慢查询

做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。 我见过太多团队把"加索引"

【背景】 我在一个订单中心做慢查询治理，主库 MySQL 8.0.32（单主 16C64G，innodb_buffer_pool_size=48G），核心表 orders 约 2.2 亿行，二级索引 idx_uid_created (uid

«结论先行：MySQL 里最「安静」的杀手不是行锁，而是 MDL（Metadata Lock，元数据锁）——它不抢数据、不抢 CPU，但能让一张表的所有 DML 集体排队，连接池在 10 分钟内被打满，且 "SHOW PROCESSLIST

背景： 我做了 8 年大数据平台，最近复盘一次事故：凌晨一个 BI 报表任务扫了 40GB 未命中的分区，把共享查询引擎的内存打爆，连带拖垮了两条在线服务链路。事后我们上了「查询级超时 + 资源配额 + 优先级队列」，但团队内部吵了一架：数

背景 做了 5 年 DBA，被问得最多的一句话是："这条 SQL 慢，你给加个索引不就完了？" 但换个场合，领导又会说："DBA 是要兜底整个库的性能的。" 这两句话同时成立，就变成 DBA 一个人既当裁判又当运动员：既要劝业务方改写法，又

结论先行：慢查询里有一类最「安静」的杀手，是隐式类型转换——它让 EXPLAIN 里的 "type" 从 "ref"/"range" 退化成 "ALL"、"key" 列直接变 "NULL"，而 SQL 里你根本看不出任何「错别字」。字段是

背景 社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了（id=49 的讨论帖、id=19 的三件套文章我都认真看过，方向基本认同）。但我想把问题再往前挪一步：在「定位」这一环，大家到底把慢查询日志（slow_query_log）

背景 做了 3 年 DBA，治理慢查询时最常撞见的一类场景是：业务方拿着一张几千万甚至上亿行的流水表，让运营看板「实时」出聚合结果（今日 GMV、分渠道转化、库存周转），SQL 写得再漂亮，本质还是在扫大表。而社区里对「该不该预聚合」的立场

背景：MySQL 8.0.34，InnoDB，业务库有一张订单流水表 t_order_flow（约 1.2 亿行，PK=id，二级索引 idx_merchant_time (merchant_id, created_at)、idx_stat

背景：订单表 t_order 约 4200 万行，InnoDB，MySQL 8.0.32，已建联合索引 idx_ab (a, b)，其中 a 是商户ID（高基数，单值查询命中 200~3000 行不等），b 是创建时间（datetime）。

背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT

一、现象：一个"数数"接口把从库拖到 9 秒 先说结论：在 InnoDB 里，"SELECT COUNT(*) FROM t" 不是"数个数"，而是全表扫描——它要顺着聚簇索引把整张表的行一条条走一遍才能得出一个数。 我们内部有个"资产总览

【背景】 我们是一套 MySQL 8.0.32 / InnoDB 的订单查询服务，核心表 t_order 约 5200 万行、单表 9.8GB（含二级索引）。高频查询按 (merchant_id, status, create_time)

一、现象与背景：加了索引，P99 反而涨了 30% 上个月给一套订单系统做慢查询治理。核心表 "t_order" 规模：1200 万行、单表 3.1GB、InnoDB、MySQL 8.0.32。业务方甩来一条高频查询： SELECT id,

背景 社区里已经有一篇讲「慢查询治理三件套顺序」的文章，把「先定位 → 再判断 → 最后加索引/改写」讲得很清楚，我基本认同。但真正到动手那一刻，我发现团队里吵得最凶的其实不是「顺序」，而是同一类慢查询，到底用哪条路去解：加索引、改写 SQ

背景：MySQL 8.0.36，InnoDB，一张约 5000 万行的日志表 access_log，主键 id，二级索引 idx_path (path)，idx_path_status (path, status)，idx_time (cr

结论先行 先给结论：订单列表接口 P99 从 340ms 压到 52ms，靠的不是加机器，而是把 "filesort" 从"磁盘临时表"拉回"内存排序"。两个关键旋钮是 "sort_buffer_size" 和 "priority_sort

背景：MySQL 8.0.36，主从架构（单主 + 1 从，半同步），主库一台 16C/64G/ESSD，从库同规格。业务在每天 02:00–03:30 跑一次订单归档批处理：把 orders 表里 create_time 早于 90 天的

背景：MySQL 8.0.36，InnoDB，一张约 1200 万行的订单表 orders，现有复合索引 idx_a_b_c (a, b, c)，a 是租户 id（bigint，等值），b 是订单时间（datetime，范围），c 是状态（

结论先行 慢查询治理不是「加索引」三个字能糊弄的，正确顺序是：先定位（EXPLAIN + 慢日志）→ 再判断（是索引问题还是写法问题）→ 最后才是加索引或改写 SQL。我 3 年在 DBA 岗位上踩过的坑，绝大多数都败在「上来就加索引」这一