一条 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
刚上读写分离，客服就收到投诉了 十一月初，我们把订单库做了读写分离：一主两从，写走主库，查走从库。用 ShardingSphere-JDBC 5.0.0-alpha（当时叫 Sharding-JDBC），配置很简单： spring: shardingsphere: datasource:
告警：Deadlock found when trying to get lock 八月中旬的一个晚上，钉钉群开始刷告警。库存服务的日志里出现了这个： 2020-08-13 21:14:32.881 ERROR [http-nio-8080-exec-42] o.s.i.d.i.InventoryM
压测时发现的怪事：接口 TP99 高但 CPU 才 30% 六月份做订单列表接口的压测，200 并发、跑 5 分钟，结果很怪：QPS 卡在 1400 上不去，TP99 到了 620ms，但应用Ubuntu 服务器 CPU 只有 30% 出头，数据库连接池（HikariCP，最大 20）也没打满，My
把 MySQL 5.7 升到 8.0，五个报错排了三天 4 月初，我们把订单库的 MySQL 从 5.7.26 升到了 8.0.19。起因很实际：运营要做"每个用户的消费排名"，5.7 里只能用会话变量写那种很难维护的 SQL，8.0 有窗口函数 ROW_NUMBER()，一行搞定。 升级过程本身（
慢查询日志里那条 1.8 秒的 SQL 7 月底，DBA 每周发的慢查询报表里，我们订单库有条 SQL 排第一：执行 14.7 万次，平均 1.83 秒，扫描行数 28 万。SQL 长这样： SELECT order_no, user_id, amount, status, create_time
凌晨两点的死锁告警 5 月 28 号凌晨，库存服务的告警响了：批量扣减任务报死锁，一晚上 217 次。错误是客户端收到的： com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when t
DBA 丢给我一张容量曲线图 2 月底，DBA 在周会上放了张图：订单主库 t_order 已经 4200 万行，数据文件 38G，加上索引一共 51G，按每月 380 万行的增速，年底到 8000 万行，明年年中破亿。他的结论是"该考虑分库分表了"。 主管把这个评估任务派给了我。说实话我当时有点虚
跑批脚本算出来的数对不上 2 月 11 号早上，财务来找我对账：昨天的日结脚本跑出来的金额是 1000 元，但后台页面显示是 1200 元。我翻脚本日志，发现它做了这么一件事： START TRANSACTION; SELECT SUM(amount) FROM t_order WHERE pay_
