数据库索引那些事儿，怎么用才不踩坑你得知道点啥

主要参考和融合了多位资深数据库工程师和开发者在社区如知乎、CSDN、个人博客上的经验分享，以及《高性能MySQL》等经典书籍中的核心理念）

说到数据库索引，你可以把它想象成一本书最前面的目录，你想找书里讲“索引”的那一页，如果没有目录，你就得从第一页开始一页一页地翻，这叫“全表扫描”，效率极低，但有了目录，你直接找到“索引”这个词对应的页码，翻过去就是了，快得很，数据库索引干的就是这个事儿,它能大大加快数据的查询速度。

这个“目录”可不是随便建的，用不好，不仅帮不上忙，还会添乱,下面就来聊聊怎么用索引才不踩坑。

第一坑：乱建索引，觉得越多越好

这是新手最容易掉进去的坑，觉得索引能加速，就给每个字段都建一个索引，这就像给一本书的每一个名词、动词、形容词都编进目录，结果目录比正文还厚，你想找点东西,光看目录就眼花缭乱了。

坏处很明显：

1. 降低写速度（增、删、改）： 你每往书里加一页（插入数据），或者修改一页的内容（更新数据），都得同步更新后面所有的目录（索引），索引越多，这个维护成本就越高,写操作自然就变慢了。
2. 占用空间： 索引也是要占硬盘空间的，数据量一大,多余的索引会白白浪费很多存储。
3. 选择困难症： 数据库优化器有时候会犯傻，面对一大堆索引，它可能选了个最差的来用,反而拖慢查询。

怎么办？ 要有选择地建，通常给那些经常用在 WHERE 条件里、或者用来做表连接（JOIN）的字段建索引，你有个用户表，几乎每个查询都要按用户名找人,那给用户名字段建索引就非常划算。

第二坑：索引建了，但查询用不上

有时候你以为建了索引就万事大吉，一查速度还是慢,很可能你的查询语句根本没用到索引。

几种常见的“气死索引”的写法：

1. 对索引列做了计算或函数处理： 你给 age 字段建了索引，但你的查询条件是 WHERE age + 10 > 30，数据库没办法直接拿“age+10”这个计算后的值去索引树里找，因为它只知道原始年龄值，所以它只能把所有数据捞出来，逐个计算一遍，正确的写法是 WHERE age > 20。
2. 索引列用了不等号或 NOT： 像 WHERE status != 'active' 或者 WHERE name NOT LIKE '张%' 这样的条件，即使 status 和 name 有索引，数据库也往往不愿意用，因为它要扫描索引中除了‘active’或‘张’开头以外的所有条目，范围太大，可能还不如直接全表扫描快，对于 LIKE 模糊查询，只有前缀匹配（如 LIKE '张%'）才能有效利用索引，中缀（LIKE '%张%'）和后缀（LIKE '%张'）匹配是用不上的。
3. 联合索引的顺序没搞对： 联合索引指的是把多个字段合起来建一个索引，(城市, 性别)，这个索引的好处是，它既支持按“城市”查，也支持按“城市+性别”一起查，但是它不支持跳过“城市”直接按“性别”查，这就像电话簿是按（姓，名）排序的，你可以快速找到所有姓“张”的人，也可以找到姓“张”且叫“三”的人，但你想找出所有叫“三”的人，这个电话簿就帮不上忙了，你得翻遍全书，所以建联合索引时，要把最常用、区分度最高的字段放在前面。

第三坑：忽略了索引的选择性

索引的“选择性”指的是索引列中不同值的个数占总条目的比例，性别”字段，只有‘男’、‘女’两个值，选择性就很低；而“身份证号”字段，几乎人人不同,选择性就非常高。

给选择性很低的列建索引，意义不大，比如你在性别上建索引，查出来的结果可能还是占了总数据量的40%，数据库优化器一看，用索引查完还得回表找这么多数据，太麻烦了，可能干脆就直接全表扫描了，优先为选择性高的列建索引,效果才显著。

第四坑：只关注查询，不关注排序和分组

索引不仅能加速查询，还能加速 ORDER BY（排序）和 GROUP BY（分组）操作，如果你的查询经常需要按某个字段排序或分组，给这个字段建索引也会有很大帮助，因为索引本身就是排好序的数据结构，数据库可以直接按索引的顺序返回结果，避免了临时的排序操作,这在处理大量数据时性能提升非常明显。

不踩坑的关键点：

• 别贪多： 索引不是越多越好,要权衡读写性能。
• 写对SQL： 确保你的查询条件能让索引“吃得下”，避免在索引列上计算、用函数。
• 理解联合索引： 注意字段顺序,像剥洋葱一样从最外层开始用。
• 选择高区分度的列： 优先给值重复少的字段建索引。
• 考虑排序和分组： 如果常用,也为这些操作建索引。

最后记住，索引是一门实践的艺术，没有放之四海而皆准的法则，最好的办法是，在真实的数据和查询压力下，用数据库提供的工具（如 EXPLAIN 命令）去分析你的SQL语句到底有没有用对索引，然后不断调整优化，这样才能真正让索引成为你的得力助手,而不是性能瓶颈。