SQL Server运维踩坑14年实战指南

文章配图，仅供参考

　　说白了，SQL Server运维这事儿，优胜劣汰的法则比代码还硬。2018年那会儿，我接手过一个金融项目，数据库里存着上亿条交易记录，老板非要搞“实时报表”，让后端直接在OLTP库上跑聚合查询。结果呢？每月1号结息日，CPU直接飚到100%，业务系统卡得连登录都超时。后来我偷偷在非高峰期建了个只读副本，用ETL抽数据到分析库，被老板骂“浪费资源”——可要不是这招，那年双十一他们系统得瘫三次。

　　白板上的字还没擦，上周五会写的“迁移方案V3.2”还留着，旁边是测试写的“别碰索引！”。其实最坑的不是技术问题，是需求变更。去年双十一前两周，运营突然说要加个“用户画像标签”，后端连夜改了表结构，加了二十多个NULL字段。我盯着DDL语句直冒冷汗——这表都两千万行了，加字段要重建表，生产环境锁表十分钟？后来我偷偷在测试环境跑了个ALTER TABLE WITH (ONLINE=ON)，结果发现企业版才支持这参数，标准版直接报错。最后没办法，凌晨三点停机维护，被运营在群里骂了半小时“影响KPI”。

　　外卖到了没人拿，放在工位上凉透了。我想起2013年那个项目，客户非要用SQL Server 2005，说“稳定”。结果三年后，微软都停服了，他们还在跑关键业务。有天凌晨三点，主库的tempdb突然爆了，日志文件涨到200G，磁盘空间不足。我翻遍文档才发现，2005版的tempdb不会自动收缩，得手动改配置。那会儿没有SSD，磁盘I/O慢得像蜗牛，重启服务花了四十分钟——客户差点把运维部掀了。

　　其实有些坑，早该被淘汰了。比如那个“用触发器同步数据”的方案，2010年我就见过，后来被消息队列取代；还有“存储过程里写业务逻辑”，现在谁还这么干？可偏偏有些老系统，像僵尸一样活着。上周我审一个新项目的数据库设计，发现还有人用“表变量+游标”处理批量数据，理由是“这样写简单”。我当场把设计图撕了——简单？你知道表变量在内存里怎么分配的吗？你知道游标会锁表吗？测试群又在响，设计说“这个字段要加默认值”，我回了句“先看看表大小再说话”，然后继续改那个报错的存储过程。

　　老李离职前跟我说过句话：“SQL Server运维，活得久的都是会妥协的。”我原以为他是说技术妥协，结果发现是跟需求妥协。比如那个“实时报表”的需求，最后我妥协成了“准实时”——每五分钟同步一次数据到分析库，既满足了业务，又没拖垮主库。再比如索引，我不再跟设计争“要不要加”，而是让他们提供查询SQL，我跑执行计划，用数据说话。优胜劣汰？说白了，就是谁更懂业务，谁更懂妥协。

　　窗外天黑了，测试群还在响。我掐了烟，回工位看了眼监控——内存泄漏的存储过程终于被杀了，临时表也清理了。设计又发来一条消息：“那个索引，要不还是加吧？”我回了句：“先跑个EXPLAIN，看看有没有全表扫描。”然后继续改那个报错的存储过程——这次我加了TRY-CATCH，至少不会让事务一直挂着。优胜劣汰？也许吧，但至少今天，我没让系统瘫掉。

（编辑：站长网）

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