刚上读写分离，客服就收到投诉了 十一月初，我们把订单库做了读写分离：一主两从，写走主库，查走从库。用 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
报错：Result window is too large 运营后台有个"导出全部商品"的功能，前端做成了分页拉取，一页 100 条，用循环一直翻到最后一页。上线当天就炸了，日志里全是这个： org.elasticsearch.ElasticsearchStatusException: Elasti
把 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
批量扣款任务卡死后，单笔扣款接口也全挂了 7 月 5 号早上 9 点 12 分，监控开始告警：/api/deduct 接口响应时间从 60 毫秒飙到 30 秒全部超时。同时 DBA 在群里说，account 表上有锁等待，已经持续 4 分钟。 第一反应是数据库慢查询。但登上机器看，应用这边 CPU
凌晨两点的死锁告警 5 月 28 号凌晨，库存服务的告警响了：批量扣减任务报死锁，一晚上 217 次。错误是客户端收到的： com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when t
跑批脚本算出来的数对不上 2 月 11 号早上，财务来找我对账：昨天的日结脚本跑出来的金额是 1000 元，但后台页面显示是 1200 元。我翻脚本日志，发现它做了这么一件事： START TRANSACTION; SELECT SUM(amount) FROM t_order WHERE pay_
同事问：我这个接口没写 limit，为什么只返回 10 条 1 月底，隔壁工位的同事喊我过去看个怪事。他的导出接口调了两次 Mapper：第一次查订单列表，第二次查订单状态统计。结果统计接口只返回了 10 条数据，而他的 SQL 里压根没有 limit。 我把 MyBatis 的 SQL 日志打开（
发布后第二天上午，接口全卡在 3 秒 12 月 18 号那次上线加了个订单导出功能，第二天上午十点，运维在群里 @ 我：订单查询接口 P99 从 40ms 涨到了 3000ms，超时率 12%。 第一反应是慢 SQL。打开 Druid 监控页（我们一直开着 /druid），看到的画面不太对： Act
