解读

在国内真实生产环境中，5% 的 CPU 上涨往往会被监控告警直接推送到企业微信或飞书群，面试官真正想验证的是：

1. 你是否理解 Query Insights 的采集机制 与 MySQL/PostgreSQL 性能_schema 开销 的本质；
2. 能否用 Cloud SQL 原生指标 + 慢日志 + 执行计划 三板斧快速收敛范围，而不是一上来就关功能；
3. 是否具备 “可接受基线” 思维——5% 在部分业务场景下是合理代价，关键看是否伴随 QPS 下跌、连接堆积或 95th 延迟飙升。

知识点

1. Query Insights 实现层：基于 performance_schema（MySQL）或 pg_stat_statements（PostgreSQL）连续采样，默认 1 秒刷一次内存表，采样线程本身消耗 CPU 且持有 mutex。
2. 关键指标：
   • database/cpu/utilization（Cloud Monitoring）
   • performance_schema/threads 状态变量
   • slow_query_log | log_min_duration_statement 实际执行时间
   • innodb_rows_read / pg_stat_user_tables.seq_scan 是否出现全表扫描放大
3. 国内网络合规：若已开 Private IP + VPC Service Controls，排查时仍需通过 Cloud SQL Auth Proxy 跳板机 登录，避免公链延迟干扰判断。
4. 版本差异：MySQL 8.0 在 performance_schema_consumer_global_instrumentation 默认 ON，比 5.7 额外多 2%～3% 固定开销；PostgreSQL 13 之后 pg_stat_statements.track_utility 默认 off，可再降 1%。
5. SRE 黄金信号：同时看 流量、错误、延迟、饱和度；CPU 单指标上涨 5% 但 P99 延迟不变，可降级为 P3 工单，而非紧急变更。

答案

步骤一：确认上涨是否持续
在 Cloud Monitoring 创建 “database/cpu/utilization” 的 7 天同比视图，排除业务自身晚高峰尖刺；若上涨与 Query Insights 开启时间窗 100% 重合，继续。

步骤二：拆分开销来源

1. 查看 performance_schema 内部线程 CPU（MySQL：
   SELECT SUM(SUM_TIMER_WAIT)/1000000000 AS cpu_sec FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE '%/thread%';）
   若结果 > 0.5 core·hour/天，即证明 采样线程本身 是主因。
2. PostgreSQL 用 pg_top 或 pg_stat_activity 观察 backend 类型 = ‘client backend’ 且 wait_event = ‘CPU’ 的采样比例。

步骤三：检查是否触发“放大”
若发现 全表扫描次数 伴随上涨，说明 Insights 把 隐式坏查询 刷了出来，导致 Buffer Pool 抖动；此时应：

• 用 Query Insights 控制台 按 Execution Count & Mean Latency 双维度排序，抓 top 10；
• 对每一条 Rows_examined / Rows_returned > 100 的 SQL 立即 EXPLAIN，确认是否缺失 复合索引 或 字符集隐式转换。

步骤四：评估容忍度并调优

• 业务低峰期 CPU 基线 30%，上涨 5% 后仍低于 50%，且 QPS、连接数、95th 延迟 无劣化 → 可接受，同步产出 “功能收益 > 代价” 报告即可。
• 若已逼近 70%，则：
  1. 调低采样频率：gcloud sql instances patch <inst> --database-flags=performance-schema-instrument='wait/%=OFF',performance-schema-consumer-events-waits-current=OFF（MySQL）
  2. 或 关闭 utility 命令跟踪：pg_stat_statements.track_utility=off（PostgreSQL）
  3. 再次观察 30 分钟，CPU 回落即闭环；否则继续深挖 Top SQL 索引优化。

步骤五：沉淀自动化
把以上指标固化到 Cloud Monitoring Dashboard + Alerting Policy：

• 当 database/cpu/utilization 连续 10 min > 60% 且 query_insights_enabled=true 时，自动创建 P2 工单 并 @值班；
• 每周跑 Terraform 把 performance_schema 开关 与 flag 基线 作为 IaC 快照，防止人为误开。

拓展思考

1. “5% 上涨” 只是冰山一角：如果业务后续做 分库分表 或 读写分离，Query Insights 会在每个节点都产生同样开销，总成本线性放大；提前在架构评审阶段就评估 采样关闭窗口 + 旁路审计方案（如 Binlog 到 BigQuery 离线分析）。
2. 与 Cloud SQL Enterprise Plus 的 “Query Plan Management” 联动：开启 Insights 后发现 计划回退，可直接把 Accepted Plan 锁进 sql_plan_baselines，避免反复解析导致 CPU 二次上涨。
3. 国内等保 2.0 场景：审计日志必须留存 6 个月，Insights 不能关；此时可把 采样频率降到 1/10 并通过 Cloud Storage 生命周期规则 自动转冷线，用存储换 CPU，实现合规与性能双赢。