技术帮助 · 发布时间：
网站准备离开共享托管时，数据库和邮件不必迁往同一处。数据库影响网页、订单或会员功能；邮件则涉及收发、历史信件和域名信誉。处理从共享托管迁出时数据库与邮件服务的拆分方案，关键是先厘清依赖，再安排两类服务各自的迁移与切换，避免只搬网站却漏掉邮箱。
第一步：盘点现状，先决定哪些服务要迁
列出网站使用的数据库类型与版本、数据库名称、网站连接配置、邮箱地址、邮箱容量及现有邮件协议。还要检查联系表单、密码重置通知和网站程序是否使用托管商提供的 SMTP 发信功能。共享主机控制面板里的邮箱和网站文件可能共用一个账户，但并不代表迁出时必须一起移动。
如果邮箱使用量很少、依赖简单，可以先保留在原服务商，只迁网站和数据库；如果原主机账户即将关闭，或邮箱容量、管理权限不够，再安排邮件迁移。记录所有 DNS 项目，尤其是 MX、SPF、DKIM 和 DMARC；这些记录关系到邮件投递，不应随手照搬旧值。
第二步：选定拆分方式，对照成本与责任
| 方案 | 适用条件 | 主要优点 | 需要承担的事项 |
|---|---|---|---|
| 数据库迁至独立数据库服务，邮件暂留原处 | 原邮箱可靠且原托管账户仍可用 | 改动较少，邮件切换风险低 | 核实原服务续用条件，并维护两处服务的账户与续费 |
| 数据库迁至新网站主机，邮件另用专门邮件服务 | 希望网站与邮件分别管理，且愿意分开配置 | 服务边界清楚，单一服务调整时较容易独立处理 | 分别管理数据库连接、邮箱账户及 DNS 记录 |
| 数据库与邮件都迁往新供应商 | 旧主机即将停用，或计划一次整理全部服务 | 减少对旧账户的依赖 | 迁移工作最多，必须分别验证网站数据和邮箱内容 |
选择从共享托管迁出时数据库与邮件服务的拆分方案时，应按实际依赖和维护能力决定，而不是只比较报价。独立数据库服务通常需要确认网络访问权限、备份方式和连接限制；专门邮件服务则要确认域名验证、发信认证及邮箱迁移能力。
第三步：先搬数据库并验证网站
- 备份：从旧环境导出数据库，并保存原始备份；记录字符集、排序规则、数据库版本和网站所用的连接参数。
- 导入：在目标环境建立数据库与专用账户，导入数据后，按新服务要求调整主机地址、权限和连接配置。
- 测试：用临时预览方式检查首页、登录、搜索、表单提交及关键业务流程。若数据在导出后仍会变化，可在正式切换前安排短暂维护或只读窗口，再补做最终同步。
数据库迁移是否顺利，不能只看导入命令是否成功。还要检查记录数量、关键页面内容、时区与字符显示；不同版本或配置可能造成兼容差异，应以目标环境测试结果为准。
第四步：单独搬邮箱，核对邮件认证
如果决定迁移邮件，先在新服务创建同名邮箱，再通过 IMAP 复制旧邮箱中的文件夹和邮件。IMAP 主要用于同步服务器上的邮件内容，联系人、日历、过滤规则和客户端本地存档未必会一并迁移，需按实际使用情况另行导出或重设。大型邮箱耗时受容量、连接速度和服务端限制影响，宜先迁移历史邮件，切换后再补同步新增邮件。
切换发信前，按新邮件服务提供的配置更新 SPF，并发布其 DKIM 密钥；DMARC 策略也要检查是否与发件来源相符。不要把旧 SPF 记录直接替换成新值而遗漏网站程序等合法发信来源，否则可能影响投递。
第五步：安排 DNS 切换并留出回退时间
- 提前核对新网站 IP、邮件服务要求的 MX 和发信认证记录；DNS TTL 可在切换前适当调低，例如设为几分钟到一小时，具体取决于 DNS 服务支持范围。
- 先切换网站所需的 A 或 CNAME 记录，再按邮件迁移计划调整 MX。两者可以分开进行，降低同时变更造成的排查难度。
- 切换后分别测试网站读写、表单发信、外部收信与回复，并关注旧邮箱是否仍收到新邮件。不同 DNS 缓存的更新速度不一，旧环境应保留一段观察期。
如新环境出现故障，可按预先记录的旧记录回退，并确认回退后数据写入位置，避免新旧数据库同时接收写入而产生分叉。完整的从共享托管迁出时数据库与邮件服务的拆分方案，应把备份、验证和回退条件一起写进计划，而不只是列出切换日期。
常见问题
数据库和邮件必须同一天迁吗？
不必。先迁数据库并验证网站、之后再迁邮箱，通常更容易定位问题；但需确认旧邮件服务在过渡期间仍可用。
只改 MX 记录会自动搬走旧邮件吗？
不会。MX 记录决定新邮件投递到哪里，旧邮件仍在原邮箱，需使用 IMAP 等方式迁移或按需归档。
迁移期间网站邮件会不会发不出去？
可能。网站程序常需单独配置 SMTP 发信；切换前测试认证信息、发件地址和 SPF、DKIM 设置，并保留故障时可用的旧配置。
什么时候可以关闭旧托管账户？
确认网站功能、数据库备份、历史邮件和 DNS 均已核验后再决定。若仍有旧邮件或回退需求，应先保留旧服务直至观察期结束。
