前几天帮一个朋友看数据库问题，他那个查询跑了8秒，页面转圈转得用户都想砸电脑。我让他把执行计划发过来，一看全表扫描，几十万行数据硬扛。加了个联合索引，查询时间从8秒降到0.02秒。他当场就愣了，问我这索引到底怎么加才能这么神。
说实话，MySQL索引优化这事儿，说难不难，说简单也不简单。很多人以为加个索引就完事了，结果发现查询反而变慢了。别笑，我见过一个开发往一张表上堆了十几个索引，每个查询都慢得像蜗牛爬。索引不是越多越好，关键是得懂原理。
先搞明白一件事：索引就是书的目录。没有目录你只能一页页翻，有目录就能直接定位。但目录也有代价——每次加新内容，你得更新目录。所以索引不是免费的，它占用磁盘空间，写操作时还要维护。问题在于很多人加索引全凭直觉，看到查询慢就随手加一个，完全不管执行计划怎么走。
我有个习惯，写SQL之前先看执行计划。用EXPLAIN关键字，看type字段是不是ALL或者index。如果是，说明全表扫描或全索引扫描，这两个基本就是慢查询的元凶。这时候你需要的不是随便加索引，而是分析WHERE条件、JOIN字段、ORDER BY字段，看看能不能用B+树索引的二分查找干掉全表扫描。
有一次查一个电商订单表，WHERE条件里有。新手可能会给status和createtime分别建索引，但MySQL通常只会选其中一个。正确做法是建联合索引，让B+树先按status筛选，再按时间范围定位，这样能直接跳过大量无关数据。联合索引的顺序很讲究，区分度高的放前面，比如status只有几个值，而时间范围可以缩小很多，那就把时间放前面不一定对，得看具体查询。
再说回索引失效的问题。我见过最典型的场景：字段上用了函数。比如，这会导致索引失效，因为MySQL得先算出所有行的DATE值才能比较。改成，就能用上索引。还有LIKE查询，也会让索引失效，因为B+树只能从左到右匹配。这些细节不注意，索引就是摆设。
覆盖索引是个好东西，很多人不知道。简单说，就是查询的字段全部在索引里，MySQL不用回表查数据行。比如你查，如果建了索引，查询直接走索引就拿到结果，不用再去数据页里翻。这在读多写少的场景下提升特别明显。我试过把一个大查询改成覆盖索引，IO次数从几百次降到几次。
索引维护也很重要。时间长了，索引会产生碎片，尤其是在频繁增删改的表上。可以用重建索引，或者定期检查索引使用情况。能看到Cardinality，这个值代表索引的区分度，如果很低但索引很大，说明这个索引可能没用。我还见过一些人给布尔字段加索引，比如status只有0和1，这种字段加索引基本没意义，因为每个值都对应一半数据，索引还不如全表扫描快。
说个实战技巧：慢查询日志一定要开。，设定，超过2秒的查询都会被记录下来。然后分析这些慢查询，用EXPLAIN看执行计划，再针对性加索引。别凭感觉优化，数据会告诉你哪里该动手。我处理过的慢查询，90%都是索引没用好，剩下的10%是SQL写得有问题。把索引搞懂了，大部分性能问题就解决了。
