DBA熬夜改表？大模型安全工程师的MySQL实战手册

　　2025年6月那晚，风扇在脚下转得跟电钻似的，我盯着屏幕上的慢查询报警，心里直骂娘——开发新上线的特征工程脚本，把一个TEXT字段当JSON存，还TM没建索引。主库CPU飚到98%，从库延迟差三分钟，运维在群里喊“再撑十分钟就切流量”，我手抖着敲ALTER TABLE，心里默念“别锁表别锁表别锁表”。

　　开发路过问了句“好了没”，我抬头看了眼窗外，天都黑了，外卖凉在桌上，汤都凝成块了。我原以为改个字段类型能有多麻烦？结果这表三百多万行，TEXT转JSON，MySQL得先重建整张表，锁表期间所有写请求全堆在主库上，监控里事务数直接爆红。运维在群里@我：“主库连接数涨到五千了，你改完没？”我盯着进度条卡在23%，心里骂这破MySQL怎么不给个预估时间？

　　后来跟开发吵了一架——他们说“JSON字段查询快”，我说“快你妹，TEXT字段没索引，全表扫描能不慢？”他们反驳“我们用LIKE模糊匹配”，我差点把键盘摔了：“LIKE '%xxx%'这种写法，索引有个屁用！”吵到⭐️⭐️⭐️⭐️我甩出慢查询日志：“看，这条SQL跑了俩小时，执行计划里全是全表扫描，你们管这叫优化？”开发不说话了，默默回去改代码——结果第二天又提交了个VARCHAR(8000)的字段，说是“为了兼容未来需求”。

　　这事儿让我想起上个月备份恢复演练，运维说“主库数据量太大，备份要跑三小时”，我建议用Percona XtraBackup，结果他说“没学过，怕搞崩”。我当场演示了一遍，备份时间从三小时缩到四十分钟，恢复测试也一次过。他挠挠头：“原来还能这么玩？”我冷笑：“你们DBA要是连备份策略都不懂，活该熬夜改表。”

　　其实最让我后怕的是那次误操作——有回我手抖，把ALTER TABLE的字段名写错了，执行完才发现，主库直接挂了。运维冲过来问“怎么了”，我盯着错误日志，冷汗直冒：“字段不存在，表结构锁了，所有写请求全堵了。”他一边重启主库一边骂：“你改表前不先在测试库跑一遍？”我哑口无言——确实，我总以为“改个字段类型能出什么事”，结果差点酿成事故。后来我养成了习惯：改表前先在测试库跑三遍，确认没问题再上生产。

　　说回那晚的慢查询，我最终用pt-online-schema-change工具改了表结构，全程没锁表，主库延迟控制在十秒内。运维在群里发了个“666”，开发默默给我点了杯咖啡——但我知道，这治标不治本。第二天我拉着开发和运维开了个会，把慢查询日志、执行计划、索引建议全甩桌上：“要么你们改代码，要么我给你们建索引，但别指望我天天熬夜改表。”他们商量了半天，最后决定“先优化SQL，再建必要索引”。

　　这事儿让我琢磨出一个道理：DBA熬夜改表？说白了是“优胜劣汰”——开发不懂索引，运维不懂备份，最后全得DBA擦屁股。但DBA要是只会改表，不懂压榨MySQL性能，不懂跟开发撕逼，那活该熬夜。我见过太多DBA，改个表结构要请示领导，建个索引要开发确认，出了问题第一个甩锅——这种DBA，不淘汰你淘汰谁？

文章配图，仅供参考

　　当然，我也承认自己有局限——比如那次误操作，比如对某些新特性的不熟悉。但至少我现在知道：DBA的价值，不是改表改到凌晨三点，而是让开发不敢写烂SQL，让运维不敢乱备份，让主库永远稳如老狗。至于那些还在熬夜改表的DBA？要么赶紧学，要么赶紧转行——这行，优胜劣汰，从来不客气。

（编辑：站长网）

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