Cloud SQL CPU使用率达100%引发服务超时问题咨询

• 优先开启Postgres慢查询日志：调整参数log_min_duration_statement = 100（单位为毫秒，可根据实际业务阈值调整），采集任务高峰时段的所有查询语句，重点统计高频查询的执行次数、扫描行数。CPU占满但内存、连接数、读写IO都正常的情况，绝大多数是未命中索引的慢查询、大量重复计算类SQL导致的。
• 对高频查询执行EXPLAIN ANALYZE分析执行计划：检查是否存在全表扫描、未走索引的排序/分组/去重操作、大表关联顺序错误等问题，数十亿级大表只要有一个高频查询走全表扫描，并发下很容易直接打满CPU。
• 核查旧API的业务逻辑：确认是否存在把批量查询拆成循环单条查询、同一份数据重复查询多次的逻辑，这类逻辑会放大数据库的CPU消耗。

• 新增热点缓存：在API层和数据库之间接入Redis缓存，提前将客户每日需要拉取的近万条数据预热到缓存中，缓存过期时间设置为24小时即可，客户请求直接走缓存返回，完全不占用数据库资源。
• 对旧API做并发限流：将6个API实例的请求做削峰处理，通过队列将数据库并发查询数控制在1~2，适当拉长单客户的查询总耗时，避免CPU瞬间被打满导致全服务不可用。
• 新增临时只读实例：将旧API的所有查询流量切到只读实例，不影响主库的其他业务，只读实例可以在客户完成新接口切换后直接释放，成本比直接升级主库CPU低很多。
• 紧急补充覆盖索引：如果定位到CPU消耗集中在某几个固定查询，可以直接针对查询字段创建覆盖索引，无需修改业务代码，索引生效后CPU使用率会直接大幅下降。

• 提前压测新接口性能：在客户切换前做全链路压测，确认新接口的查询逻辑是否有优化、是否能命中索引、数据库CPU消耗是否符合预期，避免切换后还是存在负载过高的问题。
• 大表拆分：针对数十亿级的大表提前按时间、业务维度做分库分表，降低单表数据量，提升整体查询性能。
• 离线数据导出替代在线查询：如果客户每日拉取的是T-1的历史数据，可以每日定时将数据导出到对象存储，给客户开放下载权限，从根源上消除这部分查询的数据库负载。

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