SQL索引仅加速特定条件下的读取效率，通过B+Tree结构减少扫描范围和比较次数，优化WHERE定位、ORDER BY/GROUP BY排序分组及JOIN关联匹配，但不加速写入、不压缩数据、不改变查询逻辑。
SQL 索引加快的是数据查找过程中的扫描范围和比较次数，本质是把“全表逐行翻找”变成“按结构快速定位”。它不加速写入、不压缩数据、也不改变查询逻辑，只优化特定条件下的读取效率。
加快 WHERE 条件的行定位
当查询带 WHERE（如 WHERE user_id = 123 或 WHERE status = 'active'），数据库会优先检查该字段是否有索引。如果有，就跳过全表扫描，直接在索引树（B+Tree）中做二分查找或范围遍历，几毫秒内定位到目标行的物理位置。
- 无索引：扫描全部 100 万行，逐个比对 user_id
- 有索引：在高度仅 3–4 层的 B+Tree 中最多比较 4 次，找到对应叶子节点
- 注意：LIKE 'abc%' 可用索引，但 LIKE '%abc' 不行——索引无法从右端模糊匹配
加快 ORDER BY 和 GROUP BY 的排序与分组
如果 ORDER BY 字段已建索引（且顺序一致，如 INDEX (created_at) 对应 ORDER BY created_at ASC），数据库可直接按索引叶子节点顺序读取数据，省去内存或磁盘排序步骤。
- GROUP BY 同理：索引能天然聚合同一值的数据块，减少哈希或临时表开销
- 若 ORDER BY 包含多个字段，需创建联合索引并注意字段顺序（如 INDEX (a,b) 支持 ORDER BY a,b，但不支持 ORDER BY b,a）
加快 JOIN 关联时的驱动表匹配
在 INNER JOIN 中，数据库常选小表为驱动表，用其关联字段去大表中查找匹配行。若大表的 ON 字段（如 orders.user_id）有索引，每次查找就是一次索引搜索，而非全表扫描。
- 例如：users JOIN orders ON users.id = orders.user_id，orders.user_id 上的索引让每次用户订单查找从 O(n) 降为 O(log n)
- 没索引时，每查一个用户就要扫一遍 orders 表，1000 个用户 = 扫 1000 遍 orders
不加快什么？常见误解
索引不是万能加速器。以下情况它基本不起作用：
- SELECT * FROM table —— 没 WHERE，必须回表
读所有行，索引反而多一次查找开销
- WHERE 字段区分度极低（如 gender 字段只有 'M'/'F'），优化器可能弃用索引，直接全表扫描更省
- 对索引字段做函数操作（如 WHERE YEAR(create_time) = 2025），索引失效，需改写为范围查询（create_time BETWEEN '2025-01-01' AND '2025-12-31'）
- INSERT/UPDATE/DELETE 会变慢——每次修改都要同步更新索引结构
