做服务器维护这行，天天跟日志打交道。每天成千上万条访问记录、错误信息、系统告警，不入库存起来，查问题就是大海捞针。可别小看‘入库’这两个字，真干起来，哪儿都是细节。
日志格式乱，入库直接报错
上周接手一个老项目，PHP 和 Python 混着跑，日志格式五花八门。有的带时间戳，有的不带；IP 地址有时候是字段，有时候混在消息里。拿脚本往数据库一塞，没跑十分钟就卡住了——字段长度超了，或者类型对不上。后来只好先加一层清洗，把每条日志按统一结构拆解，再插进 MySQL。现在想起来还头疼。
高频写入，数据库扛不住
小公司一开始用单台 MySQL 接日志，看着挺稳。结果某天营销活动上线，QPS 翻了十倍，写入直接把数据库打满，连带业务接口全挂。后来改用 Redis 做缓冲，先把日志扔进去，再由后台任务批量拉取入库。虽然延迟了几秒，但系统稳了，半夜也不用被报警叫醒了。
批量插入更高效
一条一条 INSERT 太慢，尤其日志这种高频数据。我们现在的做法是攒够 500 条，拼成一次批量插入：
INSERT INTO logs (timestamp, ip, method, path, status) VALUES
('2024-03-15 10:01:02', '192.168.1.100', 'GET', '/api/user', 200),
('2024-03-15 10:01:03', '192.168.1.101', 'POST', '/api/login', 401),
('2024-03-15 10:01:04', '192.168.1.102', 'GET', '/static/css/app.css', 200);实测下来，比单条快了七八倍，数据库压力也小多了。
别忘了设置索引和分区
日志表越来越大，查“昨天下午三点到四点的 500 错误”这种需求，全表扫描根本没法忍。我们在 timestamp 字段上了索引，又按月做了表分区。现在查一个月内的数据，基本秒出。
入库不是终点
数据进去了，还得能拿出来。我们搭了个简单的 Kibana 看板，运维同事点几下就能查异常趋势。有时候业务方来问“某个用户啥时候注册的”，翻日志比翻数据库还快。入库这事儿，做得好是隐形功臣，做不好就是半夜重启的元凶。