网站搭建总卡壳？18年数仓老兵的多媒体运维避坑指南

　　去年九月份那会儿，运维群里突然炸锅——有个兄弟的网站卡得死活起不来，主库CPU飙到百分之九十多，慢查询日志刷得比风扇转得还快。我原以为又是哪个开发写了全表扫描的SQL，结果一看监控，好家伙，是索引碎片炸了。这事儿说起来特逗，那兄弟之前还跟我吹牛，说他们用的什么分布式架构，结果卡壳的时候，分布式节点全在等主库返回数据，跟串糖葫芦似的。

　　最绝的是，他查了半天慢查询，发现有个SQL执行了俩小时还没完。我让他把执行计划贴出来，结果一看，好家伙，全表扫描了八百万行，就为了找“status=1”的记录。我问他：“你这表没建索引？”他说：“建了啊，但是最近数据量涨得快，索引没维护。”我差点没笑出声——合着分布式架构能扛住数据量，但扛不住索引碎片啊？这就像给法拉利装了拖拉机的轮胎，跑得越快，颠得越狠。

　　这时候开发路过，问了句“好了没”，我抬头看了眼屏幕，行数还在跳，外卖凉了都顾不上吃。我说：“你们这SQL写得，跟数仓里的ETL似的，但ETL至少还能分批跑，你这全表扫描，主库不炸才怪。”开发撇撇嘴：“我们业务就这样，数据量大没办法。”我差点把键盘摔了——数据量大是理由？索引碎片不维护也是理由？合着卡壳了全怪数据库，自己一点责任没有？

　　后来我让他用`ANALYZE TABLE`跑了一遍，结果发现索引碎片率高达百分之三十。我原以为重建索引就能解决，结果跑`OPTIMIZE TABLE`的时候，主库直接宕机了——原来表太大，重建索引需要临时空间，而磁盘空间早被日志占满了。这时候窗外天黑了，运维群里的消息还在刷，有人说“要不回滚吧”，有人说“再等等”，领导在群里问“什么时候能恢复”，我盯着屏幕，心里直骂娘——这坑踩得，比数仓里数据倾斜还坑。

　　最后没办法，只能手动清理日志，腾出空间重建索引。跑完之后，慢查询没了，CPU也降下来了，但那兄弟的网站还是卡——因为缓存没更新，用户还是读到旧数据。我说：“你这缓存策略也得改啊，不能光靠数据库扛。”他说：“缓存是开发管的，我们运维不管这个。”我差点没气背过去——合着运维只管数据库，不管业务？这就像医生只管开药，不管病人吃不吃，病能好吗？

　　这事儿让我想起数仓里的备份策略。之前有个项目，备份脚本写错了，只备份了增量日志，没备份全量数据。结果有一天主库炸了，恢复的时候发现增量日志和全量数据对不上，数据丢了不少。开发说：“我们业务允许数据丢失，反正最后会同步。”我听了直摇头——允许数据丢失？那要备份干嘛？直接删库跑路算了。后来我们改了备份策略，全量+增量分开备份，还加了校验步骤，虽然麻烦，但至少数据不会丢。

文章配图，仅供参考

　　现在想想，网站卡壳这事儿，跟数仓里的ETL卡壳差不多，都是“优胜劣汰”的结果。技术好的，早把索引、缓存、监控都弄好了，卡壳的概率低；技术烂的，天天救火，还怪环境不好。我原以为运维和开发能一起成长，结果发现，有些人永远在踩坑，永远在甩锅。下一步我打算写个自动化脚本，定期检查索引碎片，自动重建，省得再被这种破事儿折腾——毕竟，谁也不想半夜被电话吵醒，说网站卡壳了。

　　不过话说回来，这脚本能不能跑通，我还说不准。毕竟，开发写的SQL，有时候连他们自己都看不懂，更别说脚本了。但至少，能少踩几个坑，少救几次火，也算值了。

（编辑：站长网）

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