mysql优化总结

最近这两周?直在做数据存储查询优化，恰逢?初听了?次数据库技术?会，今天便想着对 mysql的优化做?下总结。这篇总结主要着眼于mysql的配置，表结构设计以及sql语句的优化。

?、mysql配置优化

max_connections：最?客户端连接数，如果服务器的并发连接请求量?较?，建议调 ?此值，以增加并?连接数量，当然这建?在机器能?撑的情况下，因为如果连接数越多，鉴于MySql会为每个连接提供连接缓冲区，这就会开销越多的内存，所以还是需要根据系统各服务实际情况设置。
key_buffer_size：索引缓存??（将从磁盘上读取的索引缓存到内存，可以设置?? 些，有利于快速检索）。
innodb_buffer_pool_size： Innodb 存储引擎缓存池??。对于 Innodb 来说最重要的 ?个配置，如果所有的表?的都是 Innodb ，那么甚?建议将该值设置到物理内存的 80%， Innodb 的很多性能提升如索引都是依靠这个。
max_allowed_packet：mysql接收的最?数据包??，这个主要在批量插?数据场景下可以设置?些。
innodb_log_buffer_size：表?InnoDB写?到磁盘上的?志?件时使?的缓冲区的字节数，默认值为8M。?个?的?志缓冲区允许?量的事务在提交之前不写?志到磁盘。因此，如果你有很多事务的更新，插?或删除操作，通过这个参数会?量的节省了磁盘 IO。
innodb_log_file_size：该参数决定着mysql事务?志?件（ib_logfile0）的??，对于具有?量数据插?操作的应?来说，这个参数需要设置??些，这样可以提?redo log 的IO性能，但是设置的过?会导致mysql故障恢复时间变?。

?、表结构优化

尽可能??的数据类型并指定较?的?度：能?整型就不要?字符串，?字符串尽量? varchar并指定较??度；
字段尽量?not null：? null 字段的处理要? null 字段的处理?效些！且在sql语句中不需要判断是否为 null；
字段?定要加注释：之前项?中就是因为字段没有注释，踩了太多坑；
设计表的时候，如果有?张表将来肯定会存储?量数据（这个?般是可以预判到的）建议建表时预留字段，避免将来数据量?新增字段过于费时；
遵守第??第三范式；对于数据量?的表，可提前进?分表；
建?索引：建?索引需要注意?定要根据实际查询?式来确定索引。这?记录?下我们项?上踩的坑：我们之前建?索引时对?张表中查询?到的三个列都建?单列索引，当查询同时涉及这三个列时，其实mysql只会?到其中?个它认为效率最优的那?列，这时候在存储、查询效率??建三个单列索引明显不如建??个组合索引划算。

三、sql语句优化

1）查询语句

?先查询缓存?定要开启哈query_cache_type设为1。
不要select *，需要什么字段的数据就查什么字段的数据；
如果表数据量?，不要?次性将所有数据查询出来。这?需要注意，如果?张表数据量千万级别，会发现查询前?万条数据效率还?，但是越到后边使?limit查询效率直线下滑，这个时候可以考虑使?其主键id作为查询游标，这样效率会?幅上升；
慎?in查询，in查询不使?索引有时候会导致全表扫描，如果查询参数是连续数值，那就?between；
连表查询时确保?表驱动?表，如果你不确定谁驱动谁，那就不要指定left join或者right join，直接?join然后让mysql??判断；

2）数据插?

?量数据插?时，?定要?insert values这种形式。这?需要注意在spring项?中批量插??量数据?定要?jdbc执?原?sql，不要?mybatis，mybatis由于要做字段映射， ?量使?java反射机制，会导致性能损耗；
?量数据插?时，最好不要并发执?，这会导致query排队，最好设计?个专门?于数据存储的服务，所有数据插?都交由它执?；

以上就是?些常?的mysql优化了，当然并不全，后续还会进?补充。

数据库

相关