Cloud SQL for MySQL 怎么部署，生产环境创建数据库前应该检查哪些配置

Cloud SQL for MySQL 是 Google Cloud 提供的托管 MySQL 数据库服务。与自己在虚拟机上安装 MySQL 不同，Cloud SQL 已经把操作系统、数据库软件维护、备份、高可用和部分基础设施运维工作托管给Google，因此生产环境部署时不能简单照搬传统 MySQL 服务器的配置方法。

尤其是在创建实例之前，数据库版本、Cloud SQL Edition、区域、机器规格、存储、网络、高可用、备份、连接认证以及监控策略，都应该先确定。实例创建以后，有些核心属性并不能随意修改，例如区域和数据库大版本，因此版本和区域选择错误，后期调整的成本会比较高。

首先要检查数据库版本。

Cloud SQL for MySQL目前已经不是只有MySQL 5.7和8.0。Google当前文档显示，Cloud SQL支持MySQL 5.6、5.7、8.0、8.4和9.7，其中8.4是默认版本，9.7已经在2026年8月进入支持范围。MySQL 5.7虽然仍然存在，但已经进入扩展支持阶段，因此新生产系统没有兼容性要求时，没有必要再把5.7作为默认选择。

如果应用依赖旧版本MySQL的特定行为、驱动或者SQL语法，则应该先在测试环境验证升级兼容性，而不是因为“生产环境求稳定”就长期停留在老版本。稳定并不等于永远不升级，数据库大版本的生命周期本身就是生产运维的一部分。

其次是Cloud SQL Edition和实例规格。

Cloud SQL目前提供Enterprise和Enterprise Plus等不同能力组合。Enterprise Plus提供更高的可用性目标以及更大的机器配置范围，并包含部分额外性能能力。因此，生产数据库不应该只按照“CPU越多越好”选择规格，而应该根据查询类型、并发连接、内存使用、磁盘I/O和业务峰值进行测试。

对于MySQL来说，内存尤其重要，因为InnoDB需要利用内存缓存热点数据和索引。但这并不意味着应该在创建实例时直接修改innodb_buffer_pool_size，然后期待性能自动提升。Cloud SQL对数据库参数有自己的支持范围，应该先查看当前Cloud SQL版本允许修改的数据库flags，再根据实际负载调整。

数据库连接数同样不能简单设置成一个所谓的“生产标准值”。max_connections应该结合实例内存、应用连接池规模、查询耗时以及并发模型确定。应用如果启动大量连接，而每个连接长期保持空闲，数据库可能还没有达到CPU瓶颈，就已经因为连接和内存压力出现问题。

网络设计则应该尽可能在实例创建阶段确定。

对于部署在Google Cloud内部的生产应用，Private IP通常是重要选择。这样应用可以通过VPC内部网络访问数据库，而不需要把数据库作为一个面向互联网的服务暴露出来。如果使用Cloud SQL Auth Proxy或者Cloud SQL语言连接器，则还可以通过Google Cloud的身份和连接机制管理访问。Cloud SQL Auth Proxy支持Private IP和Public IP，并通过TLS保护连接。

这里有一个很容易产生误解的地方：Cloud SQL并不是普通的Compute Engine虚拟机，所以不能把“开放3306端口”当成部署Cloud SQL的标准步骤。使用Public IP时，Cloud SQL有自己的authorized networks等访问控制机制；使用Private IP时，则主要依赖VPC网络路径和相关配置。

如果应用通过Cloud SQL Auth Proxy连接，也不应该随意让Proxy监听0.0.0.0。Google明确提醒，如果Proxy绑定到外部接口，那么能够访问这个接口和端口的用户可能获得连接实例的机会。默认情况下，Proxy使用本地地址监听，可以减少这类暴露。

身份认证也需要区分两个层面。

第一层是Google Cloud IAM，它决定哪个用户、服务账号或者应用有权连接Cloud SQL。第二层是MySQL数据库本身的用户和数据库权限，它决定连接以后能够访问哪些数据库和执行哪些操作。

Cloud SQL支持IAM数据库认证。使用这种方式时，需要相应的Cloud SQL Instance User权限；如果通过Cloud SQL Auth Proxy连接，还需要Cloud SQL Client权限。IAM用户进入数据库以后并不会自动获得所有数据库权限，仍然需要按照数据库对象和业务需求授予相应权限。

因此，生产环境没有必要让应用一直使用具有全部权限的数据库账号。应用应该使用专用账号，并只授予完成业务所需要的权限。数据库管理员账号、迁移账号和应用运行账号也应该尽量分开。

加密方面，Cloud SQL本身已经对数据进行加密，连接也可以使用TLS。Cloud SQL Auth Proxy会自动建立加密连接，不需要按照传统自建MySQL的方法手工维护一套数据库服务器SSL证书。当前Cloud SQL Auth Proxy文档显示，其连接使用TLS进行保护。

如果业务有更严格的合规要求，还可以进一步配置Cloud SQL的SSL模式。例如，Cloud SQL支持要求加密连接，甚至要求经过验证的客户端证书。具体模式应该根据应用连接方式和安全要求选择，而不是简单写成“必须使用TLS 1.2”。

存储配置同样需要认真规划。

Cloud SQL实例可以选择SSD或者HDD存储，并可以设置初始存储容量。更重要的是，可以启用自动存储扩容，并设置自动扩容上限。对于生产数据库，存储空间长期接近满载是一个需要避免的状态。Google的运维指南明确把持续高磁盘使用率列为需要处理的资源约束，并建议合理配置自动存储扩容。

Cloud SQL的存储容量可以增加，但不能缩小。因此，不能简单为了“以后够用”而无限制地预留容量。比较合理的方法是根据当前数据库规模、增长速度和备份需求确定初始容量，同时开启合理的自动扩容机制。

高可用性是生产环境与测试环境的重要区别。

如果业务无法接受单个可用区故障导致数据库长时间不可用，应考虑将实例配置为Regional高可用。Cloud SQL的高可用机制会在不同可用区配置备用实例，主实例出现符合条件的故障时进行故障转移。Google当前文档把Regional配置作为生产实例推荐的高可用模式。

但是，高可用和跨区域灾难恢复是两件不同的事情。

Regional HA主要解决区域内部的可用区级故障，而跨区域灾难恢复则可以使用跨区域read replica等方案。跨区域副本采用异步复制，因此不能假设主数据库提交的数据在任何时刻都已经同步到另一个区域。复制延迟、RPO以及灾难发生时需要执行的提升副本流程，都应该在正式上线前测试。

备份策略也不能简单照搬传统服务器的“每天增量、每周全量”。

Cloud SQL已经提供自动备份和Point-in-Time Recovery。Google当前文档显示，Cloud SQL的自动备份和PITR可以用于数据保护，而且高可用实例要求启用这些功能。Cloud SQL的托管备份采用Persistent Disk快照机制；如果业务还有逻辑备份、迁移或者特定恢复需求，也可以另外使用MySQL的逻辑备份工具。

更重要的问题不是“有没有备份”，而是“出了问题能不能恢复”。

生产环境应该明确RPO和RTO。例如，数据库误删数据以后，希望能够恢复到多早以前；实例完全损坏以后，希望多少分钟或者多少小时内重新提供服务。然后根据这些目标选择PITR、备份恢复、read replica以及跨区域灾难恢复方案。

监控方面，Cloud Monitoring已经能够提供Cloud SQL的CPU、存储、连接以及数据缓存等指标。CPU利用率并不是唯一需要观察的指标，持续高CPU、高内存压力、高磁盘使用率以及连接数异常，都可能说明实例规格或者应用访问模式存在问题。

因此，不建议在文章中简单规定“CPU超过80%持续5分钟就扩容”。80%可以作为某些业务的告警参考，但不是Cloud SQL的统一扩容标准。数据库性能问题经常发生在CPU没有达到极限的时候，例如某条SQL出现严重锁等待、索引失效、磁盘I/O成为瓶颈，或者连接池建立了大量长期空闲连接。

慢查询分析也应该以实际业务为基础。可以从慢查询日志、Query Insights以及数据库性能指标寻找问题，然后使用EXPLAIN等工具分析SQL执行计划。与其规定“超过10秒就算慢”，不如根据业务建立查询延迟基线。对于一个在线API来说，几百毫秒可能已经很慢；对于后台报表，一条执行几秒甚至几十秒的查询可能完全可以接受。

Cloud SQL也不是一个可以随意安装各种系统软件的普通Linux服务器。数据库参数、操作系统、存储和维护工作受到Google托管架构的限制。生产环境应该优先使用Cloud SQL提供的配置、数据库flags、监控和连接工具，而不是试图像管理自己的MySQL虚拟机一样修改底层系统。

应用连接方面，Cloud SQL连接器和连接池应该一起考虑。连接池不是越大越好。假设数据库只能稳定处理一定数量的并发查询，而应用服务器开了大量连接池，最终结果可能是数据库同时收到大量竞争请求。合理的连接池大小应该结合应用实例数量、数据库最大连接数和实际查询并发进行测试。

如果使用Cloud Run、GKE或者其他会水平扩展的计算平台，还要特别注意这一点。假设单个应用实例配置50个数据库连接，当应用从2个实例扩展到20个实例时，理论连接数量可能从100迅速增加到1000。数据库可能在应用CPU还没有出现明显问题之前，就先被连接数和查询并发压垮。

至于Redis，也不能把它当成Cloud SQL性能问题的默认解决方案。只有经过监控和SQL分析确认数据库重复读取、热点数据或者缓存需求以后，才应该增加缓存层。缓存会引入一致性、失效和更新问题，因此它不是数据库索引优化的替代品。

最后是成本控制。

Cloud SQL成本主要来自实例计算资源、存储、备份以及相关网络等方面。生产环境不能只看数据库CPU平均使用率，还应该结合峰值负载、内存、磁盘空间、I/O和业务增长判断实例是否配置合理。

对于低负载数据库，可以评估是否使用更小的实例；对于稳定且长期运行的生产负载，可以进一步比较适合的Cloud SQL定价和承诺方案。对于数据归档，也应该从业务访问频率和合规要求出发设计，而不是简单地把所谓“冷数据”全部压缩后留在数据库中。

一个比较稳妥的Cloud SQL生产部署流程，应该是先确定数据库大版本和Edition，再确定区域和机器规格，然后设计Private IP或其他连接路径，配置存储和自动扩容，启用生产所需的高可用和备份，确定IAM与数据库用户权限，再配置Cloud SQL Auth Proxy或Cloud SQL Connector以及应用连接池。数据库创建完成以后，再进行SQL性能基线、监控告警、备份恢复测试和故障转移测试。

其中最容易被忽视的是恢复测试。一个数据库即使每天都有自动备份，如果从来没有实际执行恢复演练，生产团队仍然不知道出现误删除、实例故障或者区域级灾难时究竟需要多长时间才能恢复业务。

Cloud SQL的价值就在于把大量底层数据库运维交给Google处理，但托管服务并不会自动替企业完成架构设计。生产数据库仍然需要明确版本生命周期、网络边界、身份权限、资源规格、连接池、高可用、RPO、RTO和监控指标。

因此，Cloud SQL生产部署的核心不是寻找一套所谓“最佳配置”，而是让数据库的配置与业务的访问模式、故障目标和成本边界对应起来。小型网站、SaaS应用、高并发API和数据分析系统面对的数据库问题完全不同，直接套用固定CPU阈值、固定连接数、固定备份周期或者固定跨区域方案，反而可能把一个本来简单的问题变成复杂的基础设施。