PHP CodeIgniter通过Cloud SQL Proxy连接Cloud SQL查询极慢问题

你观测到的11秒vs1.5秒的性能差距，核心原因不是Cloud SQL实例硬件或MySQL版本问题，90%以上的开销来自链路层累加，具体拆解如下：

• 基础网络延迟差：本地MySQL走环回地址或Unix套接字通信，单次查询往返延迟（RTT）稳定在0.1ms以内；Cloud SQL Proxy作为额外的转发层，哪怕和Cloud SQL实例部署在同可用区，每次请求都要经过本地代理进程的TLS加解密、TCP报文转发、GCP内部虚拟网络路由，单次查询RTT通常在0.8-1.2ms区间。10000次循环查询累加下来，仅延迟差就达到9秒左右，和你实测的差值完全匹配。
• 测试场景放大开销：你的测试用例是无复杂计算、无大结果集的极简SELECT * FROM test查询，SQL本身在数据库侧的执行时间占比不到10%，剩余90%的耗时全在链路传输、连接处理上，这种短平快查询会把链路层的开销放大到极致；如果换成复杂Join、大结果集查询，数据库侧执行时间占比提升，两者的性能差距会明显缩小。
• 额外配置开销：PHP7.2环境下运行的CodeIgniter版本默认关闭数据库持久连接，如果你的应用以PHP-FPM模式运行，每次请求重复建立经过Proxy的数据库连接时，还要额外承担TCP握手、TLS握手的开销；另外Cloud SQL托管实例默认开启强一致刷盘参数（sync_binlog=1、innodb_flush_log_at_trx_commit=1），相比本地开发环境默认的宽松刷盘策略，也会带来少量性能损耗，但这部分影响占比不超过10%，不是核心差距来源。

按优化收益从高到低排序：

• 优先调整Proxy连接模式：如果你的应用部署在GCP同VPC内的计算资源上，不要用公网+TCP的方式连接Proxy，改用私有IP访问Cloud SQL，同时启动Proxy时添加-dir /cloudsql参数，用Unix域套接字的方式暴露代理端口，CodeIgniter数据库配置中host字段填写/cloudsql/[你的Cloud SQL实例连接名]，替代原来的127.0.0.1 TCP连接。这一步可以把单次查询RTT降到0.2-0.3ms，整体测试耗时可以压缩到3秒以内。
• 开启持久连接：修改CodeIgniter的database.php配置文件，将$db['default']['pconnect']参数设为true，避免每次PHP请求周期重复建立数据库连接带来的握手开销。开启后需要同步调整PHP-FPM的pm.max_children参数、Cloud SQL实例的max_connections参数，避免连接数打满导致实例不可用。
• 业务逻辑减少循环单查：从代码层面避免循环执行单条SQL的写法，批量数据查询用IN语句、批量操作接口替代循环单条执行，从根源上减少数据库请求往返次数。针对你这个10000次查询的测试场景，如果把请求合并为1次批量查询，耗时可以直接降到毫秒级，这是所有优化手段中收益最高的方案。
• 调优Proxy运行参数：启动Cloud SQL Proxy时添加--max_connections=0（关闭代理侧连接数限制）、--log_level=error（关闭不必要的info级日志打印）参数，减少代理进程本身的CPU消耗。如果应用运行在GKE、Cloud Run、Compute Engine等GCP托管服务上，直接使用平台内置的Cloud SQL集成连接能力，不要单独手动部署Proxy进程，可以再降低10%-15%的代理转发开销。
• 对齐数据库参数：检查Cloud SQL实例的参数配置，将innodb_buffer_pool_size、innodb_log_file_size等性能参数和本地MySQL配置对齐，对于非金融级强一致要求的业务，可以将sync_binlog、innodb_flush_log_at_trx_commit参数调整为性能优先的取值，减少不必要的刷盘开销，这部分调整对纯SELECT查询的性能提升有限。

注：Cloud SQL Proxy的核心设计目标是提供加密传输、免IP白名单配置的便捷访问能力，并非为极致低延迟场景设计，链路存在固定转发开销是正常现象，实际业务场景下只要不是海量高频极简查询，这部分开销通常在可接受范围内。

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