告警：一条 JOIN 把从库 CPU 拉满 七月五号，DBA 在群里 @我：「你那条报表 SQL 把从库 CPU 干到 100%，跑了 40 秒还没出」。这是一条订单表（8000 万行）和用户表（2000 万行）的关联查询，原本是凌晨跑的批，被临时拉到白天查。我拿 EXPLAIN 一看，问题很清楚。
背景：一个写了 60 行的排行榜 SQL 七月做运营后台，产品要「每个城市的销售 Top3」和「月度累计业绩」。第一版我用子查询嵌套，SQL 拉到 60 多行，GROUP BY 套 GROUP BY，执行计划里全是 DEPENDENT SUBQUERY，跑一次 3 秒多。同事提醒我：你们库早升 My
一个 ES 查询，把节点 CPU 打到了 95% 运营后台有个"订单检索"接口，平时挺快，某天加了"按创建时间排序 + 关键词模糊"后，单查询 CPU 占用飙升，集群一个节点到了 95%，其他查询全被拖慢。我用 profile API 抓了执行计划，发现罪魁是把本该放 filter 的条件写进了 q
现象：翻到第 1000 页要 8 秒 运营反馈"订单列表翻页越往后越慢"。我们复现了一下，第一页 23 ms，第 100 页 340 ms，第 1000 页 8.2 秒。 SQL 长这样（每页 20 条）： SELECT * FROM t_order WHERE user_id = 100372
半年内第四次，又是新 SQL 没索引 2021 年 5 月 10 号，一个上线不到两小时的功能把数据库打挂了。原因是一段新写的查询没走索引，全表扫 4000 万行。 难受的是，这不是第一次。我翻了下过去半年的故障记录： 日期 原因 影响时长 2020-12-08 新接口 SQL 未加索引 47 分钟
一条 ALTER TABLE，把整个订单库堵死了 3 月 22 号下午两点，我在 t_order_item 上执行了一条自认为很安全的语句： ALTER TABLE t_order_item ADD COLUMN promotion_type TINYINT NOT NULL DEFAULT 0 C
运营说：这个报表等到花儿都谢了 十一月底，运营同学提了个工单："销售明细报表要等 8 秒以上，导出的时候更是直接超时。" 我看了下 slow log，那条查询平均 8.4 秒，最慢的一次 21 秒： # Time: 2020-11-24T14:22:31.882113+08:00 # User@Ho
压测时发现的怪事：接口 TP99 高但 CPU 才 30% 六月份做订单列表接口的压测，200 并发、跑 5 分钟，结果很怪：QPS 卡在 1400 上不去，TP99 到了 620ms，但应用Ubuntu 服务器 CPU 只有 30% 出头，数据库连接池（HikariCP，最大 20）也没打满，My
慢查询日志里那条 1.8 秒的 SQL 7 月底，DBA 每周发的慢查询报表里，我们订单库有条 SQL 排第一：执行 14.7 万次，平均 1.83 秒，扫描行数 28 万。SQL 长这样： SELECT order_no, user_id, amount, status, create_time
DBA 甩给我一个 2.3G 的慢日志文件，说"你们那边先看看" 双十二前一周，DBA 在群里发了条消息：订单库 QPS 涨了 3 倍，慢查询日志一天产生 2.3G，让各个业务方自查。我负责的订单模块首当其冲。 拿到日志文件的时候我是懵的，2.3G 文本，几百万行，根本没法用编辑器打开。这篇记录我当
