BETWEEN与>/= AND

不是更容易命中——BETWEEN 和 >/ 在联合索引中的命中行为完全一致，不存在“BETWEEN 更容易用上索引”这回事。

WHERE中用BETWEEN还是>/

MySQL 优化器把 BETWEEN a AND b 当作 >= a AND 的语法糖处理，执行计划里走的索引路径、EXPLAIN 输出的 key 和 rows 值都一样。真正决定联合索引能不能用、用到第几列的，是字段顺序和条件类型，不是写法。

比如联合索引是 (status, created_at)：

• WHERE status = 'paid' AND created_at BETWEEN '2024-01-01' AND '2024-01-31' → 能用上两列
• WHERE status = 'paid' AND created_at > '2024-01-01' → 同样能用上两列
• WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31' → 只能全索引扫描或不用索引（缺最左列 status）
• WHERE created_at > '2024-01-01' → 行为完全相同

真正影响联合索引“用到哪一列”的，是范围查询的位置

只要出现范围查询（包括 BETWEEN、>、、>=、、前缀 LIKE），它右侧的所有字段就无法用于索引查找（只可能参与覆盖索引或排序）。

win可用的mysql指令skill

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

下载

关键不是“用了 BETWEEN”，而是“它出现在联合索引里的第几列”：

• 索引 (a, b, c) 下，WHERE a = 1 AND b > 2 AND c = 3 → 只能用上 a 和 b，c 不参与索引查找（跳过）
• 同个索引下，WHERE a = 1 AND b BETWEEN 2 AND 5 AND c = 3 → 行为一模一样，c 同样失效
• 但如果写成 WHERE a = 1 AND b = 2 AND c > 3 → 这时 c 是范围列，但它在最右，不阻断其他列，所以三列都有效（a、b 精确匹配，c 范围扫描）

为什么有人觉得BETWEEN“更稳”？其实是掩盖了隐式问题

部分人观察到 BETWEEN 在某些场景下“没报错”或“执行计划看起来更干净”，其实是因为它天然规避了两个常见坑：

• BETWEEN 必须写两个确定值，不容易漏掉边界（比如只写 > 忘了补 ，导致语义错误）
• BETWEEN 不会因手误写成 >> 或 这类语法错误，而这类错误会让整个 WHERE 失效退化为全表扫描
• 但注意：BETWEEN NULL AND X 或 X BETWEEN NULL AND Y 全部不成立（NULL 比较返回 UNKNOWN），这种写法表面看着“闭区间”，实际查不到任何数据

最易被忽略的一点：范围查询本身不破坏最左匹配，但一旦它不是联合索引的**最后一列**，后面所有列就彻底失去索引查找能力——这个限制对 BETWEEN 和 >/ 完全平等，没有例外。