运维日志

线上昵称里带个 emoji，存进库变成 「ðŸ」；一次迁移之后，原本正常的客户备注全成了 「???」。这种字符集乱码，八成不是「数据库坏了」，而是 server、database、table、column、连接层五层字符集没对齐。MySQL 的 utf8 其实是 3 字节的假 utf8，存不了 emoji，真正能存全 Unicode 的是 utf8mb4。从现象反推根因，顺手把已经乱掉的数据救回来。

凌晨两点，一台共用机器 load 飙到 80，SSH 都卡。查下来是个批处理脚本 fork 爆炸，把整台宿主的 CPU 和内存吃光。这种「一个进程搞死全机」的事，ulimit 管不住、nice 降优先级也只是缓解。真正的答案是 cgroup v2——配合 systemd 的 resource control，给每个服务画好 CPU、内存、IO 的硬边界，谁越界谁先死，绝不连累邻居。

PG 跑几个月后表体积翻了好几倍、查询越来越慢，但数据量没怎么涨——多半是 MVCC 死元组没清掉，表膨胀了。讲清死元组怎么来的、怎么量化膨胀率、autovacuum 为什么没跟上，以及手动 vacuum / 重建表 / 参数调优的具体操作，附我线上踩过的坑。

进程卡住不动、接口莫名变慢、启动就报权限拒绝——这些毛病用 top 看不出所以然。strace attach 上去追踪系统调用，能直接看到进程卡在哪个 syscall、等了多久、读写是否正常。本文讲清 attach、过滤、-e 表达式、耗时统计，以及线上不敢随便 strace 时的替代打法。

一张 5000 万行的订单表要加个索引，直接 ALTER 一跑，写入全卡、连接堆成山、从库延迟飙到几分钟——这是每个 DBA 都挨过的打。MySQL 8.0 的 ALGORITHM=INSTANT 覆盖不了所有场景，真要大表变更得靠 pt-online-schema-change 和 gh-ost 这类影子表工具。一个用触发器、一个靠 binlog，把两条路都跑通，连同坑点一起摊开。

服务半夜开始报错 accept4() failed (24: Too many open files)，或者 Nginx 频繁 502。这种故障十次有八次是文件句柄（fd）耗尽，但光改 ulimit -n 往往没用——因为 systemd 起的服务根本不吃 limits.conf 那套。从内核 file-max 到进程 LimitNOFILE，到定位到底是哪个进程在漏 fd，把每一层都讲透，并给出不停机临时救急和永久修复两条路。