复合索引的最左前缀原则同时影响WHERE过滤、ORDER BY排序和SELECT覆盖；排序字段必须放在索引末尾且仅一个，否则触发Using filesort；范围查询后字段仅能用于排序；IN/OR需谨慎，可用UNION ALL或冗余字段优化；EXPLAIN中key_len和Extra字段是判断索引实际使用的关键；分页应避免大offset，改用游标分页；字段类型不匹配会导致隐式转换和索引失效。
为什么 WHERE a=1 AND b=2 AND c=3 走了索引，但加个 ORDER BY price DESC 就变慢？
因为复合索引的「最左前缀」不仅管 WHERE，还管 ORDER BY 和 SELECT 中的非主键字段。MySQL 只能利用索引中连续的前缀部分做排序——如果 price 不在索引末尾，就无法避免 Using filesort。
电商筛选常见组合如：category_id + brand_id + status + price_range + sort_field。必须把排序字段（如 price 或 created_at）放在复合索引最后，且仅放一个；否则索引失效。
- 错误示例：
INDEX(category_id, brand_id, price, status)→status在price后，WHERE status=1无法走索引 - 正确顺序：过滤字段（高区分度优先）+ 排序字段（仅一个，且放最后）
- 注意：
price BETWEEN 100 AND 500是范围查询，它之后的所有字段都无法用于索引过滤，只能用于排序
IN 列表和 OR 条件会让复合索引失效吗？
会，但有绕过方法。MySQL 5.7+ 对单列 IN（如 brand_id IN (1,2,3)）能用索引，但多列组合 IN（如 (brand_id, category_id) IN ((1,10),(2,10))）不支持；OR 更糟——只要有一个分支没索引，整条 WHERE 就可能退化为全表扫描。
- 替代方案：拆成多个
UNION ALL查询，每个分支走自己的复合索引 - 或改用临时表预存符合条件的
product_id，再关联主表（适合后台导出类场景） - 避免写
WHERE category_id = 1 OR brand_id = 5，这种几乎无法优化 - 如果必须支持多选品牌+多选分类，考虑冗余字段：比如建
category_brand_hash字符串字段存"c10_b5"，然后对它建哈希索引
如何判断你的复合索引是否被真正用上？
别只看 EXPLAIN 的 type=ref，重点看 key_len 和 Extra 字段。它告诉你 MySQL 实际用了索引的前几列。
例如索引是 INDEX(category_id, brand_id, status, price)，而 EXPLAIN 显示 key_len=8（假设前两列都是 INT），说明只用了前两列，status 和 price 没参与过滤或排序。
- 检查
Extra：出现Using index condition是好信号（ICP 启用）；出现Using where; Using index表示覆盖索引；若只有Using where，说明回表严重 - 用
SHOW INDEX FROM products确认索引字段顺序和基数（Cardinality），低基数字段（如status只有 0/1）不宜放最左 - 线上慢查日志里抓真实 SQL，用
EXPLAIN FORMAT=JSON看used_columns，比传统EXPLAIN更准
分页深度大（LIMIT 10000,20）时，复合索引还有效吗？
有效，但效果急剧衰减。MySQL 仍要定位到第 10000 行，即使走了索引，也要“数”够偏移量——IO 和 CPU 成本不低。
- 绝对不要用
LIMIT offset, size做无限滚动；改成基于游标的分页：记录上一页最后一条的(price, id)，下一页查WHERE price - 游标字段必须是复合索引的后缀部分，且顺序与
ORDER BY严格一致 - 如果前端允许“跳转到页码”，可先用
SELECT COUNT(*)预估总页数，但缓存该值，避免每次点页码都 COUNT - 注意：游标分页无法直接跳转中间页，这是权衡——你要的是性能，不是任意页码的语义保证
最常被忽略的一点：复合索引字段的类型必须和查询条件完全一致。比如 category_id 是 TINYINT UNSIGNED，但代码传了字符串 "1"，MySQL 会隐式转换，导致索引失效——查 EXPLAIN 里的 type 是否变成 ALL 就知道了。
