一、一个被反复问到的问题“你用的是MySQL还是MongoDB”这是我在技术社区分享简记往来时被问到最多的问题之一。答案MongoDB。原因不是“MongoDB比MySQL好”而是“在这个场景下MongoDB更合适”。二、MongoDB vs MySQL 的核心差异维度MySQLMongoDB数据模型关系型表行文档型CollectionDocumentSchema固定需要迁移灵活可动态变化查询语言SQLJSON-like事务强事务支持多文档事务支持有限扩展性垂直扩展为主水平扩展分片适合数据量GB级TB级三、为什么选MongoDB3.1 Schema灵活简记往来的数据结构在开发过程中变化了好几次。最初只有records表后来加了contacts表再后来给记录加了note字段、created_by字段。如果用MySQL每次加字段都要执行ALTER TABLE迁移数据量大的时候可能锁表几分钟甚至几小时。用MongoDB直接加字段就行不需要任何迁移。3.2 文档型存储更自然礼账的数据是“联系人往来记录”用文档型存储非常自然{contact:{name:张三,tags:[同事]},records:[{type:receive,amount:800,date:2026-06-20},{type:send,amount:500,date:2026-06-20}]}3.3 开发速度快Mongoose ODM 让 MongoDB 的操作非常方便constrecordawaitRecord.create({bookId:currentBookId,contactId:contact._id,type:receive,amount:800});不需要写复杂的SQL JOIN不需要担心外键约束。3.4 水平扩展能力如果用户从6.8万增长到68万、680万MongoDB的分片集群可以无缝扩展。MySQL的分库分表方案要复杂得多需要在应用层做路由。四、MongoDB的不足之处4.1 事务支持较弱MongoDB支持多文档事务但性能不如关系型数据库。简记往来的解决方案尽量把相关数据放在一个文档里减少跨文档操作。4.2 数据分析能力有限MongoDB的聚合框架不如SQL灵活复杂的报表查询可能比较吃力。简记往来的解决方案统计查询直接做聚合62万条数据下响应时间稳定在150ms以内。4.3 对开发者要求更高MongoDB的Schema灵活性是把双刃剑。好的一面是开发快坏的一面是需要开发者自己保证数据一致性。简记往来的解决方案在应用层做好数据校验用Mongoose的Schema定义数据结构。五、什么场景适合MongoDB场景是否适合理由Schema经常变化✅ 非常适合无需迁移文档型数据✅ 非常适合存储自然快速迭代✅ 非常适合开发速度快需要强事务❌ 不太适合事务支持弱于关系型复杂报表⚠️ 部分适合聚合框架够用但不如SQL六、简记往来的真实数据用MongoDB支撑简记往来半年6.8万用户62万条记录日均请求约2万次核心查询响应时间150ms服务器配置2核4G这个配置撑得住。七、总结技术选型的核心原则不选“最好的”选“最合适的”。MongoDB适合简记往来因为它Schema灵活、开发快、易扩展。如果哪天用户量暴增到百万级MongoDB的分片集群也能撑住。但如果你在做的是一个需要强事务、复杂报表的系统MySQL可能更合适。八、第一阶段总结7篇文章从需求发现到技术选型我们把简记往来的“起点”讲清楚了需求从哪里来从自己的真实痛点出发为什么通用App不够用单向流水管不了双向关系技术选型逻辑微信小程序 Node.js MongoDB环境搭建开发者工具 工程化配置项目结构分层架构 目录规范登录鉴权wx.login JWT数据库选型MongoDB vs MySQL第一阶段的目标是“让读者知道我们为什么这么做”而不是“直接给代码”。第二阶段7篇将进入核心功能实现数据模型设计、批量记礼、多账本、多人协作。如果你想继续可以告诉我。评论区聊聊你的项目用的什么数据库选它的理由是什么
