mysql优化or查询应优先用union all替代，确保每个子查询独立走索引；若任一分支无索引或含函数/范围查询，优化器会因成本过高弃用索引转全表扫描。
OR条件让MySQL优化器放弃索引，不是因为语法错，而是成本太高
MySQL优化器不会“拒绝”OR，它会算账：走索引再回表 + 合并结果，和直接全表扫描比，哪个I/O更便宜？在多数真实场景下，前者代价更高。因为回表是随机I/O，而全表扫描是顺序I/O；默认配置中，一次随机I/O的成本≈数次顺序I/O。只要OR分支中任一条件命中行数稍多，优化器就倾向选ALL。
EXPLAIN里type=ALL但possible_keys有值，说明索引“存在却不用”
看到possible_keys非空但key为NULL、type是ALL，就是典型“有索引但没走”。这不是bug，是优化器主动放弃。常见触发点包括：
-
OR连接的字段索引类型不一致（比如一个是主键，一个是普通二级索引） - 某个
OR分支含函数、IS NULL、隐式类型转换（如phone = 13800000000把字符串当数字比） - 跨字段范围查询混用，例如
created_at > '2025-01-01' OR status IN (1,2,3)——范围条件无法参与index_merge
UNION ALL替代OR时，每个子查询必须能独立走索引
拆成多个SELECT再UNION ALL，本质是把“一个难优化的查询”变成“多个易优化的查询”。但前提是每个子句本身能命中索引：
- 确保每个
WHERE子句只涉及单个已建索引的字段，且为等值查询（=、IN） - 避免在子查询里加
ORDER BY或LIMIT，否则可能干扰索引选择 - 如果原始OR本就包含
AND逻辑（如(a=1 AND b=2) OR (a=3 AND c=4)），拆分后要保持语义完整，不能只提字段名漏掉关联条件
示例：SELECT id FROM orders WHERE status = 1 OR category_id = 5 → 改为：SELECT id FROM orders WHERE status = 1 UNION ALL SELECT id FROM orders WHERE category_id = 5，前提是status和category_id各自有单列索引。
别迷信“两个字段都有索引就一定OK”
即使phone和email都建了单列索引，WHERE phone = ? OR email = ?仍大概率走全表扫描。原因在于：MySQL默认一次查询只用一个索引；要启用index_merge，必须同时满足——所有OR分支都是等值查询、无函数、无NULL判断、各字段索引独立有效、且优化器估算合并成本低于全表扫描。现实中，最后一个条件最容易失败。
真正容易被忽略的是：索引存在 ≠ 查询可用。验证永远从EXPLAIN开始，而不是从“我建了索引”开始。
