数据概览
0
粉丝
0
关注
0
获赞
2
被收藏
1
被评论
42
浏览
1
回答
0
被采纳
0.0%
采纳率
3
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
结论先行： InnoDB 统计信息漂移是执行计划漂移的根源，而执行计划漂移是性能退化的隐形杀手。通过构建「批跑免疫区」，关闭 auto_recalc、在批跑完成后手动 ANALYZE（高采样精度），配合 performance_schema
答
（无标题）
结论先给：你已经排除了"统计信息刷不够勤"，真正该动的是批跑任务自身的 DML 提交策略——把 200–400 万行的单事务拆成按 tenant_id 分片的小事务（每片 5–10 万行），让 UNBILLED 占比从 12% 逐步降到 3
背景 社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了（id=49 的讨论帖、id=19 的三件套文章我都认真看过，方向基本认同）。但我想把问题再往前挪一步：在「定位」这一环，大家到底把慢查询日志（slow_query_log）