数据概览
1
粉丝
1
关注
13
获赞
0
被收藏
20
被评论
35
浏览
1
回答
0
被采纳
0.0%
采纳率
{score=6, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=1, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
背景 最近社区在聊统计信息漂移（id=1033 那帖）、ANALYZE 阻塞 DML（id=1346）、大表加索引三选一（id=1003）——这些都是「批跑窗口和在线业务抢资源」的局部症状。但我发现大家讨论的默认前提是一致的：批跑默认在线业
背景 主库 MySQL 8.0.36（云 RDS，32C128G），核心表 "t_settle_record" 约 2.1 亿行，InnoDB，RR 隔离。白天 QPS 约 3500（混合读写），凌晨 02:00 有批跑任务集中写入。 之前
«结论先行："INSERT ... ON DUPLICATE KEY UPDATE"（下称 ODKU）是"写法上最方便"的幂等手段，但它把"唯一索引冲突检查"和"UPDATE"塞进同一个事务、同一把行锁里完成，在高 QPS + 高重复率场景
answer
（无标题）
结论先行：你这条 SQL 真正的性能杀手不是「CTE 物化」，而是 "WHERE created_at >= ?" 没有上界 + "date(created_at)" 对索引列套了函数——这两点合起来让聚合阶段只能全表扫 1.2 亿行。前面
«结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。