数据一多查询就变慢？用“目录”思维理解数据库索引
数据一多查询就变慢？用“目录”思维理解数据库索引
上期我们学习了如何使用 Sequel 进行数据查询。当表中只有 100 条数据时，查询速度几乎可以忽略不计。然而，随着业务增长，当用户数据量达到 100 万甚至更多时，同样的查询语句可能需要等待数秒，甚至直接导致超时。
为什么数据量增加会导致查询变慢？如何解决这个问题？本期我们将通过一个直观的类比，彻底讲清数据库索引的核心逻辑。
`` 是摘要与正文的分隔标记，请保留。全表扫描：数据变慢的根源
要理解索引，首先要理解数据库在没有索引时是如何工作的。
当数据库收到查询请求时，如果没有任何标记辅助，它只能从第一行开始，逐行向下查找，直到找到目标数据或翻到最后一行。这种操作被称为全表扫描（Full Table Scan）。
- 小规模数据：100 条数据扫一遍，耗时极短，用户无感知。
- 大规模数据：100 万条数据每次都从头扫到尾，计算量呈线性增长，慢是必然结果。
索引的本质：数据库的“目录”
解决全表扫描问题的办法是加索引。
我们可以将数据库表想象成一本书，将索引想象成书的目录。假设一本书有 1000 页，你要查找“数据库”这个词出现在哪一页，有两种方法：
- 全表扫描：从第一页翻到最后一页，逐页查找。
- 使用索引：翻开目录，直接定位到对应的页码，然后跳转阅读。
目录（索引）提前记录了某个值在书中的位置（页码/行号）。查询时，数据库通过索引直接定位到数据所在行，无需遍历整张表，从而大幅提升速度。
哪些字段适合加索引？
在实际开发中，索引并非随意添加，而是针对查询最频繁的字段进行优化。常见的加索引场景包括：
- 用户表：
user_id、手机号等唯一标识字段。 - 订单表：
order_id、用户关联 ID 等。
对这些字段建立索引后，数据库在执行相关查询时会直接走索引路径，速度显著提升。
索引的三大常见误区
虽然索引能加速查询，但它并非越多越好，也不是万能的。以下是开发中常见的三个坑：
1. 索引过多，拖累写入性能
索引是一把双刃剑。每次执行 INSERT（插入）或 UPDATE（更新）操作时，数据库不仅要修改数据本身，还要同步更新所有相关的索引结构。
- 后果：索引越多，写入时的维护成本越高，导致数据写入变慢。
- 建议：仅在必要的查询字段上建立索引，避免过度索引。
2. 索引建立后未生效
即使建立了索引，如果查询语句写法不当，索引也可能失效，导致数据库依然进行全表扫描。
- 典型场景：在
name字段上建立了索引，但查询时使用了LIKE '%张%'。 - 原因：前后都包含通配符（
%）的模糊查询，无法利用索引的前缀匹配特性。 - 结果：索引白建，性能无提升。
3. 在低区分度字段上建立索引
索引的效果取决于字段的区分度（即不同值的数量）。
- 典型场景：在“性别”字段上建立索引。
- 原因：性别通常只有“男”、“女”两个值，区分度极低。
- 结果：数据库优化器可能判断使用索引的收益低于全表扫描，从而直接忽略索引。
总结
索引就像书的目录，帮助数据库快速定位数据，避免全表扫描带来的性能瓶颈。但请记住：
- 建对位置：针对高频查询、高区分度的字段建立索引。
- 适度原则：索引过多会增加写入成本。
- 写法正确：避免使用导致索引失效的查询语法（如前后通配符模糊查询）。
理解索引的原理与陷阱，是编写高效数据库查询代码的关键一步。