最近公司项目从 MySQL 切到了 MongoDB，原本以为只是换个存储方式，结果上线没多久，半夜就被报警叫醒。数据同步延迟、索引失效、内存爆了……一系列问题接踵而来。这才意识到，非关系型数据库虽然灵活，但运维起来真不是省油的灯。
结构自由，代价是管理混乱
关系型数据库有严格的表结构和约束，字段类型、外键、唯一性都提前定好，改一个字段都得小心翼翼。而非关系型比如 MongoDB、Cassandra 这类，文档结构可以随时变，同一个集合里，一条记录有 name 字段，另一条可能直接变成 title，程序不处理好，查着查着就出错。
时间一长，没人记得清某个字段到底在哪些地方被用了。新人接手项目，光看数据都得花两天理清楚逻辑。这种“自由”，其实给后期维护埋了雷。
监控和调优不像 MySQL 那么成熟
MySQL 用 SHOW PROCESSLIST 能立刻看到慢查询，配合 EXPLAIN 分析执行计划，调优路径清晰。但换成 Redis 或者 Elasticsearch，命令分散，指标五花八门。Redis 的内存碎片率怎么看？Elasticsearch 的 segment 合并是否正常？得自己写脚本、搭 Grafana 面板，不然出了问题只能靠猜。
有一次线上搜索变慢，查了一圈才发现是 ES 某个节点磁盘满了，自动只读了，但告警没配置，等发现时已经影响了用户下单。
备份恢复更考验经验
MySQL 有 mysqldump、xtrabackup，流程标准化，定时任务一设，基本稳了。但 MongoDB 的备份策略就得考虑分片、副本集状态，用 mongodump 有时候还漏数据。恢复的时候更是麻烦，特别是跨版本迁移，稍不注意就起不来。
mongodump --host rs1/mongo1:27017,mongo2:27017 --db myapp --out /backup/20241201这行命令看着简单，但如果副本集主节点切换过，或者 oplog 不完整，备份出来的数据可能就不一致。真出事了，恢复十分钟能搞定还是得重搭环境，全看平时有没有踩过坑。
没有统一规范，团队协作成本高
小团队用 Redis 存会话，有人习惯用 hash，有人偏爱 string 加 JSON，命名也不统一。时间一长，缓存键名五花八门，清理过期数据都得逐个核对。加上文档缺失，离职交接基本靠口述。
反观 MySQL，哪怕命名不规范，至少能通过 INFORMATION_SCHEMA 查表结构，非关系型数据库就没这么方便了。
不是不能用，而是得懂怎么管
非关系型数据库在高并发、灵活 schema、横向扩展上确实有优势。比如用户行为日志用 Elasticsearch 查起来飞快，商品推荐用图数据库也顺手。但这些好处的前提是：你得愿意花时间把运维体系搭起来。
该做的不能少：定期巡检、容量规划、访问模式分析、异常告警。最好还能有个内部文档，记录每个库的用途、关键指标、常见问题处理方式。别等到半夜被叫起来，才开始翻手册。