如何证明Cloud MySQL连接数过多导致Cloud Functions响应缓慢？

1. 对比已用连接与最大连接数 #

直接登录你的Cloud MySQL实例，执行以下SQL：

-- 查看当前活跃连接数
SHOW STATUS LIKE 'Threads_connected';
-- 查看实例允许的最大连接数
SHOW VARIABLES LIKE 'max_connections';

如果Threads_connected的数值持续接近max_connections的上限，基本可以确定连接资源被耗尽，导致新请求排队等待。

2. 查看连接队列与错误统计 #

执行这些SQL查看队列和连接错误情况：

-- 正在执行查询的连接数
SHOW STATUS LIKE 'Threads_running';
-- 等待资源的连接数（队列长度相关）
SHOW STATUS LIKE 'Threads_waiting';
-- 因达到最大连接数被拒绝的请求次数
SHOW STATUS LIKE 'Connection_errors_max_connections';

• 若Threads_waiting长期偏高，说明有大量连接在排队等待资源；
• 若Connection_errors_max_connections持续增长，直接证明有连接请求因为达到上限被拒绝，这就是响应变慢的核心原因。

3. 结合Cloud Functions的并发特性排查 #

Cloud Functions是无状态触发，高并发场景下会快速创建新连接，很容易耗尽连接池：

• 去GCP控制台的Cloud Functions详情页，查看「并发执行数」监控指标，如果并发数走势和MySQL连接数增长完全匹配，就能对应上问题；
• 临时调低函数的最大并发数，观察响应时间是否改善。如果响应明显变快，说明之前的高并发是连接耗尽的诱因。

4. 查看MySQL连接日志辅助诊断 #

临时开启通用日志（注意不要长期开启，避免占用过多存储），查看连接的建立、断开记录：

-- 临时开启通用日志
SET GLOBAL general_log = 'ON';
-- 查看日志文件路径
SHOW VARIABLES LIKE 'general_log_file';

从日志里能看到大量来自Cloud Functions的短连接请求，以及是否存在连接被拒绝的记录，进一步坐实问题。

关于max_connections的差异说明 #

Cloud SQL的max_connections值是随实例规格动态调整的：小型实例默认150-200，大型实例可以扩容到几千。你当前看到的4000是你实例的实际配置值，以SHOW VARIABLES LIKE 'max_connections';的查询结果为准，不用纠结资料里的默认值。

内容的提问来源于stack exchange，提问作者user13203487