标签频道
慢查询治理
该标签下的文章、提问与讨论帖。
背景 我负责一套 SaaS 计费系统，主库 MySQL 8.0.32（InnoDB，16C64G，"innodb_buffer_pool_size=48G"），核心表 "t_billing_item" 约 1.8 亿行。表上有 5 个二级索
«结论先行：MySQL 8.0.3 起 "innodb_change_buffering" 默认从 "all" 改成了 "none"，绝大多数 8.0 新实例上「二级索引写合并」根本没开。对持续 INSERT 的流水表（非唯一二级索引、写入
背景 我负责一套 MySQL 8.0.32 / InnoDB 的订单核心库，单主 64C256G，"innodb_buffer_pool_size=64GB"，"innodb_lru_scan_depth=256"（默认值）。核心表 "t_
背景 我负责一套物流轨迹系统的 MySQL 8.0.36（单主 32C128G，innodb_buffer_pool_size=96G），核心表 "t_track" 约 1.8 亿行、数据文件 320GB，删除密集——每天约 25% 的行被
«结论先行：从库延迟不是"网络慢"，而是主库一条 2,348,000 行的大事务被从库单线程 SQL 线程串行回放。修它有三条路——拆事务（治本）、开 MTS 并行回放（缓解）、分库（重锤），三者各有代价，不能只挑一个。» 一、现象：凌晨对
【背景】 我这两年在大厂数据平台组，一个反复出现的场景：业务方既要在线交易（下单、查订单详情，P99 要求 50ms 内），又要跑分析型查询（按商户/时间维度聚合上千万行流水、环比同比、导出报表）。很多时候这两类查询落在同一个 MySQL
【背景】 我负责一套任务调度系统的慢查询治理，主库 MySQL 8.0.32（单主 16C64G，innodb_buffer_pool_size=48G，redo log 默认大小），核心表 t_task 约 6500 万行、当前含 PK
«结论先行：覆盖索引不是免费的午餐，它的收益是「省回表」，账单是「索引膨胀 + 写放大 + buffer pool 装得下更少的行」三笔。这三笔账里前两笔你在建索引时看得见，第三笔（缓存效率下降）往往要过两周、被别的查询拖慢后才暴露。我 1
一、现象：「更安全」的工具反而更慢、更贵 去年给一套 ERP 系统做索引补建。核心表 "t_voucher_entry"（凭证分录表）规模：5280 万行、单表 11.7GB、InnoDB、MySQL 8.0.36、8C16G 云主机、SS
«结论先行："utf8mb4_general_ci" 和 "utf8mb4_0900_ai_ci" 都是「utf8mb4」，但它们是两套不同的比较规则（collation）。跨库 JOIN 时 collation 不一致，要么直接报 "Il
背景 我在维护一套 MySQL 8.0.32 的订单系统，核心报表查询里大量使用 CTE（WITH ... AS）来组织多表关联逻辑。最近遇到一个反复出现的执行计划漂移问题，想请教社区有实际经验的 DBA。 现象 一条典型 SQL 结构如下
«结论先行：分区表不是"大表救星"，而是一笔用"跨分区查询更慢 + 唯一键受限 + 每月必维护"去换"分区裁剪快 + 删历史秒级"的交易。该不该做，取决于你的读写是否天然按时间切分。下面是一次真实的改造复盘，把收益和代价都摆到明面上算账。»
【背景】 我负责一张 800 万行的订单宽表（InnoDB, MySQL 8.0.32），带 6 个二级索引。业务上每天约 30% 的行会被批量 UPDATE status 字段，持续一个月后观察到查询性能明显退化。 【现象】 1. SHO
一、现象：一条 2ms 的权限校验，突然飙到 103ms 去年 Q4 给一套电商后台做慢查询巡检。核心链路是「登录用户 → 拉菜单列表」，SQL 长这样： SELECT m.menu_id, m.menu_name, m.parent_id
«结论先行：深分页慢的根因不是「数据多」，而是 MySQL 优化器对 "ORDER BY … LIMIT m,n" 的处理策略——它必须把排序结果完整物化（或走排序索引顺序扫描）到第 m+n 行才肯截断，前 m 行的扫描成本是纯浪费。把「页
一、现象：一条"看起来很简单"的查询，P99 卡在 1.8s 去年我们迁移订单中心到 MySQL 8.0.32，主表 "orders" 约 2.1 亿行，单表 190GB。客服后台有一个高频接口：查某用户最近的 20 条订单： SELECT
«结论先行：索引没变、SQL 没变、buffer pool 命中率也没掉，但 P99 还是从 15ms 飙到了 3.4s——根因是 InnoDB 的统计信息（cardinality）在数据批量写入后严重失真，优化器据此选错了索引/访问路径。
文
标题
摘要