[优化] 通过索引优化含ORDER BY的MySQL语句的经验分享

saturn

看到社区里面大家非常踊跃的讨论关于MySQL优化，特别是Order by优化的问题[via]，我就将自己在平时项目中积累的一些经验和大家分享一下。一家之言，未免有误，欢迎拍砖，仅供参考。

关于建立索引的几个准则：
1、合理的建立索引能够加速数据读取效率，不合理的建立索引反而会拖慢数据库的响应速度。
2、索引越多，更新数据的速度越慢。
3、尽量在采用MyIsam作为引擎的时候使用索引（因为MySQL以BTree存储索引），而不是InnoDB。但MyISAM不支持Transcation。
4、当你的程序和数据库结构/SQL语句已经优化到无法优化的程度，而程序瓶颈并不能顺利解决，那就是应该考虑使用诸如memcached这样的分布式缓存系统的时候了。
5、习惯和强迫自己用EXPLAIN来分析你SQL语句的性能。

一个很容易犯的错误：

不要在选择的栏位上放置索引，这是无意义的。应该在条件选择的语句上合理的放置索引，比如where，order by。

例子：

SQL

SELECT id,title,content,cat_id FROM article WHERE cat_id = 1;

复制代码

上面这个语句，你在id/title/content上放置索引是毫无意义的，对这个语句没有任何优化作用。但是如果你在外键cat_id上放置一个索引，那作用就相当大了。

几个常用ORDER BY语句的MySQL优化：

1、ORDER BY + LIMIT组合的索引优化。如果一个SQL语句形如：

SQL

SELECT [column1],[column2],.... FROM [table] ORDER BY [sort] LIMIT [offset],[limit];

复制代码

这个SQL语句优化比较简单，在[sort]这个栏位上建立索引即可。

2、WHERE + ORDER BY + LIMIT组合的索引优化，形如：

SQL

SELECT [column1],[column2],.... FROM [table] WHERE [columnX] = [value] ORDER BY [sort] LIMIT [offset],[limit];

复制代码

这个语句，如果你仍然采用第一个例子中建立索引的方法，虽然可以用到索引，但是效率不高。更高效的方法是建立一个联合索引(columnX,sort)

3、WHERE + IN + ORDER BY + LIMIT组合的索引优化，形如：

SQL

SELECT [column1],[column2],.... FROM [table] WHERE [columnX] IN ([value1],[value2],...) ORDER BY [sort] LIMIT [offset],[limit];

复制代码

这个语句如果你采用第二个例子中建立索引的方法，会得不到预期的效果（仅在[sort]上是using index，WHERE那里是using where;using filesort），理由是这里对应columnX的值对应多个。

这个语句怎么优化呢？我暂时没有想到什么好的办法，于是就用了一个愚蠢的办法，那就是将这个语句用UNION分拆，然后建立第二个例子中的索引：

SQL

SELECT [column1],[column2],.... FROM [table] WHERE [columnX]=[value1] ORDER BY [sort] LIMIT [offset],[limit]
UNION
SELECT [column1],[column2],.... FROM [table] WHERE [columnX]=[value2] ORDER BY [sort] LIMIT [offset],[limit]
UNION
……

复制代码

4、不要再WHERE和ORDER BY的栏位上应用表达式(函数)，比如：

SELECT * FROM [table] ORDER BY YEAR(date) LIMIT 0,30;

5、WHERE+ORDER BY多个栏位+LIMIT，比如

SELECT * FROM [table] WHERE uid=1 ORDER x,y LIMIT 0,10;

对于这个语句，大家可能是加一个这样的索引:(x,y,uid)。但实际上更好的效果是(uid,x,y)。这是由MySQL处理排序的机制造成的。

以上例子你在实际项目中应用的时候，不要忘记在添加索引后，用EXPLAIN看看效果。

(暂时只想到这么多，我想到了再来更新，欢迎大家添加)

Hex

确实学到了东西，以前对于 mysql 优化接触的不多。

沧蓝

合理的索引能够大幅度的提升读取性能。

之前我优化了同事的数据库，性能一下子提升700%。

netkuxia

700%太吹牛了吧!! 3# 沧蓝

kazaff

我信！我信 ~

renwuxun

700%太吹牛了吧!! 3# 沧蓝
netkuxia 发表于 2009-9-5 22:33

这种话你都说的出口，700%也就7倍，相当不夸张，当数据量无限增加时，有良好索引的读操作时间和没索引的读操作时间的比值趋向于零（理论上是这样的，忽略了硬件局限性）

还有关于楼主的帖子，
其实楼主的索引已经搞得相当到家了，其他的不敢说楼主了，只是给个建议吧，这时候楼主如果能够把重心转移到一个更抽象的层面，比如数据结构，设计理论啊什么的或许更有利于自身进步（实践需要正确理论的指导，这句话的意义我体会到了，可惜有点晚）。
若是还在想尽办法使你的第3个句子跑的更快，那就没有必要了，这个句子永无法优化到令人愉快的程度。但是我想说一点，我也主攻php的，4年（时间不长，但这又何妨？）的应用开发中从社区、网店、cms、blog、以及b2b平台...其中从来没有出现过“where in ...”，因为几乎所有的where in...理论上都可以通过修改数据结构而绕过。所以我一直觉得凶悍的设计价值高于极限的索引。

说的有点唬人了，实时上我写php都还没有摆脱ide，但话说回来，我没有任何理由去摆脱ide，其他任何我会的语言都一样（除了js）。

最后一点，劝诫所有的代码搬运工（特别是我自己，回学校去吧），多学点数学吧，否则你的我的他（她）的水平很难有质提升……

longjianghu

不错的文章explain

yiyihao

好帖子~学习了，真希望多出现这种帖子~

kissmumu

这么高质量的文章现在才看到,
差点错过

spt119

顶楼主。SQL优化，说多久都不过分。