优化建议

优化建议

数据库中最大的性能瓶颈就是磁盘io，主要体现在读写前寻找磁道的过程中；另一个影响性能因素是内存，innodb在内存中开辟了一个Buffer_Pool缓冲池，然后把数据页和索引页都放在内存缓冲池中读写，影响缓冲池的参数是innodb_buffer_pool_size，如果仅有innodb存储引擎的数据库服务器上，可以设置为60%的内存

对于同一份数据，当我们使用不同的方式去寻找其中的内容时，所需要读取的数据量可能是天壤之别，所消耗的资源相差也很大

join语句优化

• 使用小表驱动大表(小结果集驱动大结果集)，减少join语句的nestedLoop的循环总数

  如 select * from admin left join log on log.admin_id = admin.id where log.admin_id > 10

  就应该改为

  select from (select from admin where id > 10) t1 left join log on log.admin_id = t1.id

  使得左表尽可能的小

• 优先优化内层循环，内层循环是执行次数最多的

• 保证join语句中被驱动表上的join条件已被索引

• 尽量用join代替子查询

• join buffer的大小对整个join语句的消耗起到关键的作用

减少排序

排序会消耗较多 CPU 资源，所以减少排序可以在缓存命中率高、IO 能力足够的场景下会影响 SQL 的响应时间

减少排序的方法

• 通过利用索引来排序的方式进行优化
• 减少参与排序的记录条数
• 非必要不对数据进行排序

减少or的使用

当 where 子句中存在多个条件以“或”并存的时候，MySQL 的优化器并没有很好的解决其执行计划优化问题，再加上MySQL 特有的 SQL 与 Storage 分层架构方式，造成了其性能比较低下，使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果

防止出现索引失效的情况

如以下情况应尽量避免

• 计算
• 使用not，<>，!=
• 使用IS NULL和IS NOT NULL
• 数据类型转换
• 对索引字段使用函数或者表达式
• 索引字段中有null

group by优化

group by中where高于having，能写在where中的限定条件就不要去having中限定