搜索页平均要五秒才出结果,慢查询日志里那条前置通配符的 LIKE 每次都扫完整张文章表,翻页更慢。乍看像缓存或者权限的锅,追下去往往不是。

EXPLAIN SELECT ID FROM wp_posts
WHERE post_content LIKE '%缓存%';
-- type=ALL 表示全表扫描

追下去是这么回事:前置通配符让索引完全用不上,每次搜索都是全表扫描,还要在长正文上反复做字符串比对,数据一多就顶不住,并发上来更明显。

碰到「搜索查询性能」这类问题,我习惯先把当前配置原样备份一份,改坏了立刻换回来,不用现场推。接口问题先分清是没发出去、发出去了没收到,还是收到了处理失败。

偶发问题先统计频率,一小时几次和一天一次,查法完全不同。改完顺手把文档补一句,省得下次自己重新推一遍。

具体做法是,先看慢查询日志,确认这条语句到底扫描了多少行;把全文匹配交给专用的索引表,别直接去查正文;缩小参与匹配的字段范围,只查标题和摘要就够。

验收就看一点,搜索页响应降到一秒以内,执行计划里也不再出现全表扫描。

作者 9823189