等值条件必须置于组合索引最左侧，因B+树仅能高效利用连续左侧字段；范围条件（>、
联合索引里等值条件必须在范围条件左边
因为 MySQL 的 B+ 树索引是按字段顺序逐列构建有序结构的，一旦某列用了范围查询（>、、<code>BETWEEN、LIKE 'abc%'），后续列就无法再用于索引查找——不是“效率低”，而是根本进不了索引搜索路径。
常见错误现象：
-
WHERE a = 1 AND b > 10 AND c = 5配合INDEX (a, b, c)→c完全不走索引查找，只可能靠回表后内存过滤 -
WHERE b > 10 AND a = 1即使优化器重排为a = 1 AND b > 10，也仅能用上a和b，c依然失效 -
INDEX (created_at, user_id)配合WHERE user_id = 123 AND created_at > '2024-01-01'→ 实际只用上created_at，user_id变成全表扫描级过滤
多个等值条件之间顺序可以调，但不能和范围混着放
MySQL 查询优化器会自动重排 = 和 IN 条件的书写顺序，所以 WHERE b = 2 AND a = 1 能命中 INDEX (a, b)。但这个“重排自由”只适用于等值条件，一掺进范围操作就失效。
实操建议：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 把所有
=或IN字段左对齐排列，优先放高频、高区分度字段（如user_id比status更适合作首列） -
IN在 MySQL 8.0.24+ 支持与范围字段共存（如(a IN (1,2), b > 10)），老版本仍会截断，别依赖 - 不要把低区分度字段（如
is_deleted TINYINT）放在最左——它会导致大量数据落在同一索引分支，索引几乎白建
ORDER BY 字段必须紧接等值字段，且不能被范围中断
如果查询带 ORDER BY，想避免 Using filesort，排序字段必须出现在联合索引中，并且位置要满足两个条件：在所有等值字段之后、在范围字段之前（或就是唯一的范围字段）。
例如：
-
WHERE tenant_id = 1001 AND status = 'active' ORDER BY created_at DESC→ 建INDEX (tenant_id, status, created_at)可跳过排序 - 但若改成
WHERE tenant_id = 1001 AND created_at > '2024-01-01' ORDER BY status→status在范围之后，无法用于排序，必然触发Using filesort -
INDEX (a, b, c)支持ORDER BY a, b，不支持ORDER BY b, a或单独ORDER BY c
验证是否真用上了联合索引，只看 EXPLAIN 的三项
别信“我写了 WHERE 就一定走索引”。真正判断依据只有三个字段：
-
key：显示实际使用的索引名，为空说明没走索引 -
key_len：值越接近索引总字节数，说明用得越充分；比如INDEX (a INT, b VARCHAR(50), c DATETIME)总长 ≈ 4 + 50×3 + 8 = 162 字节，若key_len = 4，说明只用到了a -
Extra：出现Using index condition表示启用了 ICP（索引条件下推），是好事；出现Using filesort或Using temporary就得回头检查索引顺序
最容易被忽略的是：范围条件后的字段即使写在 WHERE 里，也不会反映在 key_len 中——它看起来“被忽略了”，其实是 B+ 树物理结构决定的硬限制，不是配置或语法问题。
