联合索引中范围查询（如>）导致右侧字段索引失效，是因为B+树仅在左侧列值完全相等时才保证右侧列有序，一旦出现范围条件，右侧列在对应子树中无序，无法二分查找；>=虽偶有优化器多利用索引的副作用，但不能改变右侧字段失效本质，根本解决需遵循最左前缀原则并调整索引列顺序。

联合索引中 > 为什么让右侧字段索引失效

因为 B+ 树索引的有序性只在“前一列值完全相等”的前提下，才向后延续。一旦某列用了 >（或 、BETWEEN 等非等值范围条件），该列取值就不再固定，其右侧所有列在物理存储上就失去全局有序性，MySQL 无法继续用索引快速定位。

举个例子：联合索引 idx(a, b, c)，数据按 a→b→c 逐级排序。当查询写成 WHERE a = 1 AND b > 10 AND c = 100 时：

• a = 1 能定位到索引中所有 a=1 的子树段；
• b > 10 在该子树段内筛选出若干行，但这些行的 c 值是杂乱的（比如 (a=1,b=11,c=5)、(a=1,b=12,c=99)、(a=1,b=13,c=3)）；
• 所以 c = 100 无法再走索引二分查找，只能逐行判断 —— c 列索引部分实际失效。

>= 和 > 对索引利用程度不同

别以为只是“符号差别”，>= 在某些场景下能比 > 多带一个等值分支，让优化器更愿意保留右侧字段的索引能力。例如：

• WHERE a = 1 AND b >= 10 AND c = 100：优化器可能把 b = 10 单独拎出来走等值匹配，再对 b > 10 部分做 range 扫描 —— 此时若 c 在索引中位置靠后，仍大概率失效；
• 但真实影响取决于数据分布和优化器成本估算。实测中，>= 有时能让 key_len 多几个字节，说明它确实多用了一点索引字段；
• 这不是语法保证，而是优化器权衡结果。不能依赖 >= “修复”右侧字段失效，它只是副作用更友好一点。

怎么验证某列是否真走了索引

光看 type=range 不够，关键看 key_len 和 Extra 字段：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• key_len 值要和你预期的索引字段字节数吻合（比如 VARCHAR(32) utf8mb4 最多占 128 字节，加 2 字节长度头）；
• 如果 key_len 比联合索引总长小，说明右侧字段没被用上；
• Extra 出现 Using index condition 表示用了索引下推（ICP），但仅限于 LIKE 'xxx%' 或函数条件等场景，> 条件本身不触发 ICP；
• 出现 Using where 且没 Using index，基本意味着回表 + 右侧字段过滤靠 CPU 完成。

真正有效的修复方式不是换符号，而是调顺序

最左前缀 + 等值优先 + 范围收尾，才是联合索引设计铁律。不要试图用 >= 或覆盖索引“补救”错误顺序：

• ❌ 错误索引：KEY idx_time_user (create_time, user_id) → 查询 WHERE create_time > '2026-01-01' AND user_id = 'abc' 中 user_id 必然失效；
• ✅ 正确索引：KEY idx_user_time (user_id, create_time) → user_id 等值精准截断，create_time 在子集内 range 扫描，全程走索引；
• 如果业务必须高频查时间范围 + 多个其他字段，考虑拆成多个针对性联合索引，而不是堆砌大而全的索引。

范围条件本身不破坏索引，破坏的是你建索引时没想清楚“谁该先筛、谁该后筛”。这个逻辑错位，比任何 SQL 写法都难调试。