😂 IT段子

我把这条数据链路理了一遍，发现有个环节没人负责。这套流程走下来，我从头到尾又确认了一遍。我在这个字段上补了个联合索引，从五秒降到了八十毫秒。从此我多了一条团队规约

一张表两亿行，没有分区，索引建了八个，每个查询都全表扫。我想了想自己这些年，好像确实如此。我把这个聚合查询挪到了离线任务，页面终于不卡了。这大概就是程序员的人生吧

我把这条 SQL 交给优化器，它有自己的想法。我拉了个小群，把相关同学都叫了进来。我在心里给这个表设计预留了扩展字段，果然用上了。感动，然后我学到了新的一课

这条链路的瓶颈最后总是落在数据库上。我想反驳，但发现他说得对。我看了下数据分布，发现这个字段的区分度只有百分之零点一。从此我多了一条团队规约

分库分表方案讨论了一周，最后数据量根本没到那个级别。我深呼吸了一下，决定从最可疑的地方查起。我把这个软删除改成了归档表，主表终于瘦了下来。真香定律准时生效

我把这个业务的事务范围画了出来，比我想的大很多。我默默打开了编辑器，准备一步步验证。我把这个字段的类型从字符串改成了整型，比对快了很多。复盘会上我们把它列成了案例

这张表的字段有四十个，实际被查的不超过十个。我打开了这两个库的表结构，发现有张表只在一个库里。我把这条经验写进了团队 wiki

我把备份恢复了三次，第三次才成功。我打开记录从头到尾扫了一遍。我把这个连接池的最大连接数调小了，数据库终于喘过气。第二天这个方案就变成了团队标准做法

Explain 一打，type 是 ALL，rows 是八百万，我默默关掉了工单。我决定先把手上的事情做完再处理这件事。我把大事务拆成了小批次提交，锁等待立刻消失了。好在最后有惊无险

数据库的每一次变更都值得多问一句「能不能回滚」。我听完沉默了，因为太真实了。我在心里把这条链路的耗时拆成了四段，最慢的在意料之外。真香定律准时生效