Cloud SQL 性能下降怎么排查，慢查询和数据库资源应该如何观察

Cloud SQL for MySQL 出现性能下降时，不能只盯着 CPU 使用率，也不能看到一条慢 SQL 就马上增加索引。真正有效的排查应该把查询延迟、数据库内部负载、CPU、内存、存储、连接数、锁等待以及应用访问路径放在同一条诊断链上。对于生产环境，首先要确定性能下降发生的时间窗口，再把数据库指标与应用请求、部署变更和流量变化对应起来。

最先需要确认的是，到底是“所有查询变慢”，还是“少数 SQL 突然变慢”。Cloud SQL for MySQL 提供 Query Insights，可以从查询层面观察延迟、执行次数以及查询负载，并进一步定位产生问题的应用来源。对于需要查看具体慢 SQL 的场景，可以开启 Cloud SQL 的 slow query log，并设置 log_output=FILE，然后通过 Google Cloud Logs Explorer 查看日志。Google 官方文档也明确建议通过 slow query log 记录超过指定执行时间的 SQL，而不是长期依赖 general log。

如果使用慢查询日志，真正有价值的不只是“执行超过几秒”这一数字，还包括执行时间、锁等待时间、检查的行数以及返回的行数。一个查询执行两秒并不一定意味着 SQL 本身有严重问题；如果它只扫描几十行，而且每天执行几次，实际影响可能很小。相反，一条执行几十毫秒、每天运行几十万次，并且每次检查大量无关记录的 SQL，反而可能成为数据库负载的主要来源。Google Cloud 的 MySQL 性能优化资料也建议关注 rows_examined 与 rows_sent 等指标，用它们判断查询是否扫描了大量无用数据。

下一步是分析执行计划。MySQL 的 EXPLAIN 结果中，可以重点检查 type、possible_keys、key、rows、filtered 以及 Extra 等字段。key 可以帮助确认优化器实际选择了哪个索引，rows 可以估算需要检查的数据行数量，而 Extra 中出现 Using temporary 或 Using filesort 时，则需要结合 SQL 的排序、分组、连接方式以及数据量判断是否存在优化空间。

这里尤其要避免一个常见误区：看到全表扫描就认为一定需要增加索引。小表进行全表扫描可能比使用索引更快，因为索引本身也有维护和随机访问成本。真正应该观察的是查询访问的数据规模、执行频率、过滤条件、排序和连接条件，以及随着数据量增长之后执行计划是否发生变化。

对于高并发系统，还必须观察锁等待和活动事务。MySQL 可以通过 SHOW PROCESSLIST 查看正在执行的线程和 SQL，也可以结合 SHOW ENGINE INNODB STATUS 分析 InnoDB 锁竞争、事务以及 buffer pool 状态。Cloud SQL 官方故障排查文档也将锁等待、活动查询、InnoDB 状态以及 semaphore contention 列为重要诊断信息。

如果突然出现大量查询等待，不要立即把问题归结为 CPU 不够。一个长时间未提交的事务可能持有锁，导致后续大量 UPDATE、DELETE 或其他事务排队。此时增加 vCPU 并不能从根本上解决问题，应该先找出持锁事务、确认事务持续时间和业务代码，再判断是否存在事务范围过大、缺少索引导致锁范围扩大或者应用忘记提交事务等问题。

CPU 是第二层需要观察的指标。如果 CPU 长时间接近实例能力上限，同时 Query Insights 显示大量查询消耗 CPU，那么增加实例计算能力可能有效。但如果 CPU 并不高，而查询延迟明显增加，就应该继续检查内存、I/O、锁等待和网络，而不是机械地升级实例规格。

内存问题在 Cloud SQL for MySQL 中尤其值得注意。InnoDB buffer pool 是 MySQL 内存的重要组成部分，同时每个连接和每条并发 SQL 还可能使用 session-level buffer，例如 sort_buffer_size、join_buffer_size、read_buffer_size、tmp_table_size 和 max_heap_table_size。这些参数如果设置得过大，在高并发情况下可能产生明显的内存压力。Google Cloud 也特别提醒，过大的每线程内存配置可能造成 OOM。

因此，遇到内存使用率异常时，不应该只增加实例 RAM。需要同时检查连接数、并发查询数量、临时表、buffer pool、每连接内存以及实际 SQL 行为。对于符合条件的 Cloud SQL for MySQL 实例，目前还可以使用 managed buffer pool，在发生较高内存压力时自动降低 buffer pool 大小，以降低 OOM 风险。

存储性能则需要结合 Cloud SQL 当前实例所使用的存储类型和机器系列判断。不能简单地把 Cloud SQL 存储概括为“SSD 或 NVMe”。当前 Cloud SQL 支持不同存储方案，其中部分 Enterprise Plus 实例可以使用 Google Cloud Hyperdisk Balanced，并配置 provisioned IOPS 和吞吐量。实际性能还受到存储容量、vCPU 数量和 I/O block size 等因素影响。

存储空间本身也值得检查。Cloud SQL MySQL 的磁盘使用量不一定全部来自用户表。二进制日志、临时文件以及其他系统文件都可能占用大量空间。Google Cloud 提供 database/disk/bytes_used_by_data_type 等指标，可以进一步观察不同类型的数据占用了多少存储。

如果性能下降发生在数据库重启之后，也不要立即判断实例规格不足。Cloud SQL for MySQL 使用 InnoDB buffer pool 缓存数据和索引，实例重启后缓存需要重新建立，在缓存重新预热之前，读取性能可能暂时下降。Google Cloud 官方故障排查文档明确提到了这种情况。

网络问题则应该从应用所在位置和 Cloud SQL 所在区域开始检查。Cloud SQL 支持 Private IP，通过 VPC 网络连接数据库；也可以使用 Private Service Connect 等私有网络方案。Google Cloud 官方文档建议，在没有特殊需求必须提供互联网访问时，优先考虑 Private IP。

需要特别注意的是，Private IP 并不会自动消除所有网络延迟。应用与数据库如果位于不同区域，仍然会产生跨区域网络延迟。因此，判断数据库“慢”之前，应该先区分 SQL 执行时间和客户端到数据库之间的网络等待时间。如果数据库内部执行只需要几十毫秒，而应用端请求却需要几百毫秒甚至更久，继续优化 SQL 未必能够解决主要问题。

Cloud SQL 的高可用和读副本也必须区别对待。当前 Cloud SQL for MySQL 的区域高可用配置使用 Regional Persistent Disk，在同一区域的不同 zone 之间进行同步复制，以便在发生区域内基础设施故障时进行自动故障转移。普通 read replica 则采用异步复制，主要用于读扩展以及部分灾难恢复场景，并不等同于 HA。

因此，不应该简单提出“写密集型使用同步复制、读密集型使用异步复制”。这实际上混淆了高可用、读扩展和灾难恢复三个不同问题。生产系统需要根据 RPO、RTO、读取压力、写入压力以及故障场景选择 HA、read replica 或跨区域灾备方案。

数据库网络安全方面也不能直接套用其他云平台的“安全组”概念。Google Cloud 环境主要涉及 VPC、VPC firewall rules、Private IP、Private Service Access、Private Service Connect、Authorized Networks，以及 Cloud SQL Auth Proxy 或 Cloud SQL Language Connectors 等连接方式。具体采用哪一种，要看应用部署位置以及是否需要通过公网连接。

查询优化最终仍然应该回到 SQL 和数据模型本身。对于高频过滤和连接条件，可以考虑合适的单列或复合索引；对于数据量极大的表，可以根据访问模式评估分区；对于明显的热点读取，可以考虑应用缓存。但这些措施都应该建立在实际执行计划和负载数据之上，而不是看到慢查询就批量增加索引。

索引也不是越多越好。每增加一个索引，INSERT、UPDATE 和 DELETE 都可能承担额外维护成本，同时会占用存储和 buffer pool 空间。一个读密集型查询可能因为增加复合索引得到巨大改善，但同一个索引未必适合写密集型业务。因此，索引设计应该结合查询频率、选择性、数据分布和写入成本进行评估。

连接池同样需要谨慎调整。连接池的作用是减少频繁建立数据库连接的开销，但并不是把连接数量调得越大越好。过多并发连接会增加线程、session buffer 和其他内存消耗，并可能进一步放大 CPU、锁竞争和上下文切换压力。Cloud SQL 官方资料也建议对线程缓存以及每线程内存参数保持保守配置。

实际排查时，可以建立一条固定流程：先确定性能下降发生的时间和范围，再通过 Query Insights 或慢查询日志找到高负载 SQL；随后用 EXPLAIN 检查执行计划；如果 SQL 没有明显问题，再检查锁等待、连接数、CPU、内存和存储；最后才判断是否需要升级实例、增加索引、调整连接池或者改变架构。

对于生产环境，不建议一次修改大量参数。应该先记录当前性能基线，包括平均延迟、P95/P99 延迟、QPS、CPU、内存、I/O、活动连接数、锁等待以及最主要 SQL 的执行统计，然后一次改变一个主要变量，再观察结果。这样才能知道性能变化究竟来自 SQL 优化、实例规格、存储配置还是应用层行为。

Cloud SQL 性能优化的核心不是寻找一个万能的 CPU 或内存阈值，而是建立从“请求延迟”一直追踪到“具体 SQL、执行计划、锁、资源和网络”的证据链。数据库真正出现瓶颈时，监控数据应该能够回答三个问题：到底什么变慢了，为什么变慢，以及修改之后是否真的恢复。只有把这三个问题连接起来，Cloud SQL 的性能优化才不会变成不断升级实例规格的昂贵试错。