华为云代付 腾讯云 CDB 实例 CPU 瞬间飙升 100%？定位慢 SQL 的正确姿势
这类问题我见得最多：监控一报警，CPU 直接打满，业务开始超时，页面卡顿，DBA 第一反应是“是不是慢 SQL”。但实际排查下来，真正把 CPU 顶上去的，往往不止一种原因。
如果你现在正准备处理这个问题，最关心的通常不是原理，而是三个现实问题：怎么最快找到罪魁祸首、要不要先扩容、账号和权限够不够用。下面我按实际处理顺序来讲，尽量不绕弯。
先别急着扩容，CPU 100% 不一定就是慢 SQL
我处理过不少案例，CPU 飙高时，现场常见的误判有三种：
- 高并发短 SQL：单条 SQL 看起来不慢，但每秒执行几百次，累积把 CPU 打满。
- 锁等待堆积：真正占 CPU 的不是某条慢 SQL，而是大量会话在重试、等待、重算。
- 大事务或批量任务：凌晨跑报表、补数、批量更新，CPU 会在短时间内冲到 100%。
所以第一步不要直接“猜 SQL”，而是先看这几个指标是否同步异常：
- 连接数是否突然上升
- QPS/TPS 是否同一时间放大
- 慢日志是否在同一分钟集中出现
- 是否刚做过 DDL、备份、导入导出、参数调整
如果 CPU 高，但慢日志很少，通常说明问题不在“单条慢 SQL”，而是在“高频短 SQL”或者“锁/事务”层面。
定位顺序要对：监控 → 慢日志 → 执行计划 → 现场验证
很多人一上来就只看慢日志，结果翻半天也找不到明显异常。正确顺序应该是这样：
- 先看实例监控：确认 CPU 飙高的时间点，最好精确到 5 分钟以内。
- 再看慢 SQL Top 列表：重点不是“耗时最长”，而是“执行次数多、总耗时高、扫描行数大”的 SQL。
- 看执行计划：重点盯全表扫描、索引失效、回表过多、排序/临时表。
- 回到业务现场：这个 SQL 是谁发起的，什么时候发起，是否被定时任务或批处理放大。
在腾讯云 CDB 控制台里，通常先从性能监控和 SQL 分析入口入手。实操里我建议你优先抓这几类 SQL：
- 单次不慢，但执行次数异常高的 SQL
- rows examined 很大，但返回行数很少的 SQL
- 带 ORDER BY / GROUP BY / DISTINCT，同时没有合适索引的 SQL
- 更新、删除大批数据但没有分批的 SQL
如果你发现某条 SQL 每次只跑几十毫秒，但一天执行几十万次，那它比一条 3 秒慢 SQL 更容易把 CPU 顶满。
真正有用的判断标准，不是“慢”，而是“浪费了多少 CPU”
华为云代付 定位慢 SQL 时，建议你重点看这三个数字：
| 指标 | 怎么看 | 实际意义 |
|---|---|---|
| 执行次数 | 是否短时间暴增 | 高频短 SQL 常见于接口抖动、重试风暴、缓存失效 |
| 扫描行数 | 是否远大于返回行数 | 说明索引没打中，CPU 多花在读和过滤 |
| 排序/临时表 | 是否频繁出现 filesort、temporary | 这类 SQL 很容易在高并发下把 CPU 拉满 |
实战里，很多“慢 SQL”不是单纯慢，而是扫描了不该扫的数据、做了不该做的排序、重复执行了不该重复执行的查询。这才是 CPU 飙升的根源。
账号、实名认证、充值和支付，往往是排障时最容易被忽略的拦路点
有些用户明明已经知道问题在哪，但卡在腾讯云账号流程上：没实名、没充值、支付失败、权限不足，最后只能看着告警干着急。
如果你是新账号，建议先把下面几件事做完，再去处理 CDB 故障：
- 完成实名认证或企业认证：不实名，很多资源开通、变配、续费会受限。
- 绑定可用支付方式：避免临时扩容时因为付款失败耽误故障处理。
- 预留账户余额：按量或包年包月都要看站点规则，余额不足时容易影响续费、升配和自动续费。
- 确认账号权限：有些团队是子账号操作，只有查看权限，没有改参数、导出日志、升级实例的权限。
华为云代付 这里有个很现实的风险点：新账号一次性大额充值、频繁换卡、跨地区支付、主体信息不一致，都可能触发风控审核。尤其是企业账号，付款主体、认证主体、发票信息最好保持一致，否则审核时间会被拉长。
支付方式和风控差异，决定你能不能“马上动手”
不同站点、不同地区，腾讯云的支付方式会有差异。实操上你要关注的不是“支持多少种支付方式”，而是哪种方式最不容易卡审核。
- 信用卡：适合紧急开通和按量场景，但新卡、小额多次失败，容易触发安全校验。
- PayPal / 电汇 / 对公支付：适合企业采购，但到账慢，别等故障出现了才走流程。
- 本地支付渠道：更适合日常小额充值，但要看账号所在站点是否支持。
我给客户的建议很直接：如果 CDB 已经处在告警边缘，不要把“待支付”“待审核”“待充值”留到最后一刻。数据库问题最怕的不是贵，而是你想扩容时没法立刻操作。
成本怎么选：临时升配，还是先优化 SQL？
这个问题没有固定答案，但可以按场景快速判断：
| 场景 | 更合适的做法 | 原因 |
|---|---|---|
| 活动峰值只持续几小时 | 先临时升配，后续再优化 | 先止血，避免业务超时和订单损失 |
| 某条 SQL 长期高频 | 先改 SQL / 补索引 | 单靠升配只能延缓，费用会持续增加 |
| 凌晨批量任务导致 CPU 打满 | 拆批、限速、错峰执行 | 比单纯加机器更有效 |
| 锁等待明显 | 先处理事务和加锁顺序 | 升配对锁等待帮助有限 |
从成本角度看，短期扩容是应急手段，长期优化 SQL 才是控制账单的关键。我见过不少团队一开始靠升配顶住了，但一个月后 CPU 又满，账单还涨了 40% 以上。真正省钱的做法，是先把高频 SQL 和大事务清掉，再看是否还需要更高规格。
几个高频问题，基本决定你能不能快速恢复
Q1：CPU 100%，但慢日志里没几条 SQL，怎么办？
先看连接数、锁等待、重试风暴和高频短 SQL。很多时候不是“慢”，而是“多”。
Q2：为什么我已经发现问题 SQL，却改不了？
通常是权限问题。子账号没有参数修改、变配、导出慢日志权限，或者账号还没完成实名认证/企业认证。
Q3：新账号为什么一买资源就被审核？
高金额订单、频繁支付失败、付款主体和认证主体不一致，都会触发风控。企业账号尤其要注意资料一致。
Q4：充值后多久能生效？
一般到账后可用，但如果是对公转账、人工审核、跨地区支付，时间会更长。别把续费卡在最后一天。
Q5：慢 SQL 处理完就一定不会再高 CPU 吗？
不一定。还要防缓存失效、批量任务、报表周期、备份窗口和业务重试。很多 CPU 问题是“组合拳”。
给现场排障的实用建议
如果你现在就在处理这台 CDB，我建议按这个顺序做：
- 记录 CPU 飙升的准确时间段。
- 拉出同时间段的连接数、QPS、锁等待、慢日志。
- 筛选 Top SQL，看执行次数和扫描行数，而不是只看单次耗时。
- 对可疑 SQL 跑执行计划，确认是否索引失效或回表过多。
- 能临时止血就先限流、加索引、拆批或升配。
- 确认账号实名、余额、权限没问题，避免修到一半被支付或风控卡住。
这套流程的核心不是“找到一条最慢的 SQL”，而是找到真正消耗 CPU 的那批请求。只要定位顺序对了，CPU 100% 这类问题通常能很快缩小范围。真正耽误时间的，往往不是技术本身，而是账号权限、支付没准备好、和排查方向走偏。
