数据库与应用要不要分机

拆不拆数据库，看的不是技术潮流，而是三个具体信号。应用和数据库同机部署在业务初期完全合理，省成本、链路短、运维简单，盲目拆分反而扩大故障面和维护成本。 什么时候值得拆 三个信号：一是内存见顶，数据库要的缓存超过机器内存一半，比如 MySQL 的 innodb_buffer_pool_size 想配 6G 而机器只有 8G，应用就没有余粮；二是 CPU 互相抢，业务高峰期 top 里 mysqld 和 php-fpm 轮流吃满，互相拖慢；三是备份打架，凌晨全量备份把磁盘 I/O 打满，页面响应明显变慢。三条占两条，就该规划拆分了。信号之外再算一笔账：拆分后多一台机器的开销，换来的稳定和独立扩容值不值——多数中小业务的答案是先升配、后拆分。 拆分的正确姿势 拆分不是把数据库搬走就完事，顺序有讲究：先做完整备份，用 mysqldump -u root -p --single-transaction 业务库名 > full.sql 导出全量；在新机器上恢复并跑一天只读验证，确认数据一致；然后把应用配置里的连接串从 localhost 改成新库的内网地址，比如 10.0.0.12:3306；旧机数据保留几天再下线。每一步都留了退路，出问题随时回切。 拆完之后的好处 两边资源独立扩容，数据库内存不够就单独升内存，不用连累应用机；备份、重启、内核升级互不影响；安全上还能把数据库放进不暴露公网的内网段，防火墙只允许应用机访问 3306 端口，暴露面小一大截。还有一点常被忽略：拆分后两台机器可以分别安排维护窗口，夜里升级内核不用整个业务停摆。 机器怎么配 应用机选常规云服务器即可，顺云 S4 这类成长型配置能撑起多数中型站点；数据库机内存优先，S4-8G 适合中型库，数据量大、并发高的核心库可以直接上独享物理资源的裸金属 B4，磁盘 I/O 更稳。 先备份、再迁移、后切换，这条顺序任何时候都不能倒。