联合索引字段顺序直接影响数据局部性，因b+树叶子节点按索引定义顺序物理排序；多个范围查询时，仅最左等值字段加首个范围字段可定位起始位置，后续范围字段无法剪枝，导致扫描行数暴增、跨页读取、缓存命中率低。
WHERE条件中多个范围查询时，为什么索引字段顺序直接影响数据局部性
因为MySQL联合索引的B+树叶子节点是按索引定义顺序物理排序的。当WHERE里出现多个范围条件（如 b > ? 和 c > ?），只有最左的等值字段 + 第一个范围字段能用于“定位起始位置”，后续范围字段无法跳过不满足的记录——它们只能靠逐行读取判断，导致扫描行数暴增，数据在磁盘/内存中不再连续。
比如索引 (a, b, c) 上执行 WHERE a = 1 AND b > 10 AND c > 20：a=1 定位到某段；b>10 在该段内向右扫描；但c>20无法进一步剪枝，所有被b筛选出的记录都得加载出来检查c，这些记录在叶子节点上虽按c有序，但物理上可能跨多个页，缓存命中率低。
- 数据局部性差 → 更多次磁盘随机IO或Buffer Pool换页
- Extra显示
Using where而非Using index，说明索引未覆盖、回表频繁 - 即使加了
LIMIT 10，MySQL仍可能扫描上千行才凑够10条
如何用字段区分度和写入模式反推最优索引顺序
别只看“哪个字段唯一值多”，要结合查询模式和插入行为一起看。高区分度字段（如 user_id、order_no）适合放最左做等值过滤；但若业务是时间序写入（如日志表），把 created_at 放索引左侧，能让新数据集中在同一组叶子页，减少页分裂，也提升范围查询时的局部性。
- 查区分度：
SELECT COUNT(DISTINCT col)/COUNT(*) FROM tbl，值越接近1越好 - 写入热点匹配：如果
status只有3个值，但90%写入集中在status = 1，那(status, created_at)比(created_at, status)更容易让同status的数据物理相邻 - 避免把低区分度字段（如
is_deleted）放在中间——它会让索引树分支变宽，降低B+树查找效率
ORDER BY与范围条件共存时，索引顺序必须兼顾扫描起点和结果有序性
当SQL含 WHERE a = ? AND b > ? ORDER BY c DESC，索引 (a, b, c) 不仅能快速定位a=？的块、用b>？做范围扫描，还能让扫描出的每一页内c天然倒序——无需 Using filesort，更关键的是：这些c有序的记录在B+树叶节点上是连续存储的，CPU预取和页缓存效率高。
- 若错建为
(a, c, b)：a能用，但b>？变成范围后，c就失效，ORDER BY c强制排序，数据被重新打散 - MySQL 8.0+ 支持
DESC显式声明，但5.7及以前靠B+树双向遍历，(a,b,c)配ORDER BY c DESC依然有效 - 有
LIMIT时，这个局部性优势会被放大——MySQL可能只需读取前几页就拿到全部结果
EXPLAIN里哪些信号说明局部性已被破坏
光看 key 显示用了索引不够，重点盯 rows 和 Extra：
-
rows远大于实际返回行数（比如查10条却扫2万行）→ 局部性差，大量无效页加载 -
Extra: Using where出现，且没Using index→ 索引未覆盖，需回表，主键聚簇索引页随机访问 -
Extra: Using filesort→ 排序脱离索引有序性，数据被重排，局部性归零 -
type: index（全索引扫描）而非range或ref→ 索引最左字段没被利用，完全失去定位能力
真正难调的不是“能不能走索引”，而是“走索引后，数据在物理层面是否还扎堆”。字段顺序一动，B+树结构就变，局部性可能从毫秒级掉到百毫秒级——这点在分页、导出、报表类查询里特别致命。
