建站新手必避的7大运维坑：第5个90%人忽略的性能隐患

　　2025年5月，凌晨一点零七分，慢查询告警堆到第19条——不是阈值设低了，是它真在那儿炸。我盯着那个执行计划里嵌了三层子查询、外加两个函数索引失效的SELECT，手还悬在键盘上没敲完kill，运维老张端着保温杯路过工位，探头问：“好了没？”我摇头，他叹气，杯盖都没拧紧就走了。风扇一直在转，嗡嗡的，比平时响半档。

　　第5个坑？就是建站新手连日志都不翻就上线的那个“默认配置”。不是MySQL的wait_timeout，不是Redis的maxmemory策略，是那个被所有人当摆设的——slow_query_log=OFF。对，关着。连ON都懒得点。不是不懂，是压根没进过my.cnf看第三行。我原以为顶多是业务测得糙、监控埋得浅，结果翻生产库配置时发现：log_output=file，但目录是/var/log/mysql/——而那个目录权限是700，属主是root，mysql用户连touch都touch不了。所以慢查询日志？从来就没写进去过。一行都没有。你猜那19条告警是怎么来的？是Zabbix在扫processlist，靠Rows_examined > 50000硬扛出来的“疑似慢查”。

　　开发小王推门进来，T恤上印着“if (true) { coffee(); }”，手里捏着刚改完的迁移脚本。他说：“查得慢不怪SQL，怪服务器IO差。”我点头，顺手把刚才抓到的执行计划截图发他微信，他回了个[OK]表情，三分钟没说话。后来他发来一句：“这字段类型怎么是TEXT？”——对，就是那个被WHERE条件反复扫描的字段，建表时写成TEXT，没加前缀索引，也没考虑FULLTEXT，就为图省事填了个“支持长文本”。我懒得说，因为上周他刚在另一个库里把datetime写成varchar(20)，理由是“前端传过来就是字符串”。窗外天黑了，整层楼只剩我们俩工位亮着，灯带是那种偏冷白光，照得键盘上的油光特别清楚。

　　这不是技术问题。这是筛选器。优胜劣汰，真的。能活过三个月还没被慢查询搞崩的站，要么背后有人天天盯EXPLAIN，要么业务本身就没啥并发——后者居多。剩下那些撑不过一周的，八成死在这儿：他们以为性能问题是“突然发生的故障”，其实是“一直沉默的尸体”，只等第一个真实用户点击登录按钮，才被进程树里暴涨的线程数捅出来。我见过最绝的是一个教育类SaaS，注册页提交卡住二十秒，运维去查，发现连INSERT INTO user VALUES(...)都在等锁——因为上一条update还在事务里挂着，而那个事务开头是个SELECT FOR UPDATE，锁定的是整个user_status表。为啥？因为开发觉得“状态得强一致”，没想清楚隔离级别和业务容忍度之间隔着八百公里山路。

　　外卖凉了。盒盖掀开全是凝固的油星子，我扒拉两口就不动了。想起来早上值班的李工跟我说：“备份策略我调过了，现在每四小时全量一次，binlog实时归档。”我说好，他眨眨眼：“不过恢复脚本我还卡在验证checksum那一块——老报错，估计是磁盘读出来有坏块，但没空重做校验。”我没接话。这种事儿不能接。你一接，下一句就是“要不你帮看看？”然后你发现他连xtrabackup的日志输出都没截全，只截了最后三行ERROR。我喝口凉茶，喉咙有点涩。这事跟慢查询没关系，但它在同一条时间线上：都是“以为没问题，其实早坏了”的典型。

　　领导下午开会时讲“降本增效”，说了十七分钟，PPT里有张图叫《全链路可观测性建设蓝图》，箭头从Nginx画到K8s再到DB，最后一格写着“自愈能力”，底下小字“规划中”。没人提日志开关的事。散会后我回工位，发现屏幕上行数一直在跳——是top命令没关，PID列数字像骰子一样狂滚。我顺手kill了，又开了个新的，这次加了-d 3参数。其实没必要，但手痒。

　　有人问我：为什么不一开始就配好？我答不上来。可能是因为第一个需求太急，老板说“今晚必须上线”，运维同事同时在救另外三个集群的内存泄漏；也可能因为新人心里有个幻觉，觉得“只要功能跑通，性能是以后的事”——像减肥，总想着“等我忙完这阵”。但现实是：性能债不滚利息，它直接生娃。一个慢查询养出三个连接池满，三个连接池满再拖垮下游服务健康检查，健康检查失败又触发熔断误判……最后你看到的崩溃，是三个月前那个没开slow_log的深夜决定，用递归方式投胎回来讨债的。

文章配图，仅供参考

（编辑：我爱制作网_池州站长网）

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