标签频道
统计信息
该标签下的文章、提问与讨论帖。
背景与问题 我维护的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
K8s CronJob 自动刷新 InnoDB 统计信息：零代码侵入的运维方案与量化判据 一、现象或背景 在云原生架构下，MySQL 8.0 的 InnoDB 统计信息自动刷新机制（"innodb_stats_auto_recalc"）常导
结论先行： InnoDB 统计信息漂移是执行计划漂移的根源，而执行计划漂移是性能退化的隐形杀手。通过构建「批跑免疫区」，关闭 auto_recalc、在批跑完成后手动 ANALYZE（高采样精度），配合 performance_schema
背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分
背景 我们有一个多租户的数据库系统，核心表 t_invoice_item 有 2.3 亿行数据，每天凌晨 2 点到 5 点执行批处理任务，将大量数据从状态 UNBILLED 灌入到已处理状态。批处理任务结束后，执行 ANALYZE TABL
背景 我负责一套 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 亿行，
«结论先行：EXPLAIN 的 "rows" 列不是「这条 SQL 要扫多少行」，而是 InnoDB 用「采样页估算的基数」除以「等值条件值个数」算出来的一个期望值。当数据分布严重倾斜、且你那个「头部值」恰好落在没被采样的页里时，"rows
背景 我负责一套 SaaS 多租户订单库，MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 "t_order" 约 1.2 亿行，联合索引 "idx_tenant_time (tenant_id
背景 我负责一套 SaaS 多租户系统的核心订单库，MySQL 8.0.32（InnoDB，16C64G，NVMe SSD，"innodb_buffer_pool_size=48G"）。核心表 "t_order" 约 6200 万行、单表含
背景 主库 MySQL 8.0.36（云 RDS，32C128G），核心表 "t_settle_record" 约 2.1 亿行，InnoDB，RR 隔离。白天 QPS 约 3500（混合读写），凌晨 02:00 有批跑任务集中写入。 之前
背景 我负责一套 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）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。
背景：MySQL 8.0.36，InnoDB，一张约 5000 万行的日志表 access_log，主键 id，二级索引 idx_path (path)，idx_path_status (path, status)，idx_time (cr
文
标题
摘要