CR 时跟同事吵了一架 上周做订单模块的代码评审,同事设计的新表里有个 ext_data 字段,类型 json,里面塞了发票信息、优惠券信息、配送偏好、渠道来源,一共十几个子字段。他的理由是"这些字段每个订单不一定都有,建十几个列太浪费"。 我在评论里提了反对意见,他回了一句"MySQL 8 原生支
几个年头里反复踩的坑 建表时随手选类型,上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题,新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移,所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255),其实 MySQL 在 utf8m
用户投诉:刚改完昵称又变回去了 那天下午客服转来 7 个工单,都是"改了资料刷新又回旧值"。我第一反应是缓存,清了一遍没用。查监控才发现,是主从延迟在作怪——前端查到了还没同步过去的旧数据。更诡异的是,有的用户反馈"改完看是对的,过两秒刷新又变回去",典型的读到了从库旧快照。 定位过程 用户在主库改
慢查询告警响了,但我不知道是哪条 SQL 有天早上 Prometheus 报了一条 mysql_slow_queries 突增,我登录数据库一查 SHOW PROCESSLIST,满屏都是 Sending data 的查询,根本分不清谁是元凶。那时候我们的慢查询治理还是"出问题了才去看日志",属于事
「下单偶尔失败,刷新一下就好了」 1 月中旬,运营那边反馈:商家后台点"确认收货"有时候会失败,弹一个系统繁忙,再点一次就好了。我们查日志,一天里有 200 多条这样的错: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException:
现象:翻到第 1000 页要 8 秒 运营反馈"订单列表翻页越往后越慢"。我们复现了一下,第一页 23 ms,第 100 页 340 ms,第 1000 页 8.2 秒。 SQL 长这样(每页 20 条): SELECT * FROM t_order WHERE user_id = 100372
一条 ALTER TABLE,把整个订单库堵死了 3 月 22 号下午两点,我在 t_order_item 上执行了一条自认为很安全的语句: ALTER TABLE t_order_item ADD COLUMN promotion_type TINYINT NOT NULL DEFAULT 0 C
告警: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
慢查询日志里那条 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