索引合并不是电商范围查询的首选方案，而是联合索引设计失当后的次优补救；应优先按高频查询模式建立覆盖全部过滤条件的联合索引，避免依赖index_merge带来的多次I/O与归并开销。
索引合并不是加速电商范围查询的首选方案，它通常是联合索引设计失当后的次优补救手段。 在商品列表页、价格区间筛选、时间范围+类目组合等典型电商查询中，index_merge 往往意味着你本该建一个覆盖全部过滤条件的联合索引，却只建了多个单列索引——结果 MySQL 被迫用更重的归并逻辑来“凑合”执行。
为什么 EXPLAIN 显示 index_merge 但查询仍慢
常见错误现象是：看到 type=index_merge 和 Extra=Using union(...) 就以为“用了索引”，实际性能可能比单个高效联合索引差 3 倍以上。
- MySQL 需要分别扫描多个二级索引，取出各自满足条件的主键，再做归并（排序或集合运算），最后统一回表——这涉及多次随机 I/O 和内存归并开销
- 如果任一索引返回的主键集很大（比如
price BETWEEN 0 AND 5000匹配 80% 商品），归并后仍要回表大量数据，key_len小、rows高、Extra出现Using where就很典型 - 优化器在数据量小（如测试表只有百条）时可能压根不选
index_merge，导致你本地验证失效；生产环境大表才暴露问题
哪些电商 WHERE 条件容易误触 index_merge
以下写法在已有 idx_price、idx_category_id、idx_status 等单列索引时，极易触发 index_merge_union 或 index_merge_intersection：
-
WHERE category_id = 123 AND price BETWEEN 99 AND 299→ 应建INDEX(category_id, price)，而非两个单列索引 -
WHERE status = 'on_sale' OR is_new_arrival = 1→ 若两者选择性都低，index_merge_union效率远不如全表扫描 + 条件过滤 -
WHERE (category_id = 123 OR tag_id IN (4,5)) AND create_time > '2026-01-01'→ 这种混合逻辑易走sort_union，但归并排序成本高，且create_time范围结果若无序，无法利用 ROR 优化
强制跳过 index_merge 的实操方法
当确认联合索引更优，但优化器仍选错执行计划时，可用以下方式干预：
- 用
FORCE INDEX指定唯一期望的联合索引：SELECT * FROM products FORCE INDEX(idx_category_price) WHERE category_id = 123 AND price BETWEEN 99 AND 299; - 禁用索引合并优化器开关（全局或会话级）：
SET optimizer_switch='index_merge=off';—— 注意这会影响所有查询，仅建议在已验证联合索引全覆盖的场景下临时使用 - 删除冗余单列索引，只保留真正必要的联合索引和主键，避免优化器“有得选”：
DROP INDEX idx_price ON products;（前提是idx_category_price已存在）
真正该优先做的：按电商查询模式建联合索引
电商查询极少孤立使用单字段，高频组合才是建索引的依据。例如：
- 商品列表页：常为
WHERE category_id = ? AND status = 'on_sale' ORDER BY sort_score DESC LIMIT 20→ 建INDEX(category_id, status, sort_score)，注意sort_score必须升序/降序与查询一致 - 价格筛选页：用户拖动滑块，
WHERE price BETWEEN ? AND ? AND brand_id IN (?, ?, ?)→ 若brand_id是离散值，优先建INDEX(price, brand_id)；若品牌数极多，考虑INDEX(brand_id, price)更利于等值+范围 - 搜索后筛选：
WHERE MATCH(title) AGAINST(...) AND category_id = ? AND is_promotion = 1→ 全文索引无法参与index_merge，必须确保category_id和is_promotion覆盖在同一个联合索引中，否则全文检索后还要二次过滤
复杂点在于：范围条件（BETWEEN、>）会截断其右侧所有字段的索引查找能力。所以 INDEX(category_id, price, sort_score) 中，sort_score 只能用于排序，不能用于等值过滤；若还需 WHERE ... AND sort_score > 80，就得把 sort_score 换到 price 左侧，或者拆成两个索引权衡。
