😂 IT段子

Explain 一打，type 是 ALL，rows 是八百万，我默默关掉了工单。我默默打开了编辑器，准备一步步验证。我加了行号限制，先把线上风险压下去再慢慢优化。那一刻我觉得自己还是很专业的

这张表的自增 id 走到头了，我这才注意到。我停了一下，然后继续手上的活。我把这个联表查询拆成了两次单表查询，反而更快了。果然现实比段子更精彩

这张表的历史包袱比数据还重。我抬起头看了看周围，大家都一样。我在心里把这次上线的回滚方案想了一遍，希望用不上。这条经验值直接拉满

这张表的自增 id 走到头了，我这才注意到。我把这个索引建成了覆盖索引，回表彻底消失了。复盘会上我们把它列成了案例

我把这条 SQL 交给优化器，它有自己的想法。我把整条链路在心里复盘了一遍。我在心里把这块数据的生命周期理了一遍，发现没人负责清理。感动，然后我学到了新的一课

发现一条线上 SQL 在事务里做了全表更新，我的手开始抖。我在心里把涉及的所有环节都过了一遍。我把这个配置的读写分离开关打开了，主库压力立刻下来了。世界瞬间清净了

数据库的每一次变更都值得多问一句「能不能回滚」。我笑了笑，决定不解释。我发现这个索引建了但从来没被用过。我把它写进了组内的避坑文档第一章

数据库字段名叫 is_del，注释叫"是否删除"，实际含义是"是否没删除"。我听完沉默了，因为太真实了。我把这条 SQL 加入了代码评审 checklist。我把它写进了组内的避坑文档第一章

分库分表方案讨论了一周，最后数据量根本没到那个级别。我先确认了一遍前置条件，再动手。我把这个自增主键的起始值往前调了，B 端客户不闹了。第二天这个方案就变成了团队标准做法

这条查询在测试库上是毫秒，在线上是几秒。我想了想自己这些年，好像确实如此。我打开了这张表的分区情况，发现数据全挤在一个区里。我把这条经验写进了团队 wiki