mysql GROUP BY、DISTINCT、ORDER BY语句优化

GROUP BY、DISTINCT、ORDERBY这几类子句比较类似，GROUP BY默认也是要进行ORDERBY排序的，笔者在本书中 把它们归为一类，优化的思路也是类似的。

可以考虑的优化方式如下。

1、尽量对较少的行进行排序。

2、如果连接了多张表，ORDERBY的列应该属于连接顺序的第一张表。

3、利用索引排序，如果不能利用索引排序，那么EXPLAIN查询语句将会看到有filesort。

4、GROUP BY、ORDERBY语句参考的列应该尽量在一个表中，如果不在同一个表中，那么可以考虑冗余一些列，或者合并表。

5、需要保证索引列和ORDERBY的列相同，且各列均按相同的方向进行排序。

6、增加sort_buffer_size。 sort_buffer_size是为每个排序线程分配的缓冲区的大小。增加该值可以加快ORDERBY或GROUP BY *** 作。但是，这是为每 个客户端分配的缓冲区，因此不要将全局变量设置为较大的值，因为每个需要排序的连接都会分配sort_buffer_size大小的内存。

7、增加read_rnd_buffer_size。 当按照排序后的顺序读取行时，通过该缓冲区读取行，从而避免搜索硬盘。将该变量设置为较大的值可以大大改进ORDER BY的性能。但是，这是为每个客户端分配的缓冲区，因此你不应将全局变量设置为较大的值。相反，只用为需要运行大查询 的客户端更改会话变量即可。

8、改变tmpdir变量指向基于内存的文件系统或其他更快的磁盘。 如果MySQL服务器正作为复制从服务器被使用，那么不应将“--tmpdir”设置为指向基于内存的文件系统的目录，或者当服务 器主机重启时将要被清空的目录。因为，对于复制从服务器，需要在机器重启时仍然保留一些临时文件，以便能够复制临时表 或执行LOADDATAINFILE *** 作。如果在服务器重启时丢失了临时文件目录下的文件，那么复制将会失败。

9、指定ORDERBY NULL。 默认情况下，MySQL将排序所有GROUP BY的查询，如果想要避免排序结果所产生的消耗，可以指定ORDERBY NULL。 例如：SELECT count(*) cnt, cluster_id FROM stat GROUP BY cluster_id ORDER BY NULL LIMIT 10·

10、优化GROUP BY WITHROLLUP。 GROUP BY WITHROLLUP可以方便地获得整体分组的聚合信息（superaggregation），但如果存在性能问题，可以考虑在应用层实现这个功能，这样往往会更高效，伸缩性也更佳。

11、使用非GROUP BY的列来代替GROUP BY的列。 比如，原来是“GROUP BYxx_name,yy_name”，如果GROUP BYxx_id可以得到一样的结果，那么使用GROUP BYxx_id也是可 行的。

12、可以考虑使用Sphinx等产品来优化GROUP BY语句，一般来说，它可以有更好的可扩展性和更佳的性能。

从句子中可以看到，选取的字段比较多，另外连接条件也比较多，另外还包括了子查询。

就此语句给出几个需要注意的问题：

1、请先使用explain，对这个语句进行分析，EXPLAIN解释SELECT命令如何被处理。这不仅对决定是否应该增加一个索引，而且对决定一个复杂的Join如何被MySQL处理都是有帮助的。

2、尽量在连接条件多的时候，把数据提取量少的条件放在前面，这样会减少后一个条件的查询时间。对了，这些经常用的连接条件最好建上索引。我不清楚

INNER JOIN table_user_profile AS up ON up.uid = u.uid

INNER JOIN table_user_count AS uc ON uc.uid = u.uid

INNER JOIN table_user_daren AS ud ON ud.uid = u.uid

这些那个先内连接数据比较少，自己排列一下试一试。

3、避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等这样的 *** 作符,因为这会使系统无法使用索引,而只能直接搜索表中的数据。像in和not in这样的关键字用exists和not exists比较好。u.uid not in(SELECT uid FROM table_user_follow where f_uid=100)改成u.uid not exists(SELECT uid FROM table_user_follow where f_uid=100)，效率会有提高。

4、mysql使用函数的时候会增加负担，完全可以交给脚本程序去解决。比如此子查询：

SELECT MAX(share_id) FROM table_share 完全可以不写在这个sql语句中，交给脚本程序可以了。

只有5种吗？我知道十种以上的说。

索引（没我得全表查询了）

改变数据储引擎（MyISAM没事务再也不用担心锁表了）

增加冗余数来减少连表查询数（消耗硬盘空间减少CPU使用）

调整查询顺序减少查询量优先（数量少了连表的笛卡儿积也少了）

全文索引（文字长度有限制，而且IO使用量会大增，但是妥妥的快）

查询尽量不要用函数（函数可是不走索引的哦亲）

查询变量类型要提前对好减少系统负担（我提前改变了系统你就不用检测了）

升级服务器硬件（没什么是氪金解决不了的）

配置好临时表空间，合理理由临时表减少主表查询抢资源（唯我独查）

合理理由函数减少系统的判断（明明都能确认内容不同你用UNION 系统还是傻傻的查一遍是否重复 UNION  ALL则跳过这个步骤同理 inner join 和 left join 也一样 ）

强制走索引（复合索引的情况有时候手动走比系统判断要好哦）

脏读、幻读等（你堵车我绕路）

数据归档，迁移（没用的数据要进仓哦，别占着主表的资源）

表的碎片整理（迁移后碎片整理更健康哦亲）

索引重构（数据都走了索引也应该重构一下才能保证速度哦）

善用存储过程（串N个表（N大于10）的查询千万别一个SQL到底，分布式查询在吧结果集合并吧骚年）

预处理数据（mysql也有job哦，对于经常要子查询的数据可以先弄个明细表根据主表在后台进行补完，查询的时候就更方便了）

懒得说了。。。。。。。。。。。。。。。。。。

---