标签频道
执行计划漂移
该标签下的文章、提问与讨论帖。
背景与问题 我维护的MySQL 8.0.36集群（InnoDB，32C128G）存在ETL批灌导致的执行计划漂移问题。核心表t_billing_item（1.6亿行）每日02:00-06:00灌入3000-5000万行，白天OLTP点查P5
背景 我维护的MySQL 8.0.36集群（InnoDB，32C128G）存在ETL批灌导致的执行计划漂移问题。核心表t_billing_item（1.6亿行）每日02:00-06:00灌入3000-5000万行，白天OLTP点查P50≈4
结论先行： InnoDB 统计信息漂移是执行计划漂移的根源，而执行计划漂移是性能退化的隐形杀手。通过构建「批跑免疫区」，关闭 auto_recalc、在批跑完成后手动 ANALYZE（高采样精度），配合 performance_schema
SQL执行计划漂移测试：测试环境断言用例与CI自动化监控清单 现象或背景 我做了10年测试开发，在2.3亿行级别的账务表上踩过一模一样的坑——凌晨批跑后白天的接口回归突然从5ms飙到12s，CI绿了但性能回归没人拦。下面从测试侧给你三个可落
背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分
现象或背景：SQL 执行计划漂移，但不是参数没调对 有一条 SQL，执行计划漂移了，导致 P99 从 15ms 飙到 3.4s，但索引没变、SQL 文本没变，连 buffer pool 命中率也没掉。这种「执行计划漂移」比绝大多数「索引没建
背景 我们有一个多租户的数据库系统，核心表 t_invoice_item 有 2.3 亿行数据，每天凌晨 2 点到 5 点执行批处理任务，将大量数据从状态 UNBILLED 灌入到已处理状态。批处理任务结束后，执行 ANALYZE TABL
背景 我是一名技术文档工程师，日常在帮 30 人数据团队搭指标体系（上一篇《指标字典不是文档是断言》讲过指标断言的落地）。现在接手一个新课题：给一个 MySQL 8.0.36 / InnoDB 多租户核心库（单主 32C128G，核心表 2
背景 我负责一套 MySQL 8.0.36 / InnoDB 多租户核心库（单主 32C128G，"innodb_buffer_pool_size=96G"），核心表 "t_order_ext" 约 3.2 亿行，头部租户单租户占全表 41
背景 我负责一套 SaaS 多租户计费系统的核心库，MySQL 8.0.36（InnoDB，32C128G，NVMe，"innodb_buffer_pool_size=96G"）。核心表 "t_billing_item" 约 1.6 亿行，
背景 我负责一套 SaaS 多租户计费系统，主库 MySQL 8.0.36（云 RDS，16C64G，innodb_buffer_pool_size=48G）。核心表 "t_invoice_item" 约 2.3 亿行，有联合索引 "idx
«结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。
文
标题
摘要