MySQL全文索引与无索引列组合查询性能骤降问题咨询

这种坑我之前踩过！核心问题就是数据库查询优化器选错了执行顺序——明明全文索引能把候选行砍到原来的几十分之一甚至百分之一，但优化器偏偏舍近求远，要么先扫全表处理无索引的x列条件，再在大结果集里跑全文检索；要么逻辑顺序错配，直接把耗时拉满了。

先拆解下背后的逻辑： #

• 单独用MATCH...AGAINST快：因为全文索引直接定位到匹配的行，结果集极小，毫秒级就能出结果。
• 单独查无索引的x列要3秒：这是全表扫描200万行的正常耗时。
• 组合起来反而9秒：说明优化器没按你预想的「先靠全文索引缩小范围，再在小结果集里查x」执行，反而可能先扫全表找符合x的行（3秒），再在这些行里跑全文检索（本来快，但结果集大就变慢），叠加额外处理开销后，耗时直接翻倍还多。

解决方案按优先级来： #

1. 强制优化器先走全文索引

直接用FORCE INDEX指定使用全文索引，让查询先筛选出小结果集，再在这个小范围里检查x的值——就算x无索引，扫几千行和扫200万行完全不是一个量级。

示例SQL（替换成你的全文索引名）：

SELECT * 
FROM your_table FORCE INDEX(users_fulltext_index)
WHERE MATCH(users) AGAINST('你的特定用户关键词' IN BOOLEAN MODE)
AND x = 目标值;

我当时这么改完，直接从10秒降到了0.2秒左右，效果立竿见影。

2. 更新表统计信息

如果优化器判断失误是因为表的统计信息过时（比如数据量变化大但没更新统计），可以手动更新统计信息，让优化器能正确估算两个条件的过滤效率，自动选择最优计划。MySQL里执行：

ANALYZE TABLE your_table;

更新完再跑组合查询，说不定优化器自己就开窍了。

3. 给x列加普通索引（可选，但长期最优）

如果x列的查询频率不低，给它加个普通B-tree索引，单独查x的耗时会直接降到毫秒级，组合查询的效率也会更上一层楼——毕竟两个条件都有索引，优化器怎么选都不会差。

验证执行计划 #

可以用EXPLAIN看看查询到底走了什么逻辑：

EXPLAIN SELECT * FROM your_table
WHERE MATCH(users) AGAINST('特定用户' IN BOOLEAN MODE)
AND x = 目标值;

如果type列显示fulltext，说明先走了全文索引；如果是ALL，那就是全表扫描，这时候就必须用FORCE INDEX来纠正了。

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