13年DBA亲历：创业老炮儿晒17个技术踩坑实录

　　去年中考那周，我在监控台盯了四天。不是运维在看告警，是盯着学生家长点进查分页那一刻——手指悬停在“查询”按钮上，0.8秒没反应，控制台里三个`fetch`被abort，`Failed to fetch`后面跟着一个`AbortError`，再往后滚动两行，`ResizeObserver loop completed with undelivered notifications.`。我手边泡的枸杞水早凉透了，工位显示器是竖着的，调页面响应式时顺手掰过去的，到现在也没掰回来。

　　会议室白板没擦干净，上回画的分库分表草图还粘着半截蓝线，底下压着产品写的“查分页必须支持10万并发”——字是昨天下午三点写的，墨迹没干透，被空调风吹得微微翘边。后端同学把查分接口扔进了Redis缓存，key写成`score:${userId}`，但前端传来的`userId`里混了字母和空格，结果所有请求全打到DB，没走缓存。他改完发PR那会儿，我正蹲在测试机前抓包，型号是MacBook Pro 2019，风扇嘶吼着像要起飞，Wireshark里全是重传包。

文章配图，仅供参考

　　谁在背后走过碰了椅子，哐当一声，我头都没抬。外卖到了没人去拿，袋子搁在茶水间门口，汤渗出来浸湿了门垫。键盘上Q键掉了，用胶带粘过两次，现在按下去有0.3秒延迟，但我不换，因为习惯了盲打时多使三分力。有个产品经理站了很久，端着杯子，杯沿一圈浅褐色茶渍，站在我工位后方三米处不动，等我抬头，我没抬。他最终自己说：“其实……是不是能加个降级开关？”我说：“开关我写了，但你们没配权限，上次发布没提工单。”

　　查分页崩溃那天，是周四下午4:22。DB负载冲到98%，慢查询日志刷得满屏，最慢一条执行了8.7秒，`EXPLAIN`显示走了全表扫描，原因？索引字段类型是`VARCHAR(255)`，传参却是整型`123456`，MySQL隐式转换不走索引。这事儿我在入职第三年就见过，在一个电商抢购页里——一模一样。我改了，他们上线了，半年后又出现，还是同一个表，还是同一类字段，连注释都没改：“此处防止类型不匹配”——注释还在，但人已经换了三拨。

　　有一次构建日志里飘出一行：`WARNING: webpack asset size limit exceeded (250 KiB)`。没人理，直到H5加载失败卡白屏。我扒出来发现是某个埋点SDK把整个Lodash打包进去了，而这个SDK只用来调一个`_.get()`。提交记录里作者备注：“修复undefined异常（#1243）”，commit hash是`f3a7b8d`，时间是凌晨2:17。我回滚了它，替换成原生写法，上线后首页FCP从5.2秒压到1.1秒左右——大概几秒，记不清了，反正比之前快三倍不止。但下个月需求评审，又看到同一个SDK被加进小程序新页面。

　　我们搞了个灰度策略，按地区分流。浙江走A链路，江苏走B链路。但有个中间件配置漏了，所有省份都走B，而B链路连的是未扩容的旧集群。中考当天中午，DBA群里弹出第一条告警：`pg_stat_database.blks_read > 500k/sec`。接着是第二条：`connection refused on port 5432`。我立刻切手动主从切换，切完发现VIP漂移失败——TKE的`keepalived`进程僵死了，`ps aux | grep keep`跑出来三个僵尸进程，其中一个父PID是1。我ssh上去杀，杀不动，最后只能重启节点。节点重启时，有人在测试群里发截图：页面提示“服务暂时不可用”，字体字号跟设计稿标注完全一致，14px，#999，左对齐。

　　还有一次，前端同事为防重复提交，在按钮上加了`disabled=true`，结果忘了重置状态。用户点完查分，网络一抖，请求发出去又断开，按钮永远灰着，但数据没查出来。家长以为没提交成功，狂点，后端接口收到十几次同样参数——然后全进慢查询队列。那晚我删了127条重复日志，手动`DELETE FROM query_log WHERE status = 'timeout' AND created_at > '2023-06-15 16:00:00';`，语法没错，但删完发现没加事务，中间被人误触了`flush logs`，binlog里那段删操作没了，得重做。后来我自己写了脚本，自动识别这类模式，跑在凌晨三点。现在它还跑着，cron里写着`0 3 /opt/dba/bin/check_query_repeats.sh`。

　　我翻过17个类似事故的日志、commit、监控图、错误堆栈、会议纪要——没有一个是因为技术本身不够新，全是因为某个人在某个环节少按了一次回车，或没看一眼控制台报错里的第三行，或以为“这次不会出事”。我不信复盘报告里写的“流程缺失”，流程再多也堵不住人踮脚去够屏幕顶上那个没关的tab页。也不信“加强培训”，上个月新来的实习生问我“为什么不能直接`DROP DATABASE production`”，我教他看`my.cnf`里的`sql_mode`，他点头说懂了——结果两天后他`mysqldump --all-databases`导出来的SQL里，真有条`DROP DATABASE IF EXISTS xxx`没被注释掉。

　　我现在每天早上第一件事，不是看监控大盘，是检查`/etc/my.cnf.d/protect.cnf`有没有被覆盖。如果被覆盖了，我就打开终端，把`max_connections = 500`那行粘贴回去，再`systemctl reload mysqld`。我不指望它彻底解决问题，但至少能多撑23分钟。今晚我会再扫一遍所有业务库的`information_schema.COLUMNS`，找`VARCHAR`和传参类型不一致的字段，不修，只记下来，存在`/tmp/schema_mismatch.txt`里——明早开会时，把它打印出来，夹在产品需求文档里，一起交过去。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!