咱们直接聊Mnesia。这货是Erlang亲生的数据库，天生就长在OTP生态里，跟那些后来硬塞进系统的MySQL、Redis不一样。好多人在生产环境用Mnesia踩坑，其实不是它不行，是配置没到位。今天这篇实战指南，咱们从最基础的配置说起，一路爬到高可用集群搭建，中间该避的坑我一个不落全讲清楚。
先说说基础配置。Mnesia的配置文件很轻，不像MySQL要搞那一套。你只要在Erlang节点启动后，调用，就能在当前节点创建schema。这一步很多人忽略，结果数据存进去发现是临时表，一重启全没了。记住：schema是Mnesia的骨架，不先搭好，后面所有操作都是空中楼阁。我习惯在配置里单独写个init函数，把schema创建、表定义、索引建立全放一起，每次部署跑一次就行。还有个小技巧：生产环境别用默认的schema路径，用指定独立目录，避免和日志混在一起。
接下来聊点干货——表分片。很多人以为Mnesia只能单机玩，其实它支持把表切碎了分布到多个节点。用，就能把user表切成4片，每片在2个节点上存磁盘副本。这里有个坑：分片数量要按数据增长曲线来定。我见过有人把100万条数据分成100片，查询时跨片通信开销比数据本身还大。经验值是每片控制在50万到100万条，太少了浪费节点，太多了查询变慢。调试时用看分布情况，哪片数据不均匀就手动调整。
说到节点管理，这是Mnesia集群的核心。启动节点时用指定长名字，别偷懒用短名，生产环境长名才稳定。加入集群就一行代码：。但光加节点不管用，你还得把schema和表结构同步过去。我一般先在新节点上, 再, ，这样新节点会从现有节点拉schema。注意：删除schema会清空所有数据，生产环境千万别手抖。加完节点后，用确认所有节点都活着，少一个都别往下走。
高可用集群的难点在容错设计。Mnesia默认用主从复制，主节点挂了，从节点只能读不能写。想要真正高可用，得用把从节点升格为对等节点。但这里有个陷阱：对等节点之间的数据同步是异步的，写入主节点后，从节点可能延迟几毫秒才看到。所以你的业务代码里，写操作后需要立刻读的话，得用强制同步。我踩过这个坑：订单系统写入后立即读状态，结果读到旧数据，给客户发了两次货。后来改成写完后等200毫秒再读，才解决问题。如果对一致性要求极高，可以启用监听表事件，写操作完成后回调通知其他节点。
跑生产环境，性能监控绕不开。Mnesia自带的能看内存使用、表数量、事务队列长度。我最常用的是，看哪个表占内存多。遇到过最奇葩的问题：一张log表每天增长快，但数据只有最近7天有用，结果内存被撑爆，整个集群瘫痪。解决方案是写个定时任务，用清理过期数据，同时把表类型从改成，数据落盘就不怕内存爆炸了。还有，事务锁监控也重要。用能看到当前有哪些事务在等锁，如果发现某个事务等锁超过5秒，说明业务逻辑有问题，得优化查询路径。
最终落到集群搭建。假设你有3台机器：node1、node2、node3。先在每台机器上装好Erlang，然后用启动节点，cookie必须一致，否则节点之间认不出来。node1上先启动，执行和, 再创建表。接着node2和node3分别启动，用加入集群。把表副本分布到三个节点：, 。这样任意一个节点挂了，数据还在另外两个节点上。测试时拔掉一个节点的网线，用看剩余节点是否正常，写操作能不能继续。如果发现集群脑裂了（两个节点互相认为对方死了），赶紧在存活节点上手动指定主节点，避免数据冲突。
说点心里话。Mnesia不是万金油，它强在低延迟、强一致性、和Erlang进程的无缝集成。但如果你要处理几百TB的数据，或者需要复杂SQL查询，那还是老老实实用PostgreSQL。Mnesia最适合的场景是：缓存、会话状态、实时排行榜、设备配置信息。我见过最漂亮的用法，是某游戏公司用Mnesia做玩家在线状态管理，百万玩家同时在线，查询延迟不到1毫秒。他们就是严格按照我们刚才说的配置，分片加副本加监控，跑了三年没出过事故。所以别被Mnesia的简陋文档吓到，从基础配置开始，一步步把集群搭起来，你会发现它比想象中靠谱得多。
