数据库索引那些事儿，怎么折腾才能让查询快点儿起来

主要参考自《高性能MySQL》一书、多位资深数据库工程师的公开技术分享以及数据库官方文档的通俗解读）

咱们来聊聊数据库索引这个事儿，你可以把数据库想象成一个巨大的图书馆，里面放着海量的书（也就是数据），你想找一本叫《三体》的书，如果没有索引，你会怎么办？只能从第一个书架开始，一本一本地翻，直到找到为止，这种方法我们称之为“全表扫描”，在数据库里就是一条查询语句把整张表的数据都翻一遍，效率极低，尤其当表里有几百万、几千万条数据的时候,那速度简直慢得让人想哭。

索引就是为了解决这个问题而生的，它就像图书馆的图书目录卡片，你可以通过作者名、书名或者ISBN号快速定位到书在哪个区域、哪个书架、第几层，数据库索引也是一个道理，它是一种特殊的查找表,它保存了数据表中某些列的值以及指向这些数据实际存储位置的指针。

索引是怎么让查询快起来的？

核心原理就俩字：排序，想象一下，如果图书馆的书完全是乱放的，那就算有目录卡片告诉你书在“A区3架2层”，你跑过去发现那里可能放的是一本菜谱，这目录就失效了，数据库索引会对创建索引的那一列（或多列）的值进行排序，并记住每条数据的位置，当你查询的时候，比如你根据用户名“张三”来找信息，数据库就不用扫描整个表了，它直接去索引这个“有序列表”里，用类似二分查找这种高效算法，快速定位到“张三”的位置，然后直接去对应的磁盘地址把数据拿出来，这个过程可能只需要几次查找，而不是几百万次,速度自然就上去了。

常见的索引类型和怎么用

1. 单列索引：这是最基础的，就针对某一列建索引，比如你经常根据用户的手机号来查信息，那就在手机号这一列上建个索引，但要注意，如果你建的索引列，在查询条件里根本没用到，那这个索引就等于白建了,它不会起作用。

2. 复合索引（也叫组合索引）：这个就更高级一点，是针对多个列一起建的索引，这就像图书馆的目录卡片，先按姓氏笔画排，姓氏相同的再按名字笔画排，复合索引的威力很大，但用法有讲究，这里有个非常重要的原则叫“最左前缀原则”，举个例子，你建了一个复合索引，包含三列：(省份, 城市, 区县)。

   • 查询条件用到了省份,这个索引能起作用。
   • 查询条件用到了省份和城市,这个索引也能很好地起作用。
   • 如果你的查询条件只用了城市，或者只用了区县，对不起，这个复合索引就用不上了！因为它就像电话簿，必须先知道姓，才能在里面找名，你跳过“省份”直接查“城市”，索引就蒙了,只能退回到全表扫描。

   建立复合索引时，要把最常用、筛选性最强的列放在左边。

3. 唯一索引：这个好理解，就是要求索引列的值必须是唯一的，不能重复，比如给身份证号字段建唯一索引，可以保证不会插入两个身份证号一样的人，它除了能加速查询,还能保证数据唯一性。

建索引不是越多越好，它有代价的

索引虽然好，但可不是随便建的,它就像一把双刃剑。

• 占用空间：索引本身也是一张表，它需要占用额外的磁盘空间，你建的索引越多,占的空间就越大。
• 降低写操作速度：当你往表里插入一条新数据、删除一条数据或者更新了索引列的值时，数据库不仅要动原始数据，还得去更新所有相关的索引，维护那个“有序列表”，这意味着，写操作（增、删、改）会变慢，如果一个表需要频繁地写入,索引建得太多就会成为负担。

建索引的一个基本哲学是：用在读多写少的表上，比如电商网站的商品表、新闻网站的文章表，大家主要是在查询浏览，很适合建索引，而像日志表这种，几乎只有写入、很少查询的,就别建太多索引了。

实战中的一些小技巧

• 选择区分度高的列：什么叫区分度高？就是这列的值几乎都不重复，比如身份证号、手机号，区分度就极高；而像“性别”这种，只有“男”、“女”两种值，区分度就很低，你给性别建索引，数据库通过索引一下子找到了所有“男”的记录，可能还有几百万条，它还得在这几百万条里继续扫描，索引的效果就大打折扣了，优先选择那些在WHERE子句里经常出现且值种类多的列建索引。
• 避免在索引列上做计算或函数操作：你有一个日期字段create_time，你经常要查某一天的数据，错误的写法是：WHERE DATE(create_time) = '2023-10-01'，这样即使create_time上有索引，数据库也得对每一行数据都先计算一下DATE()函数，索引就又失效了，正确的写法是：WHERE create_time >= '2023-10-01' AND create_time < '2023-10-02',这样索引才能派上用场。
• LIKE查询要小心：像LIKE '%关键字%'这种模糊查询，尤其是开头用了通配符的，索引基本是无效的，因为索引是根据值的前缀来组织的，你开头都不确定，数据库又得全表扫描了，如果非要优化,可以考虑使用专业的全文搜索引擎。

没有一劳永逸的索引方案，随着业务发展，数据量和查询模式都会变，所以要定期审视你的慢查询日志，看看哪些查询慢了，分析一下是不是索引没建对，然后不断地进行调整和优化，折腾索引,就是个持续的过程。