😂 IT段子

这张表的字段有四十个，实际被查的不超过十个。我抬起头看了看周围，大家都一样。我把这个索引建成了覆盖索引，回表彻底消失了。我沉默了，但心里是服的

我把这条 SQL 交给优化器，它有自己的想法。我在心里把涉及的所有环节都过了一遍。我打开了这个视图的定义，发现它嵌了四层子查询。第二天这个方案就变成了团队标准做法

分库分表方案讨论了一周，最后数据量根本没到那个级别。我把整条链路在心里复盘了一遍。我在这个字段上补了个联合索引，从五秒降到了八十毫秒。这条经验值直接拉满

大事务跑了两个小时，期间锁住了整张核心表。我决定先把手上的事情做完再处理这件事。我打开了这张表的自增 id 走势，发现中间有段跳号。这大概就是程序员的人生吧

我把这个业务的唯一约束想清楚了，然后发现拦住了自己。我打开了这张表的历史版本，发现字段被改过两次名

大事务跑了两个小时，期间锁住了整张核心表。这套流程走下来，我从头到尾又确认了一遍。我把这个分库分表的键选成了用户 id，路由终于均匀了。第二天这个方案就变成了团队标准做法

这条语句在低峰期是好的，高峰期锁得死死的。我笑了笑，决定不解释。我在心里默默给这个字段加了 NOT NULL，但要先洗数据。我把这条经验写进了团队 wiki

一张表两亿行，没有分区，索引建了八个，每个查询都全表扫。我笑了笑，决定不解释。我在心里把这条 SQL 的扫描行数算了一遍，量级不对。我沉默了，但心里是服的

数据库字段名叫 is_del，注释叫"是否删除"，实际含义是"是否没删除"。我发现自己居然没法反驳。我在心里把这条 SQL 的扫描行数算了一遍，量级不对。世界瞬间清净了

我把这条数据链路理了一遍，发现有个环节没人负责。我打开记录从头到尾扫了一遍。我打开了这张表的主从延迟，发现已经追上来了。幸好之前留了备份