在MySQL中，当数据量逐渐增大，最直观的感受就是某些查询变得越来越慢。之所以要引入索引，根本原因在于数据库默认的数据存储方式是按插入顺序堆放在表中的，如果没有额外的检索结构，任何条件查询都只能从第一行开始逐条比对，这种全表扫描在大数据量下完全不可接受。索引通过预先构建有序的辅助结构，让数据库可以用极少的步骤定位到目标数据所在位置，从而把时间复杂度从O(n)降低到O(log n)级别。
一、全表扫描的问题到底在哪里
假设我们有一张订单表 orders，里面存放了五百万条记录，现在需要查询某个用户最近的一笔订单。如果没有任何索引，MySQL只能执行所谓的全表扫描（Full Table Scan），也就是把五百万行数据从磁盘读入内存，一行一行判断 user_id 是否匹配。这个过程不仅消耗大量磁盘IO，还会占用CPU做无意义的比较，而且在返回结果前必须遍历完所有数据。
更麻烦的是，全表扫描会污染InnoDB的缓冲池（Buffer Pool）。因为大表扫描会把很多只使用一次的页加载进内存，挤掉那些真正热点数据，导致其他查询也变慢。当并发量上来后，多个全表扫描并行执行，数据库很容易出现线程阻塞、连接数打满的情况。这也是为什么线上业务SQL必须避免全表扫描。
-- 没有索引时的查询，explain会出现ALL类型 EXPLAIN SELECT * FROM orders WHERE user_id = 10086; -- 给user_id加上索引后再执行 CREATE INDEX idx_user_id ON orders(user_id); EXPLAIN SELECT * FROM orders WHERE user_id = 10086; -- 此时type变为ref，rows从500万降到极少数量
二、MySQL索引的底层结构原理
MySQL最常用的InnoDB存储引擎默认使用B+树作为索引结构。B+树是一种多路平衡查找树，它的非叶子节点只存键值用于导航，所有真实数据记录都放在叶子节点，并且叶子节点之间用双向链表串联。这样的设计让树的高度通常只有三到四层，哪怕表里有上亿条数据，一次等值查询也只需要三次左右磁盘IO。
与普通的二叉搜索树或哈希表相比，B+树特别适合磁盘存储。因为每次磁盘读取是以页（默认16KB）为单位的，B+树的一个节点可以放下很多键值，极大降低了树高。另外，范围查询如 WHERE id > 100 AND id < 200 可以借助叶子节点的链表顺序遍历，不必回溯上层节点，效率非常高。哈希索引虽然等值查询快，但不支持范围且存在哈希冲突，因此InnoDB的 adaptive hash index 只是辅助能力。
-- 查看索引使用情况的一个简单方式 SHOW INDEX FROM orders; -- 联合索引的最左前缀原则示例 CREATE INDEX idx_uid_status ON orders(user_id, status); -- 以下查询能用到索引 SELECT * FROM orders WHERE user_id = 1 AND status = 'paid'; -- 以下只能用到user_id部分 SELECT * FROM orders WHERE status = 'paid';
三、索引带来的其他隐性收益
除了加速查询，索引还能减少锁的持有时间。在InnoDB的行锁机制下，查询如果通过索引快速定位，那么只会对命中行加锁；若是全表扫描，则可能在遍历过程中对大量行加锁甚至升级为间隙锁，阻塞其他事务。对于高并发下单、扣款类场景，索引几乎是保障系统吞吐量的前提。
此外，合理的索引可以优化排序与分组操作。比如 ORDER BY create_time 如果 create_time 上有索引，MySQL就能直接按索引顺序读数据，省去了额外的 filesort 临时文件排序过程。没有索引时，几万行数据的排序就可能在内存或磁盘产生明显延迟。因此，索引不只是“查得快”，而是贯穿了整条SQL执行链路的效率基石。
| 对比项 | 无索引 | 有B+树索引 |
|---|---|---|
| 查询复杂度 | O(n)全表扫描 | O(log n)树检索 |
| 磁盘IO次数 | 与数据量成正比 | 稳定3到4次 |
| 缓冲池影响 | 易污染热点数据 | 只加载命中页 |
| 锁范围 | 可能锁大量行 | 仅锁命中行 |
四、使用索引时要注意的误区
有人觉得索引越多越好，其实不然。每一个索引在写入数据时都要同步维护，INSERT、UPDATE、DELETE都会带来额外的B+树分裂与合并开销。一张表如果建了七八个索引，写性能会明显下滑。正确的做法是针对高频查询字段建索引，并尽量使用联合索引覆盖多个查询条件。
还有常见误区是对字段做函数运算导致索引失效，例如 WHERE DATE(create_time) = '2023-01-01' 会让MySQL放弃使用 create_time 上的索引。应当改写为范围查询 WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02'。理解索引的工作方式，才能让它真正发挥作用而不是成为负担。
-- 错误写法：索引失效 SELECT * FROM orders WHERE DATE(create_time) = '2023-01-01'; -- 正确写法：走索引范围扫描 SELECT * FROM orders WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02';
综合来看，使用MySQL索引是为了在海量数据下依旧保持稳定的查询延迟、降低系统资源消耗并支撑高并发访问。它是数据库性能优化中最基础也最立竿见影的手段，理解其原理并规避常见误用，是每一位后端开发者必备的功课。