会员中心首屏 4.8 秒才出来，慢查询日志里同一页面执行了 20 条结构相同的查询。乍看像缓存或者权限的锅，追下去往往不是。
EXPLAIN SELECT * FROM wp_points_log WHERE user_id IN (1,2,3); SHOW INDEX FROM wp_points_log;
追下去是这么回事：循环里逐条查等级和积分，典型的一对多查询写在 foreach 里。积分表按用户查的那个字段也没有索引。
「等级页查询慢」这类改动最怕改一半，回滚脚本先准备好，再动生产。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，先用执行计划看每条查询走了哪个索引；把循环查询改成一次批量查，用 IN 拿回全部数据；积分表给用户 ID 和创建时间加联合索引；改完再测一次首屏时间，对比慢查询条数。
验收就看一点，首屏降到 1 秒以内，慢查询日志里这个页面不再出现重复查询。