目录

1.调优步骤

2.小表驱动大表

3.order by 优化

 4.group by优化

---

1.调优步骤

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

2.小表驱动大表

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

提示
1.EXISTS (subquer) 只返回 TRUE 或FALSE，因此子查询中的 SELECT也可以是 SELECT *或select 1，官方说法是实际执行时会忽略 SELECT 清单。

2.EXISTS 子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担忧效率问题，可进行实际检验以确定是否有效率问题。

3. EXISTS 子查询往往也可以用条件表达式、其他子查询或者 JOIN来替代，何种最优需要具体问题具体分析

3.order by 优化

MySQL支持二种方式的排序，FileSort和Index，Index效率高它指MySQL扫描索引本身完成排序。FileSort方式效率较低。

满足一下两种情况会使用index进行排序：

(1)ORDER BY 语句使用索引最左前列。

(2)使用Where子句与Order BY子句条件列组合满足索引最左前列。

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

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

如果不在索引列上，filesort有两种算法:mysql就要启动双路排序和单路排序

提高Order By的速度
.Order by时select* 是一个大忌只Query需要的字段，这点非常重要。在这里的影响是:1.1当Querv的字段大小总和小于max lenth for sot dat 而排序字段不是 TEXT或BLOB 举型时，会用改进后的算法一一单路排序，否则用老算法一一多路排序。
1.2 两种算法的数据都有可能超出sof bufer的容量，超出之后，会创建tmp文件进行合并排序，导致多次10，但是用单路排序算法的风险会更大一些,所以要提高sort buffer size。
2.尝试提高 sort buffer size
不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的
3.尝试提高 max length for sort data
提高这个参数，会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort buffer size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率.

 4.group by优化

group by实质是先排序后进行分组，遵照索引建的最佳左前缀。
当无法使用索引列，增大max length for_sort data参数的设置+增大sort buffer_size参数的设置。

where高于having，能写在where限定的条件就不要去having限定了。