含OR子句的MyISAM表查询性能低下问题及优化咨询

哈哈，这个问题我太熟悉了！之前帮朋友排查过几乎一模一样的情况，咱们先把原因掰扯清楚，再给你几个落地的优化方案：

首先得说MyISAM这个老引擎的“脾气”——它对带OR的复合条件索引支持真的很拉胯。你虽然给colA、colB、colC都建了单列索引，但当查询里出现(colB='123' OR colC='123')这种分支条件时，MySQL没办法高效地把这三个单列索引组合起来用：

• 要么它只会用colA的索引先过滤出colA='ABC'的行，然后再逐行去检查colB或colC是否等于123，100万行的话，回表扫描的开销直接拉满，这就是为啥慢到10秒；
• 要么它尝试做索引合并，但MyISAM的索引合并效率极低，甚至有时候会直接放弃，干脆走全表扫描，那速度能快才怪。

而你拆分后的两个查询就不一样了：每个都是colA='ABC' AND colX='123'，哪怕你只有单列索引，MySQL也能先用colA的索引过滤出小结果集，再快速筛选colB/colC；如果有(colA, colB)这种联合索引，那直接就能通过索引定位到目标数据，根本不用回表，所以0.002秒就搞定了。

给你三个不同维度的方案，按需选择：

• 优先加联合索引（最彻底的优化）
  给表创建两个联合索引：

  CREATE INDEX idx_a_b ON table(colA, colB);
  CREATE INDEX idx_a_c ON table(colA, colC);
  

  加完之后，原查询就能通过MySQL的索引合并特性，分别用这两个联合索引找到符合条件的行，再合并结果，速度会直接跟拆分后的查询看齐。
  （别想着建(colA, colB, colC)这种三列索引，对这个查询没用，因为OR条件会打断索引的连续匹配）

• 不改表结构，改写查询
  如果你暂时没法加索引，就把原查询改成用UNION ALL拼接两个高效子查询：

  SELECT * FROM table WHERE colA='ABC' AND colB='123'
  UNION ALL
  SELECT * FROM table WHERE colA='ABC' AND colC='123';
  

  这个写法和你手动拆分查询的逻辑完全一致，MySQL会分别执行两个快查询，再合并结果。要是担心有重复行（比如某一行同时满足colB和colC都是123），就把UNION ALL换成UNION，不过会多一步去重，速度稍微降一点，但还是比原查询快N倍。

• 长远方案：换InnoDB引擎
  MyISAM真的是老古董了，不支持事务、行级锁，索引优化能力也远不如InnoDB。如果你的业务场景允许（比如不需要全文索引的旧特性，或者可以用InnoDB的全文索引替代），把表迁移到InnoDB，这类带OR的查询性能会有质的提升——InnoDB的索引合并、自适应哈希索引等特性，对这类场景的支持要好得多。

内容的提问来源于stack exchange，提问作者R C