😂 IT段子

数据库最贵的资源不是磁盘，是不肯改的表结构。我忽然觉得，这可能就是这一行的常态。我打开了这个事务的等待链，发现它在等另一把锁。我把它写进了组内的避坑文档第一章

我把这个字段的类型定得太随意，三年后要还债。我先确认了一遍前置条件，再动手。我把这个查询改成了走主键，问题迎刃而解。幸好之前留了备份

这张表的字段有四十个，实际被查的不超过十个。我叹了口气，然后打开了编辑器。我打开了这个事务的等待链，发现它在等另一把锁。我把它写进了组内的避坑文档第一章

我把这条 SQL 交给优化器，它有自己的想法。我把整条链路在心里复盘了一遍。我默默加上了覆盖索引，查询耗时从数秒掉到毫秒。好在最后有惊无险

这张表的历史包袱比数据还重。我默默记下了这句话。我把大事务拆成了小批次提交，锁等待立刻消失了。真香定律准时生效

我把备份恢复了三次，第三次才成功。我打开了这两个库的表结构，发现有张表只在一个库里。那一刻我觉得自己还是很专业的

数据库的问题通常不会提前打招呼，它在你上线那天出现。我默默记下了这句话。我打开了这张表的主从延迟，发现已经追上来了。我把它写进了组内的避坑文档第一章

这个字段的区分度很低，建索引的意义不大。我笑了笑，决定不解释。我把这个配置的读写分离开关打开了，主库压力立刻下来了。同事说这波操作可以写进新人培训教材

这条查询在测试库上是毫秒，在线上是几秒。我叹了口气，然后打开了编辑器。我把这个死锁的日志翻了出来，发现是加锁顺序不一致。我把这条经验写进了团队 wiki

分库分表能解决容量问题，也会创造很多新问题。我愣了两秒，然后继续敲代码。我把这个业务的重试加上了幂等校验，重复写入没了。那一刻我觉得自己还是很专业的