查询优化（MySQL优化查询）

SQL性能下降的原因

• 查询语句本身写的烂
• 索引失效
  • 单值索引
  • 复合索引
  • 覆盖索引
• 关联查询太多join（设计缺陷或不得已的需求）
• 数据库服务器调优及各个参数设置不适当（缓冲、线程数等）

找出慢SQL语句：慢查询日志

慢查询日志：找出运行速度慢的SQL语句

MySQL优化几大步骤

• 观察，至少跑1天，看看生产的慢SQL情况。

• 开启慢查询日志，设置阈值，比如超过5秒钟的就是慢SQL，并将它抓取出来。

• explain+慢SQL分析

• show profile，查看硬件资源使用情况

• 运维经理 or DBA，进行SQL数据库服务器参数调优。

• 总结

1. 慢查询的开启并捕获
2. explain+慢SQL分析
3. show profile查询SQL在Mysql服务器里面的执行细节和生命周期情况
4. SQL数据库服务器的参数调优

优化手段：explain+慢SQL分析后进行优化时使用

索引优化：建立索引，使用索引快速查询

索引优化

永远小表驱动大表: 类似嵌套循环Nested Loop

优化原则：小表驱动大表，即小的数据集驱动大的数据集

当B表的数据集必须小于A表的数据集时，用in优于exists
当A表的数据集必须小于B表的数据集时，用exists优于in
注意：A表与B表的ID字段应建立索引。

• EXISTS

1. SELECT … FROM table WHERE EXISTS(subquery)
2. 该语法可以理解为：将主查询的数据，放到子查询中做条件验证，根据验证结果（TRUE或FALSE）来决定主查询的数据结果是否得以保留。

• 提示

1. EXISTS（subquery）只返回TRUE或FALSE，因此子查询中的SELECT *也可以是SELECT 1或SELECT ‘X’，官方说法是实际执行时会忽略SELECT清单，因此没有区别。
2. EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担心效率问题，可进行实际检验以确定是否有效率问题。
3. EXISTS子查询往往也可以用条件表达式/其他子查询或者JOIN来替代，何种最优需要具体问题具体分析。

• 总结
  

ORDER BY关键字优化

ORDER BY子句，尽量使用Index方式排序，避免使用FileSort方式排序

建表SQL

案例

• MySQL支持两种方式的排序

1. FileSort和Index，Index效率高。FileSort方式效率较低。
2. Using Index，它指MySQL扫描索引本身完成排序。

• ORDER BY满足两种情况，会使用Index方式排序：

1. ORDER BY语句使用索引最左前列
2. 使用Where子句与ORDER BY子句条件列组合满足索引最左前列

尽可能在索引列上完成排序操作，遵照索引建的最佳最前缀

• 如果不在索引列上，filesort有两种算法：
  
  
  

• 小总结

GROUP BY关键字优化

group by实质是先排序后进行分组，遵照索引建的最佳左前缀。

• 当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置。
• where高于having，能写在where限定的条件就不要去having限定了