数据库索引那些事儿，怎么用才能查得快又准，效率提升真不难

主要参考自《高性能MySQL》、掘金社区“数据库索引深度解析”系列文章、以及多位一线后端开发工程师的实践经验分享）

咱们先来打个比方,数据库就像一个大图书馆，里面的书就是数据，如果没有索引，你要找一本叫《三体》的书，那就得从第一个书架的第一本开始，一本一本地翻，这叫“全表扫描”，效率低得吓人，而索引呢，就像是图书馆的图书目录卡片，它告诉你《三体》这本书在哪个区域、哪个书架、第几层，你直接奔着那个位置去，瞬间就能找到，快得不是一星半点。

索引的核心思想就是用空间换时间，数据库会为特定的列（或多个列）单独创建一个有序的数据结构（最常见的是B+树），这个结构里存储着列的值和对应数据行的“指针”，当你根据这个列去查询时，数据库就能像查字典一样，快速定位到数据，而不是傻乎乎地遍历整个表。

那索引具体是怎么让我们查得“快”又“准”的呢？

关键在于索引的数据结构,大多数数据库默认的索引类型是B+树索引，B+树长得像一棵倒过来的树，有根节点、分支节点和叶子节点，它的好处特别多：

1. 层级低，查询快：就算数据有千万条，B+树也只需要很少的几次比较就能找到目标，因为每一层都能过滤掉大量的数据，这就像你查英文单词，不会从A开始一个个看，而是先定位到首字母，再定位到第二字母，范围迅速缩小。
2. 叶子节点有序相连：B+树的所有数据都存储在叶子节点上，并且叶子节点之间用指针连成了一个有序链表，这对于范围查询特别友好，比如你要找价格在50到100块之间的商品，数据库只需要在索引上找到50这个起点，然后顺着叶子节点的链表往后扫描就行了，非常高效。

光有索引还不够，得会用才行，下面这些“怎么用”的窍门，才是效率提升的关键：

给谁建索引？（选择合适的列） 不是所有列都值得建索引，你应该优先考虑这些列：

• WHERE子句里的常客：经常被用来做查询条件的列，比如user_id、order_date。
• 连接查询的列：经常用于表连接（JOIN）的列，比如foreign_key。
• 高选择性的列：什么叫高选择性？就是这个列的值几乎都不重复，身份证号”、“手机号”，每个值都能精准定位到极少的几行数据，相反，像“性别”这种只有“男”、“女”两种值的列，建索引意义不大，因为一下子还是会查出半表的数据。

小心索引失效的坑！（避免无效索引） 你明明建了索引，查询却还是慢，很可能是因为你的写法让索引“失效”了，常见的坑有：

• 在索引列上做计算或函数操作：WHERE YEAR(create_time) = 2023，数据库没办法直接拿2023去有序的索引树里找，它得先把create_time这一列的所有值都拿出来用YEAR()函数计算一遍，相当于又退化成了全表扫描，正确的写法应该是 WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。
• 使用左模糊或全模糊查询：LIKE '%关键字%' 或 LIKE '%关键字'，索引是从左到右匹配的，开头就是通配符，索引就不知道从哪开始了，如果必须用，尽量用右模糊 LIKE '关键字%'，这样索引还能派上用场。
• 使用不等于条件： 或 <> 通常会导致索引失效。
• 类型转换：如果索引列是字符串类型，你却用数字去查，WHERE phone_number = 13800138000，数据库可能会进行隐式类型转换，导致索引失效。

联合索引的威力与“最左前缀原则” 我们的查询条件不止一个，查找某个用户最近下的订单”，这时，在(user_id, order_date)上建立一个联合索引（也叫复合索引），会比单独为user_id和order_date各建一个索引效果要好得多。

但联合索引有个非常重要的规则——最左前缀原则，意思是，索引就像一本书的联合目录，先按第一个字段排序，第一个字段相同的情况下再按第二个字段排序，查询条件必须包含联合索引的最左边的列，索引才能被充分使用。

• 比如索引是 (a, b, c)：
  • WHERE a = 1 AND b = 2 AND c = 3 （完美使用）
  • WHERE a = 1 AND b = 2 （使用索引的a和b部分）
  • WHERE a = 1 （使用索引的a部分）
  • WHERE b = 2 AND c = 3 （索引失效！ 因为跳过了最左边的a）

索引不是越多越好 索引虽好，但不能贪多，因为索引也是一张“表”，它需要占用额外的存储空间，更重要的是，当你对数据进行增、删、改操作时，数据库不仅要更新数据本身，还要去更新所有相关的索引，以保证索引和数据的一致性，这就会拖慢写入速度，索引的本质是一种权衡，用在读多写少的场景下效果最显著。

想让数据库查得快又准，索引是你的最佳伙伴，记住几点：给对的列（查询频繁、选择性高）建索引；避开让索引失效的写法（函数、左模糊等）；善用联合索引并遵守最左前缀原则；保持理智，索引不是万能的，过多反而会成为负担，理解了这些，数据库的效率提升，真的不难。