标签频道
慢查询治理
该标签下的文章、提问与讨论帖。
背景 做了 5 年 DBA，日常治理慢查询时我习惯用 "max_execution_time"（MySQL 8.0.22+，单位 ms）做"安全阀"：给一条已知可能跑飞的批量 UPDATE 设 2s 上限，超时直接 KILL，避免一条慢 S
【背景】 我是 DBA，3 年经验，主要做数据库设计与慢查询治理。主库 MySQL 8.0.32（社区版，InnoDB，单主 16C64G，innodb_buffer_pool_size=32G），核心业务表 "t_report_src"
背景 我负责一套 MySQL 8.0.32 / InnoDB 的核心库（单主 32C128G，buffer pool 48G，核心表 2 亿行级别）。慢查询治理是每周例行动作，阈值 "slow_query_time=0.5s"。最近一个月慢
背景： 我做消息中心的 IM 服务，核心表 "t_message"（InnoDB，MySQL 8.0.32），约 3.2 亿行，单表 210GB，NVMe。字段："id"(bigint 自增 PK)、"sender_id"(bigint)、
«结论先行：MySQL 8.0.13+ 的表达式索引（Functional Index）让 "WHERE UPPER(email) = ?"、"WHERE JSON_EXTRACT(payload, '$.status') = ?"、"WH
«结论先行：千万行级批量 UPDATE 里，「每批 N 万行 + 批间 sleep X ms」的两个数都是拍脑袋的输入，真正的输出是「每批在 buffer pool 里砸出多少脏页」——批大小应该由 buffer pool 容量 × 允许的
«结论先行：多表 JOIN 慢，十有八九不是「表太大」，而是优化器选错了「驱动表（外层表）」——它把过滤后仍剩千万行的大表放外层，让内表被嵌套循环扫描了千万次。这类问题 EXPLAIN 的 "rows" 看着都「正常」，真正的破绽藏在 "t
【背景】 做了 15 年 DBA，联合索引的列序设计几乎天天碰。社区里"加索引 vs 改 SQL"的取舍（id=1581 的讨论、id=19 的三件套文章）我已经看过了，方向没有分歧。但我想把问题再聚焦一层：不是"加不加"，而是"列怎么排"
«结论先行：EXPLAIN 的 "rows" 列不是「这条 SQL 要扫多少行」，而是 InnoDB 用「采样页估算的基数」除以「等值条件值个数」算出来的一个期望值。当数据分布严重倾斜、且你那个「头部值」恰好落在没被采样的页里时，"rows
【背景】 我负责一张 MySQL 8.0.32 / InnoDB 的结算流水表 "t_settlement"，约 1.2 亿行、单表约 60GB，PK=id，现有 4 个二级索引。近两个月每天约 35% 的行被批量 UPDATE statu
«结论先行：复合索引的列顺序不是「按选择性从高到低排」，而是被「等值列 → 范围/排序列 → 覆盖列」这三段结构锁死的。我见过太多团队把高选择性列放第一列、结果 "type" 还是 "ALL"；也见过有人为了省回表把大字段塞进索引，反而把
【背景】 MySQL 8.0.32 / InnoDB，单主 32C128G，innodb_buffer_pool_size=96G。核心表 t_settlement 约 1.2 亿行，当前含 PK + 4 个二级索引（idx_merchan
背景 我负责一套 SaaS 多租户订单库，MySQL 8.0.36（InnoDB，16C64G，buffer_pool 48G），核心表 "t_order" 约 1.2 亿行，联合索引 "idx_tenant_time (tenant_id
一、现象：索引没问题、统计信息没问题，但点查就是慢了 1000 倍 今年 3 月给一套供应链结算系统做慢查询治理。核心表 "t_settle_detail"：MySQL 8.0.36、InnoDB、单表 8.4 亿行、表 + 索引合计 31
«结论先行：「给大表加列」和「给大表加索引」是两条完全不同的成本曲线。加列在 MySQL 8.0 上多数场景可以走 INSTANT——只改元数据、不重建表、不回填数据，1.8 亿行的表也能 0.4s 完成、对业务 DML 零阻塞；但它有一道
【背景】 MySQL 8.0.32 / InnoDB，生产主库 64C/256G，"innodb_buffer_pool_size=128GB"（3 个 instance），NVMe SSD（Intel P5510 3.84TB）。核心表
背景 SaaS 工单系统，主库 MySQL 8.0.32（InnoDB，32C128G，"innodb_buffer_pool_size=96G"，NVMe 本地盘），核心表 "t_ticket"： - 规模：8800 万行、单表 112G
«结论先行：高频 UPDATE 低选择性列时，真正的瓶颈不是 CPU、不是主键索引，而是「二级索引 B+ 树的随机 I/O + 页分裂」，而 InnoDB 用来吸收这类成本的机制叫 change buffer，它的命中率直接决定你的 P99
«结论先行：InnoDB 默认行格式 COMPACT 下，超过 768 字节的 TEXT/BLOB/JSON 列会被"内联前 768 字节 + 20 字节 off-page 指针"塞进主行，既把每页能装的热行稀释到 1/7，又让点查在 bu
背景 MySQL 8.0.32 / InnoDB，一张 900 万行的工单表 "t_ticket"，有两个单列索引： - "idx_priority"（INT，分布极不均匀：P1 占 1.2%、P2 占 8%、P3 占 90.8%） - "
已经到底了
文
标题
摘要