发布后第二天上午，接口全卡在 3 秒 12 月 18 号那次上线加了个订单导出功能，第二天上午十点，运维在群里 @ 我：订单查询接口 P99 从 40ms 涨到了 3000ms，超时率 12%。 第一反应是慢 SQL。打开 Druid 监控页（我们一直开着 /druid），看到的画面不太对： Act
DBA 甩给我一个 2.3G 的慢日志文件，说"你们那边先看看" 双十二前一周，DBA 在群里发了条消息：订单库 QPS 涨了 3 倍，慢查询日志一天产生 2.3G，让各个业务方自查。我负责的订单模块首当其冲。 拿到日志文件的时候我是懵的，2.3G 文本，几百万行，根本没法用编辑器打开。这篇记录我当
那条跑了 4.7 秒的 SQL，我改了三个地方降到 23 毫秒 九月底，运营反馈"订单查询页面打不开"。我一看监控，那个列表接口的 TP99 从平时的 120ms 涨到了 4.7 秒，慢查询日志里刷了一屏同一条 SQL。 库是 MySQL 5.7.21，订单表 t_order 数据量 860 万。先
对账时发现：同一个事务里两次查询的结果不一样 上周做月底对账，写了个校验脚本：先统计账户表的总余额，再逐条核对流水，最后再统计一次总余额，看两次是否一致。结果两次统计的数字差了 3800 元。 我一开始以为是脚本 bug，查了半天才发现——脚本跑的过程中，有交易在实时发生，我第二次统计时读到了新提交
慢查询日志里躺了一条 8 秒的 SQL DBA 每周会给我们发一份慢查询报表。上周的报表里，我们服务贡献了第一名：一条 8.2 秒的 SQL，平均执行 1200 次/天。 # Time: 2018-03-08T10:22:33.123456Z # Query_time: 8.203451 Lock
3 万条数据导了 20 分钟 上周五下午接到个活儿：从老系统导 3 万条历史订单到新库。我写了个循环，单次 insert，跑起来就去接水了。回来一看还在跑，最后总共花了 18 分 42 秒。DBA 在钉钉上问我是不是在攻击数据库。 痛定思痛，我把 MyBatis 批量插入的几种写法全试了一遍，顺便记
