Google Cloud Cloud SQL 和 Compute Engine 自建 MySQL 怎么选

在Google Cloud上部署MySQL，很多人第一反应是比较服务器价格：一台Compute Engine虚拟机多少钱，Cloud SQL一个实例多少钱。但真正做过生产数据库的人通常知道，账单只是问题的一半。数据库最大的成本有时候不是CPU、内存和磁盘，而是凌晨两点收到报警以后，谁负责处理复制中断、磁盘故障、备份失败、版本升级和数据库恢复。

Cloud SQL和Compute Engine上的MySQL，本质上代表两种不同的工程模式。Cloud SQL是Google Cloud提供的托管数据库服务，Google负责大量底层基础设施和数据库运维工作；Compute Engine则更接近传统服务器模式，你租的是一台云服务器，MySQL本身由你安装、配置、升级和维护。Google官方也明确提供了在Compute Engine上自行安装和配置MySQL的方案，因此两者并不是“一个能用，一个不能用”，而是控制权和运维责任的分配不同。

Cloud SQL最直接的优势是减少数据库基础设施的日常管理。备份、监控、日志、维护、部分复制和高可用能力由Cloud SQL提供，用户不需要像传统服务器那样自己维护整个操作系统和数据库服务器环境。对于普通网站、SaaS应用、企业内部系统或者需要快速上线的项目，这意味着开发人员可以把更多时间放在应用本身，而不是研究MySQL参数和磁盘故障。

但“托管”并不等于“什么都不用管”。Cloud SQL仍然需要选择实例规格、存储、数据库版本、网络方式、备份策略、用户权限、连接池和索引设计。数据库慢查询不会因为搬进Cloud SQL以后自动消失，SQL写得不好仍然会慢，索引设计错误仍然会让CPU飙升。Google负责的是数据库基础设施的大量运维工作，而不是替你优化业务SQL。

高可用方面尤其需要区分普通实例和HA实例。Cloud SQL可以配置区域级高可用，将主实例和备用实例分布在同一区域的不同可用区，并通过同步复制保持数据冗余。发生相应基础设施故障时，Cloud SQL可以自动进行故障切换。Google目前的文档明确说明，高可用配置属于regional availability，而没有配置HA的实例属于zonal availability，两者的故障恢复能力并不相同。

因此，不能简单写成“Cloud SQL自动故障转移，而Compute Engine必须手动处理”。如果在Compute Engine上自建MySQL，完全可以使用复制、故障转移工具、负载均衡、监控和自动化脚本构建高可用系统，只是这些组件需要由你的团队设计、部署、测试和维护。Google甚至提供了针对Compute Engine MySQL工作负载的配置建议，包括实例类型、存储和性能优化，但最终的数据库架构责任仍然在使用者一侧。

自建MySQL真正吸引人的地方，是控制权。Compute Engine允许你更加直接地控制操作系统、MySQL配置文件、文件系统、磁盘、网络拓扑以及数据库运行环境。对于某些需要特殊参数、特定插件、特殊复制方式或者非常规数据库架构的系统，这种自由度非常重要。Google自己的文档也把“需要高级参数控制”和“特定性能需求”等列为可能选择Compute Engine自建MySQL的场景。

例如，一个团队可能希望调整MySQL底层参数，使用特定的备份工具，建立完全自定义的复制架构，或者让数据库与某些特殊的软件系统紧密结合。在Cloud SQL受到服务边界限制的情况下，自建MySQL就可能更加方便。代价也很直接：你获得了更多控制权，同时也获得了更多需要自己解决的问题。

运维差异到了生产环境会更加明显。Compute Engine上的MySQL不仅仅是安装一个mysql-server然后设置root密码。生产环境通常还涉及操作系统补丁、MySQL版本升级、磁盘空间、I/O性能、备份验证、日志轮换、权限管理、TLS、网络访问、监控、慢查询、复制延迟、故障恢复以及灾难恢复。真正成熟的自建数据库团队，还需要定期进行恢复演练，因为“备份成功”与“真的能够恢复”完全是两回事。

Cloud SQL则把其中相当一部分工作交给Google Cloud。Google官方文档列出的托管范围包括备份、高可用与故障转移、网络连接、导入导出、维护更新、监控和日志等。Cloud SQL的自动备份和时间点恢复能力也可以减少团队自行搭建备份基础设施的工作。

不过，Cloud SQL也不是一个跨区域灾难恢复的万能按钮。区域级灾难仍然需要单独设计DR方案。Google的文档明确指出，如果承载Cloud SQL数据库的Google Cloud区域整体不可用，仅配置区域内HA并不能解决跨区域灾难恢复问题，需要考虑跨区域只读副本等方案。

成本方面也不能简单得出“Cloud SQL贵、自建便宜”的结论。Cloud SQL的账单通常包含实例计算资源、存储、备份、网络等不同部分；如果配置HA，相关成本也会增加。Google目前还提供Cloud SQL committed use discounts，也就是Committed Use Discounts（CUD），适合长期稳定运行的数据库负载。官方当前文档显示，符合条件的Cloud SQL计算和内存使用可以采用一年或三年的承诺折扣，但存储、备份、IP地址、网络出站流量等并不包含在CUD适用范围内。

因此，不能把Cloud SQL理解成“数据库不用管，所以一定更贵”，也不能认为“Compute Engine只要一台VM，所以一定便宜”。如果一个公司为了节省几百美元云账单，却需要数据库工程师花大量时间维护备份、升级、监控和故障恢复，那么服务器账单降低了，实际总成本却可能上升。反过来，如果团队本身就有成熟的数据库自动化平台，自建MySQL的一部分运维成本已经被内部工具消化，那么Compute Engine的经济性可能发生变化。

还有一个非常容易被忽略的问题，就是数据库与应用之间的网络路径。如果应用本身就在Google Cloud中，Cloud SQL可以通过私有网络方式提供数据库连接；Compute Engine上的MySQL同样可以放在VPC内部，通过私有IP限制访问。真正需要测试的是实际应用的连接延迟、并发连接数、连接池配置和数据库I/O，而不是看到两个服务都在Google Cloud就认为性能自然相同。

对于普通中小型网站，如果数据库主要负责用户账户、文章、订单、后台管理等标准MySQL业务，而且团队并没有专门的DBA，那么Cloud SQL通常可以显著降低基础设施运维工作。尤其是网站已经运行在Google Cloud生态中时，托管数据库能够减少服务器层面的维护项目。

如果数据库是企业核心系统，对稳定性、恢复时间和审计有较高要求，那么应该重点评估Cloud SQL的HA、备份、PITR、权限、日志以及跨区域DR设计，而不是只看一台实例的月租价格。Cloud SQL的HA能力需要主动规划和配置，并不是创建普通实例以后所有高可用能力自动出现。

而对于拥有成熟数据库工程团队的企业，Compute Engine自建MySQL则可以提供更大的操作空间。尤其当系统需要特殊MySQL参数、特殊插件、定制复制架构、非常规存储设计或者更深层次的操作系统控制时，自建方案的价值会更加明显。Google也明确把高级参数控制和特定性能需求列为Compute Engine自建MySQL可能适用的情况。

最终真正应该比较的不是“Cloud SQL一小时多少钱”和“Compute Engine一小时多少钱”，而应该比较整个数据库生命周期的成本和责任。Cloud SQL把大量基础设施工作交给Google，换来的是更低的运维负担和较少的底层控制；Compute Engine把更多控制权交给开发团队，同时也要求团队承担更多数据库基础设施责任。

如果你的核心业务是网站、SaaS、企业应用或者一般交易系统，首先应该从Cloud SQL开始做POC，然后测试真实SQL负载、并发连接、读写比例、备份恢复时间以及峰值性能。如果测试发现Cloud SQL的服务边界确实限制了业务，再考虑迁移到Compute Engine自建MySQL。对于数据库来说，真正昂贵的从来不只是服务器，而是一次没有准备好的故障恢复，以及一个团队长期背负却没有计算进账单里的运维工作。