BETWEEN与>/= AND
不是更容易命中——BETWEEN 和 >/ 在联合索引中的命中行为完全一致，不存在“BETWEEN 更容易用上索引”这回事。
WHERE中用BETWEEN还是>/
MySQL 优化器把 BETWEEN a AND b 当作 >= a AND 的语法糖处理，执行计划里走的索引路径、<code>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、>、、<code>>=、、前缀 <code>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 和 >/ 完全平等，没有例外。
