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），数据库可直接按索引叶子节点顺序读取数据，省去内存或磁盘排序步骤。
行盟APP1.0 php版
下载
行盟APP是结合了通信和互联网的优势，加之云计算所拥有的强大信息资源，借助广大的终端传递服务，潜在的拥有巨大商机。她到底是什么，又有什么作用？她是一款手机应用软件；她是一款专门为企业服务的手机应用软件；她是一款能够将企业各种信息放入其中并进行推广传播的手机应用软件！只要轻轻一点，企业的简介，产品信息以及其他优势就能最快最大限度的透过手机展现在客户的眼前，一部手机，一个APP，你面对的将是一个6亿&
- 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) = 2023），索引失效，需改写为范围查询（create_time BETWEEN '2023-01-01' AND '2023-12-31'）
- INSERT/UPDATE/DELETE 会变慢——每次修改都要同步更新索引结构
