CR 时跟同事吵了一架 上周做订单模块的代码评审，同事设计的新表里有个 ext_data 字段，类型 json，里面塞了发票信息、优惠券信息、配送偏好、渠道来源，一共十几个子字段。他的理由是"这些字段每个订单不一定都有，建十几个列太浪费"。 我在评论里提了反对意见，他回了一句"MySQL 8 原生支
背景：一个写了 60 行的排行榜 SQL 七月做运营后台，产品要「每个城市的销售 Top3」和「月度累计业绩」。第一版我用子查询嵌套，SQL 拉到 60 多行，GROUP BY 套 GROUP BY，执行计划里全是 DEPENDENT SUBQUERY，跑一次 3 秒多。同事提醒我：你们库早升 My
几个年头里反复踩的坑 建表时随手选类型，上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题，新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移，所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255)，其实 MySQL 在 utf8m
用户投诉：刚改完昵称又变回去了 那天下午客服转来 7 个工单，都是"改了资料刷新又回旧值"。我第一反应是缓存，清了一遍没用。查监控才发现，是主从延迟在作怪——前端查到了还没同步过去的旧数据。更诡异的是，有的用户反馈"改完看是对的，过两秒刷新又变回去"，典型的读到了从库旧快照。 定位过程 用户在主库改
面试被问：REQUIRES_NEW 到底开了几个连接 前阵子面一个五年经验的候选人，我随口问："方法 A 用 REQUIRED 调方法 B，B 用 REQUIRES_NEW，这俩用的是同一个数据库连接吗？"对方答"应该是同一个吧，都在一个事务里"。这其实是个很常见的误解。REQUIRES_NEW 会
慢查询告警响了，但我不知道是哪条 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
晚上八点半，所有接口一起超时 4 月 15 号晚上八点二十几分，告警群开始刷屏：订单服务全部接口超时，错误率 100%。 Pod 是活的，CPU 和内存都正常，CPU 只有 31%。但所有请求都在报同一个错： 2021-04-15 20:23:41.882 ERROR [http-nio-8080-
一条 ALTER TABLE，把整个订单库堵死了 3 月 22 号下午两点，我在 t_order_item 上执行了一条自认为很安全的语句： ALTER TABLE t_order_item ADD COLUMN promotion_type TINYINT NOT NULL DEFAULT 0 C
