0%

优化建议

优化建议

数据库中最大的性能瓶颈就是磁盘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中限定

欢迎关注我的其它发布渠道