标签频道
慢查询治理
该标签下的文章、提问与讨论帖。
结论先行： InnoDB 统计信息漂移是执行计划漂移的根源，而执行计划漂移是性能退化的隐形杀手。通过构建「批跑免疫区」，关闭 auto_recalc、在批跑完成后手动 ANALYZE（高采样精度），配合 performance_schema
【背景】 作为 DBA，我常在高并发场景下面对索引设计的两难： - 粗粒度索引（如主键）能扛住 10w QPS，但慢查询占比 30% - 细粒度联合索引（如 (user_id, timestamp)）能降 90% 慢查询，但维护成本翻倍 【
背景 我们使用 H2 数据库管理一个日志审计系统，核心表 "t_audit_log" 规模达到 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业务方反馈该表的某高频
现象或背景 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。 先给一个具体的数：我们库
背景：我们正在管理一个 MySQL 8.0 多租户库，核心表约 2.8 亿行，单主 32C128G，头部租户占 41%。日常运行中，我们发现部分 SQL 的执行计划在不同租户参数下不一致，出现计划漂移（plan drift）现象。这导致部分
背景 做了 5 年 DBA，日常治理慢查询时我习惯用 "max_execution_time"（MySQL 8.0.22+，单位 ms）做"安全阀"：给一条已知可能跑飞的批量 UPDATE 设 2s 上限，超时直接 KILL，避免一条慢 S
结论先行 **MySQL 8.0.13+ 的表达式索引（Functional Index）让 "WHERE UPPER(email) = ?"、"WHERE JSON_EXTRACT(payload, '$.status') = ?"、"W
«结论先行：慢日志（slow_log）/ performance_schema 里的 "query_time" 是「从收到语句到返回结果」的墙钟时间，它把等锁的挂起时间原封不动算进去了。你按 query_time 排 Top N 去优化，很
«结论先行：InnoDB 二级索引的"膨胀"（叶子页数远超理论值）是长期运行最容易被漏诊的隐性成本——它不产生慢日志、不触发任何告警，但会让随机写页分裂从 0.3% 涨到 11%，UPDATE 改索引列时 P99 从 4.2ms 爬到 31
结论先行 「先修哪条」不该拍脑袋，应该算出来。 我在 4000 万行的 "t_trade_order" 上治 23 条慢 SQL、人手只够修 3 条的场景里，把优先级拆成了一个三因子公式： "Score = 影响分(链路 × 缓存兜底 ×
【背景】 做了 8 年 DBA，最常被开发同学拿来"拍板"的一句话是："这个 SQL 慢，你加个索引不就完事了？" 我见过太多这样的链路： - 一个订单列表接口，一次请求拆成 12 条子查询（N+1 的变体），单条 P50 只有 3ms，但
背景 我负责一套 SaaS 多租户计费系统，主库 MySQL 8.0.36（云 RDS，16C64G，"innodb_buffer_pool_size=48G"）。核心表 "t_invoice_item" 约 2.3 亿行，有一条按 "te
背景 MySQL 8.0.32 / InnoDB，单主 32C/128G，"innodb_buffer_pool_size=64G"。核心表 "t_msg_log" 约 1.2 亿行，PK=id，二级索引 "idx_user_ts (use
«结论先行：INPLACE 加索引不是「跑起来就完事」，它有三个压力特征完全不同的阶段（FLUSH → index build 回填 → commit MDL），每个阶段该盯的指标、判停阈值都不一样。我这次把 10 年里积累的判停经验整理成
«结论先行：「走了索引」只说明第一跳（二级索引页）是热的，不说明第二跳（聚簇索引数据页）是热的。当二级索引小、聚簇索引大、buffer pool 装得下索引却装不下数据时，点查会稳定落在「索引命中 + 回表随机 I/O」的半命中区间——EX
【背景】 15 年 DBA，最近在给一套结算系统（MySQL 8.0.32 / InnoDB，单主 16C64G，buffer_pool 40G）做索引治理。核心表 t_settle_bill 约 6500 万行、单表 41GB，写 QPS
背景 我是一名技术文档工程师，日常在帮 30 人数据团队搭指标体系（上一篇《指标字典不是文档是断言》讲过指标断言的落地）。现在接手一个新课题：给一个 MySQL 8.0.36 / InnoDB 多租户核心库（单主 32C128G，核心表 2
背景 MySQL 8.0.32（RDS，32C128G，buffer_pool 96G），交易流水表 "t_txn" 约 2.8 亿行，按 "tenant_id" 做 HASH 分区（64 个分区），二级索引 "idx_tenant_biz
背景 我负责一套 MySQL 8.0.36 / InnoDB 多租户核心库（单主 32C128G，"innodb_buffer_pool_size=96G"），核心表 "t_order_ext" 约 3.2 亿行，头部租户单租户占全表 41
«结论先行：社区里「IN 改 EXISTS 就快」的说法只对了一半。同一张 860 万行的角色-菜单关联表，决定性能的不是 SQL 写法，而是子查询侧的索引与结果集大小：子查询命中 < 1 万行时三种写法 P99 都在 5ms 内；命中 1
已经到底了
文
标题
摘要