Google Cloud SQL中多条件WHERE查询比分步查询慢的原因排查

这是个非常典型的索引使用场景问题，我来帮你拆解背后的逻辑和解决办法：

先分析单独查询的高效原因 #

• A = valueA 查询：因为A列有单独索引，InnoDB的B+树索引对等值匹配支持非常好，能直接定位到所有符合条件的记录，几乎是瞬间找到512998条数据，所以耗时仅0.18秒完全合理。
• B like "%input_string%" 查询：这里你可能以为用到了B列的索引，但实际上like "%xxx%"这种前缀模糊匹配是无法利用B列的普通索引的——因为InnoDB的索引是按字符顺序排序的，前缀不确定的话，数据库没法通过索引快速定位，只能做全表扫描筛选符合条件的记录。不过你的表只有51万条数据，全表扫描耗时1.43秒也在预期内。

组合查询慢的核心原因 #

当你把两个条件组合起来时，MySQL优化器会选择看起来成本更低的执行计划：它会先用A列的索引快速定位到512998条符合A=valueA的记录，但问题来了——A列的索引里只存储了A的值和主键id，要判断这些记录的B列是否符合like条件，数据库必须通过主键id去主键索引（聚簇索引）里查询对应的B列值，这个过程叫做「回表查询」。

想象一下：要对51万条记录逐一做回表操作，这意味着51万次随机IO，这是非常耗时的，最终导致总耗时达到9.64秒。

解决办法：建立覆盖型复合索引 #

最直接的优化方案是创建包含A和B的复合索引，让数据库不需要回表就能完成查询：

CREATE INDEX idx_A_B ON `table`(A, B);

这个复合索引的结构是先按A排序，再按B排序。查询时，数据库会先通过A的等值匹配快速缩小范围，然后直接在索引里读取B的值进行like筛选——全程不需要回表，能把查询耗时降到和单独查询A差不多的级别。

你可以用EXPLAIN命令验证优化效果：

EXPLAIN select count(*) from `table` where A = valueA and B like "%input_string%";

如果看到Extra字段里出现Using index，说明数据库已经用上了覆盖索引，不需要回表了。

内容的提问来源于stack exchange，提问作者Andres Biarge