一杯咖啡的时间，聊聊技术与成长
为什么你需要一个消息队列：解耦、异步、削峰
下单接口串行调五个服务，800ms 起步，大促直接雪崩。老王把一条消息队列插进链路：解耦、异步、削峰，三件事各归各位，接口从 800ms 干到 80ms。
分享一个 IDEA 插件：一键生成 MyBatis-Plus CRUD
受够了重复写 CRUD？这个插件根据实体类自动生成 Mapper / Service / Controller，支持 pig 框架的代码规范，附下载。
收官复盘：一张分库分表作战地图
二十篇走完，从一次八小时的 DDL 谈到老库安全下线——分库分表的决策、设计、迁移、治理收进一张地图。拆分是成本最高的性能手段，但走完这条路你会明白：它逼你理清业务边界、数据流向和容量账本，这些比分片本身更值钱。
踩坑实录：七个分库分表事故清单
机制都懂，事故照出——不带分片键的扫荡查询、跨片归并拖死的分页、分片键选错的全表路由、双写没对齐的数据错乱……七个真实形态的分库分表事故，现象、根因、修复与教训逐一复盘。事故报告里最贵的一句话永远是：早就知道，没做。
分片治理：水位、倾斜与再平衡
拆完不是终点，是另一场长期管理的开始：每个分片的容量水位涨到哪儿了？数据是不是悄悄倾斜了？三年后的容量今天规划够不够？分片系统的健康不靠某次重构，靠一套日日看、月月盘的治理机制。
冷热分离与归档：让主表保持轻盈
互联网数据有个铁律：绝大多数查询只发生在最近的数据上。把两年前的订单请出主表，两亿行立刻瘦到三千万——索引变矮、缓存变热、DDL 变快。归档不是把数据一删了之，冷库选型、限速批次、可回捞的查询入口，一样都不能少。
在线 DDL：分片环境的表结构变更
单表改一次结构要拷表八小时，分片之后变成三十二张表改三十二次——好消息是每张都小了，坏消息是协调成本翻了几十倍。gh-ost 那套在线改表在分片环境怎么排兵布阵、新结构上线前怎么保证新旧代码兼容，这一篇给出演练清单。
数据迁移（下）：校验、切流与回滚预案
双写追平只是「看起来一致」，校验通过才算「证明一致」——行数核对、分块 checksum、抽样比对三道关。之后按用户白名单灰度切流，先读后写，每一步都留着回滚的门。迁移工程的下半场，全是流程与纪律，没有算法。
数据迁移（上）：双写方案的全貌
几亿行的库没法一夜搬完，停机迁移窗口又批不下来——能走的路只剩一条：老库继续服役，新库并行建设，双写保同步，校验合格再切流。四阶段迁移框架是分库分表工程里的重头戏，本篇先搭出全貌：存量怎么搬、增量怎么追、双写怎么写。