同时创建A-B与B-A索引是否冗余？能否用A-B+B索引替代？

你的思路没问题——用A-B复合索引加单独的B索引（也就是你说的"A-B+B"方案），绝大多数时候都能替代同时建A-B和B-A两个复合索引，还能减少维护成本。但确实有几个特殊场景得额外考虑：

• 排序性能瓶颈
  如果你的查询经常需要按B、A顺序排序（比如ORDER BY B, A），B-A复合索引可以直接满足排序需求，数据库不用额外做文件排序。但只靠A-B索引的话，数据量大时，数据库得先过滤再排序，性能会差不少。

• 高频B前缀查询+回表问题
  要是有大量仅用B过滤的查询（比如WHERE B = ?），而且查询需要返回A字段，B-A复合索引能直接覆盖查询（不用回表查原数据），但A-B索引做不到，这时候B-A的性能优势很明显——哪怕你有单独的B索引，也得回表拿A的数据。

• 特定覆盖索引需求
  如果查询是WHERE B = ? AND A = ?，同时还要返回其他字段，B-A索引可以把这些字段也包含进去（做成覆盖索引），全程不用碰原表；但A-B索引做不到这一点，得回表读取数据，IO开销会更大。

• 数据库优化器的“固执”
  有些数据库的优化器在处理WHERE B = ?这类查询时，可能不会主动选择A-B索引，哪怕理论上可以用，反而会走全表扫描或者其他低效索引。这种情况下，B-A索引能强制优化器选对执行路径。

说白了，你的方案在常规场景下足够高效，但如果碰到上述高频排序、特定覆盖查询或者优化器不给力的情况，B-A索引可能还是得加上。

内容的提问来源于stack exchange，提问作者George Andersen