等值条件必须置于组合索引最左侧，因B+树仅能高效利用连续左侧字段；范围条件（如>、
等值条件必须放组合索引最左边
MySQL 的 B+ 树索引只能高效利用「连续的左侧字段」，一旦遇到范围条件（>、、<code>BETWEEN、LIKE 前缀匹配以外的情况），后续字段就无法走索引了。所以 WHERE status = 1 AND created_at > '2024-01-01' 能用上 (status, created_at)，但反过来写成 (created_at, status) 就只用到 created_at，status 变成全表过滤。
- 等值字段（
=、IN）优先排左，数量越多越好 -
IN算等值，但 MySQL 8.0.24+ 才支持IN后面接范围字段（如(a IN (1,2), b > 10)），老版本仍会截断 - 多个等值字段之间顺序影响不大，但要考虑高频查询的筛选率：高区分度字段（如
user_id）放更左，能更快缩小扫描范围
范围条件只能放在等值字段之后，且最多一个
组合索引中允许出现一个范围字段，但它必须紧接在所有等值字段之后；再往后加任何字段，都进不了索引查找阶段，只能靠回表后内存过滤。
- 错误示例：
INDEX (a, b, c)配合WHERE a = 1 AND b > 10 AND c = 5→c不走索引 - 正确做法：把
c拿到等值侧，比如改写成WHERE a = 1 AND c = 5 AND b > 10，再建索引(a, c, b) -
ORDER BY字段如果和索引顺序一致，且没有被范围中断，可避免文件排序；否则即使有索引也触发Using filesort
LIKE 前缀匹配算等值，通配符开头不算
LIKE 'abc%' 是索引友好型范围（本质是 >= 'abc' AND LIKE '%abc' 或 LIKE '%abc%' 完全无法使用 B+ 树索引，只能全表扫或依赖全文索引。
- 如果业务常查后缀或模糊中间，别硬塞进普通组合索引，考虑
FULLTEXT或倒排（如把字符串反转存一列，索引它再查REVERSE(col) LIKE 'cba%'） -
LIKE 'abc%'在组合索引里可当范围字段用，但不能出现在等值字段中间——例如(a, b, c)中，若b LIKE 'x%'，则c失效 - 注意字符集和排序规则：utf8mb4_bin 下大小写敏感，可能导致预期外的索引失效，建议统一用
utf8mb4_0900_as_cs或明确COLLATE
EXPLAIN 不显示 "Using index condition" 就可能漏了 ICP
MySQL 5.6+ 引入索引条件下推（ICP），能把部分 WHERE 条件下推到存储引擎层过滤，减少回表次数。但只有满足特定条件才会启用，比如范围字段后的等值条件，或者函数不作用于索引列本身。
- 检查
EXPLAIN输出中的Extra字段：出现Using index condition表示 ICP 生效；只有Using where则说明过滤在 Server 层做，已回表 - ICP 不生效常见原因：用了函数（
YEAR(created_at) = 2024）、隐式类型转换（status = '1'但字段是 int）、或者索引字段顺序没对齐条件顺序 - 别依赖 ICP 补救烂索引设计——它只是优化，不是救命稻草
索引顺序不是玄学，是 B+ 树结构决定的刚性约束。最容易被忽略的是：你以为的“范围”可能不是 MySQL 认定的范围（比如 !=、NOT IN 都不算，直接放弃索引），还有 NULL 值在等值判断里的行为差异（IS NULL 可走索引，col != 1 会跳过 NULL 行但不走索引）。这些细节不验证，光调顺序没用。
