监控数据库状态是第一要务
每天早上到公司，泡杯咖啡后第一件事就是打开监控面板。我们用的是Prometheus + Grafana这套组合，搭配MongoDB自带的mongostat工具，能实时看到连接数、内存使用、慢查询数量等关键指标。有一次发现某个时段写入延迟突然升高，排查下来是业务方批量导入数据没走索引，及时沟通调整了写入方式，避免了后续问题。
定期检查索引使用情况
索引不是建完就一劳永逸的。通过db.collection.explain()查看执行计划，结合slow query log分析，能发现哪些查询走了全表扫描。比如用户中心的订单查询接口响应变慢，查了一下发现是最近加了个新字段做筛选，但没加索引。补上之后QPS立马回升。
备份策略不能偷懒
我们采用每日一次全量备份 + 每小时增量oplog备份的方式。使用mongodump时会加上压缩参数减少存储占用：
mongodump --host rs1 --port 27017 --gzip --archive=/backup/mongo_$(date +%Y%m%d).gz恢复的时候也方便：
mongorestore --host rs1 --port 27017 --gzip --archive=/backup/mongo_20240405.gz曾经因为误删集合导致数据丢失，靠这个机制在20分钟内完成恢复，没造成太大影响。
副本集状态要常看
进入mongo shell后习惯性运行rs.status()，看看主从节点是否正常，有没有处于RECOVERING或ROLLBACK状态的成员。有次发现一个secondary长时间同步不上，原来是网络抖动导致oplog拉取失败，重启后自动追平。
清理无用数据有讲究
日志类集合增长飞快，直接drop collection太粗暴。我们用TTL索引自动过期：
db.logs.createIndex({"createTime": 1}, {expireAfterSeconds: 604800})相当于一周前的数据自动清除，省心又安全。
性能调优从小处着手
观察到内存命中率下降时，优先考虑是不是工作集变大了。适当调整WiredTiger缓存大小（storage.wiredTiger.engineConfig.cacheSizeGB），但我们一般设为物理内存的60%左右，留点余地给系统和其他进程。别盲目加大，反而可能触发swap。
权限管理不能松懈
给不同服务分配独立账号，按最小权限原则授权。比如报表系统只能读特定库：
db.grantRolesToUser("report_user", [{ role: "read", db: "analytics" }])这样即使凭证泄露，影响范围也可控。
运维这活儿说白了就是“防患于未然”。MongoDB看着挺稳，真出事往往是小问题积累成的。把这些日常动作养成习惯，比啥高大上的架构都管用。