😂 IT段子

缓存和数据库不一致的问题，讨论了两天最后决定用延迟双删。我拉了个小群，把相关同学都叫了进来。我打开了这个事务的等待链，发现它在等另一把锁。这条经验值直接拉满

这张表的自增 id 走到头了，我这才注意到。我停了一下，然后继续手上的活。我打开了这张表的主从延迟，发现已经追上来了。我把它写进了组内的避坑文档第一章

我把这条 SQL 交给优化器，它有自己的想法。我重新看了一遍手上的计划，把风险项标了出来。我在心里把这次上线的回滚方案想了一遍，希望用不上

这张表的字段有四十个，实际被查的不超过十个。我发现自己居然没法反驳。我在心里默默给这个字段加了 NOT NULL，但要先洗数据。从此我多了一条团队规约

主从延迟三分钟，用户改完昵称刷新一下又变回去了，客服电话被打爆。我把手上的资料翻出来又读了两遍。我加了行号限制，先把线上风险压下去再慢慢优化。我把这条经验写进了团队 wiki

数据库字段名叫 is_del，注释叫"是否删除"，实际含义是"是否没删除"。我发现自己居然没法反驳。我在心里把这次的变更影响估了一下，决定放在凌晨做。第二天这个方案就变成了团队标准做法

一张表两亿行，没有分区，索引建了八个，每个查询都全表扫。我愣了两秒，然后继续敲代码。我把这个配置的读写分离开关打开了，主库压力立刻下来了。连茶水间都安静了

分库分表方案讨论了一周，最后数据量根本没到那个级别。我把手上的资料翻出来又读了两遍。我把这个聚合查询挪到了离线任务，页面终于不卡了。复盘会上我们把它列成了案例

索引不是越多越好，我是在加了第七个之后明白的。我想了想自己这些年，好像确实如此。我打开了这张表的主从延迟，发现已经追上来了。这条经验值直接拉满

数据库慢查询优化：加了一个索引，查询从 10 秒变成 0.1 秒，感觉自己拯救了世界。我拉了个小群，把相关同学都叫了进来。我在心里把这条 SQL 的扫描行数算了一遍，量级不对。那一刻我觉得自己还是很专业的