MySQL非等值row constructor（如(a,b)>(x,y)）不走索引，因CBO不将其重写为OR形式；等值匹配则安全且可命中复合索引。

MySQL 子查询中直接用 (col1, col2) = (val1, val2) 是安全且走索引的，但换成非等值比较（比如 >、）就大概率失效——不是语法错，是优化器不改写，索引用不上。

子查询里用 ROW 构造符做等值匹配没问题

多列等值匹配场景下，ROW() 或隐式元组写法在子查询中完全可用，语义清晰，还能命中复合索引：

• WHERE (a, b) = (SELECT x, y FROM t2 WHERE ...) 是合法且高效的，前提是子查询返回单行
• 等价于 WHERE a = (SELECT x ...) AND b = (SELECT y ...)，但更紧凑，也避免了两次子查询执行
• 如果 SELECT x, y 返回多行，会报错 Subquery returns more than 1 row，这是预期行为，不是 bug
• 索引使用取决于外层表的 (a,b) 是否有合适复合索引，和子查询是否能走索引无关

非等值比较如 (a,b) > (1,2) 在子查询中照样不走 range scan

哪怕写在子查询右边，比如 WHERE (a,b) > (SELECT x,y FROM t2 LIMIT 1)，MySQL 依然不会把该条件重写为 a > x OR (a = x AND b > y) —— 所以执行计划里看不到 type: range，大概率退化为全表扫描。

win可用的mysql指令skill

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

下载

• 错误现象：SQL 逻辑正确、结果对，但 EXPLAIN 显示 type: ALL 或 type: index
• 根本原因：CBO（Cost-Based Optimizer）不处理非等值 row constructor 的范围展开，也不尝试将其下推为 OR 条件
• 别指望加 FORCE INDEX 能救回来，索引结构本身不支持这种字典序跳转的 range 切分
• 替代方案只能手动展开：WHERE a > (SELECT x FROM t2 LIMIT 1) OR (a = (SELECT x FROM t2 LIMIT 1) AND b > (SELECT y FROM t2 LIMIT 1))，但注意子查询重复执行三次，需用变量或 JOIN 重写

用 JOIN 替代子查询 + ROW 构造符更可控

当需要基于多列匹配做关联过滤时，显式 JOIN 比嵌套子查询 + ROW 更易优化、更少踩坑：

• 例如查找“与某用户同部门同职级的所有人”，用 JOIN 写成 ON u1.dept = u2.dept AND u1.level = u2.level，可明确利用 (dept,level) 复合索引
• 而 WHERE (dept,level) IN (SELECT dept,level FROM users WHERE id=123) 虽语法短，但 MySQL 对 IN + 多列子查询的优化有限，尤其数据量大时容易走临时表
• 若子查询结果固定，可先查出值存入变量，再用于 WHERE (a,b) = (@x,@y)，避免重复执行

真正容易被忽略的是：row constructor 的非等值用法在任何上下文（包括子查询）里都不触发 range 计划，它看起来像索引友好操作，实则是个“语法糖陷阱”。宁可多写几行 OR，也不要依赖 (a,b) > (x,y) 自动走索引。