能，因为优化器会自动重排条件顺序，只要复合索引最左列col_a在WHERE中参与等值查询，col_b= ? AND col_a= ?仍可走(col_a, col_b)索引。
WHERE 条件里用了 col_a 和 col_b，但只对 (col_a, col_b) 建了复合索引，col_b = ? AND col_a = ? 能走索引吗？
能，但取决于查询条件是否满足「最左前缀匹配」。MySQL/PostgreSQL 的 B-tree 复合索引从左到右逐列构建有序结构，WHERE 中只要包含索引最左侧连续列（哪怕顺序打乱），就能利用索引定位起始位置。
实际执行时优化器会自动重排条件顺序，所以 col_b = ? AND col_a = ? 和 col_a = ? AND col_b = ? 效果一致——前提是 col_a 是索引第一列。
- ✅ 有效：索引
(col_a, col_b)+ 查询WHERE col_a = 1 AND col_b = 2 - ✅ 有效：索引
(col_a, col_b)+ 查询WHERE col_b = 2 AND col_a = 1（优化器重排） - ❌ 无效：索引
(col_a, col_b)+ 查询WHERE col_b = 2（跳过左列，无法定位范围） - ⚠️ 部分生效：索引
(col_a, col_b, col_c)+ 查询WHERE col_a = 1 AND col_c = 3（col_b缺失，col_c无法用索引过滤，只能回表或全扫）
等值查询 + 范围查询混用时，col_a = ? AND col_b > ? AND col_c = ? 的索引列顺序怎么排？
把等值列放前面，范围列紧接其后，且范围列只能有一个（后续列失效）。B-tree 索引一旦遇到范围（>、、<code>BETWEEN、LIKE 'abc%'），就只能用到该列为止，右边列不再参与索引过滤。
例如 col_a = ? AND col_b > ? AND col_c = ?，最优索引是 (col_a, col_b, col_c) —— col_a 精确匹配定位起点，col_b 范围扫描划定区间，col_c 在这个区间内再过滤（但不走索引查找，仅内存过滤）。
- ✅ 推荐索引：
(col_a, col_b, col_c)→ 利用col_a和col_b，col_c不参与索引查找但可减少回表数据量 - ❌ 避免索引：
(col_a, col_c, col_b)→col_c = ?在范围列col_b前，但col_b是范围，导致col_c实际无法被索引利用（因col_b未定界，col_c的有序性已断裂） - ⚠️ 注意：如果
col_c区分度极高（比如唯一值），有时加在范围列后仍能降低回表行数，但别指望它提升索引扫描效率
ORDER BY 和 WHERE 同时存在时，WHERE a = ? AND b > ? ORDER BY c DESC 还需要单独建排序索引吗？
不需要额外建索引，只要 c 是复合索引的「连续后缀」，且前面的列已满足 WHERE 过滤条件，就能避免文件排序（Using filesort）。
关键看索引是否覆盖「过滤 + 排序」的完整有序路径。例如查询 WHERE a = ? AND b > ? ORDER BY c DESC，索引 (a, b, c) 可以：先用 a 定位，再用 b 范围扫描，此时 c 在每个 (a,b) 子区间内天然有序，直接按需取反序即可。
- ✅ 有效：索引
(a, b, c)→ 过滤和排序全部走索引 - ✅ 也有效：索引
(a, b, c, d)→ 多余列不影响，c仍是连续后缀 - ❌ 无效：索引
(a, c, b)→b是范围，c在中间，c的有序性被b打断，无法用于排序 - ⚠️ 检查方式：
EXPLAIN看Extra字段有没有Using filesort；有，说明排序没走索引
线上慢查突然变快，SHOW INDEX 显示索引没动，但 EXPLAIN 的 key_len 变小了，可能是什么原因？
很可能是查询条件中某个列发生了隐式类型转换，导致索引截断使用。比如索引是 (user_id, status)，而 user_id 是 BIGINT，但 SQL 里写了 WHERE user_id = '123'（字符串），MySQL 会把整列转为字符串比对，无法用 user_id 的索引部分做高效查找，key_len 就只算到 status 那一截（甚至归零）。
- ? 典型诱因：
INT列用字符串比较、VARCHAR列用数字比较、字符集不一致（如 utf8mb4 vs utf8）、JSON 列误用=而非-> - ? 快速验证：
EXPLAIN FORMAT=JSON查used_columns和key_length是否与预期一致；或开general_log看实际传入参数类型 - ? 修复动作：统一参数类型（应用层绑定
LONG而非STRING），显式CAST，或加函数索引（如INDEX ((CAST(user_id AS CHAR)))） - ⚠️ 特别注意：ORM 自动生成的 SQL 很容易忽略字段类型，比如 MyBatis 的
#{id}如果id是 Long 却配置成 String 类型，就会触发隐式转换
列顺序不是玄学，是 B-tree 结构决定的刚性约束；调优时盯着 EXPLAIN 的 key_len 和 Extra，比反复猜索引名更可靠。真正容易被绕过去的是类型隐式转换——它不报错，不告警，只悄悄让索引失效。
