背景：一个写了 60 行的排行榜 SQL 七月做运营后台，产品要「每个城市的销售 Top3」和「月度累计业绩」。第一版我用子查询嵌套，SQL 拉到 60 多行，GROUP BY 套 GROUP BY，执行计划里全是 DEPENDENT SUBQUERY，跑一次 3 秒多。同事提醒我：你们库早升 My
几个年头里反复踩的坑 建表时随手选类型，上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题，新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移，所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255)，其实 MySQL 在 utf8m
用户投诉：刚改完昵称又变回去了 那天下午客服转来 7 个工单，都是"改了资料刷新又回旧值"。我第一反应是缓存，清了一遍没用。查监控才发现，是主从延迟在作怪——前端查到了还没同步过去的旧数据。更诡异的是，有的用户反馈"改完看是对的，过两秒刷新又变回去"，典型的读到了从库旧快照。 定位过程 用户在主库改
分库分表后，运营要查"跨商家跨库的订单" 我们订单库按 user_id 哈希分了 16 个库、每库 64 张表。单用户的订单查询很顺，因为都在同一个分片。直到运营提了个需求："给我看最近 30 天、金额大于 5000、状态是退款中的所有订单"——这个查询跨了所有库所有表，没有分片键可路由。组员在周会
慢查询告警响了，但我不知道是哪条 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
半年内第四次，又是新 SQL 没索引 2021 年 5 月 10 号，一个上线不到两小时的功能把数据库打挂了。原因是一段新写的查询没走索引，全表扫 4000 万行。 难受的是，这不是第一次。我翻了下过去半年的故障记录： 日期 原因 影响时长 2020-12-08 新接口 SQL 未加索引 47 分钟
8200 万行数据，怎么搬到 32 个分片里去 接上一篇。分片规则定好了、ShardingSphere 配好了，接下来的问题是：老库里那 8200 万行数据怎么搬过去，而且不能停服。 这篇文章写的是迁移本身，跟分片设计是两件事，但难度可能更大。 先算停机方案要多久 最省事的做法是挂维护页，导出导入。
一条 ALTER TABLE，把整个订单库堵死了 3 月 22 号下午两点，我在 t_order_item 上执行了一条自认为很安全的语句： ALTER TABLE t_order_item ADD COLUMN promotion_type TINYINT NOT NULL DEFAULT 0 C
