现象描述
当 TDSQL Boundless 实例 CPU 利用率过高时，通常会出现以下现象：
实例监控中 CPU 利用率或 CPU 最大使用率持续处于高位，或在特定时段出现明显尖峰。
慢查询数增加，部分 SQL 执行耗时明显上升。
SQL 平均执行时间、P95 SQL 执行时间、P99 SQL 执行时间升高。
当前打开连接数、汇总活跃线程数或节点维度活跃线程数增多。
在多节点实例中，可能仅个别节点 CPU 明显高于其他节点。
严重时，业务访问可能出现响应抖动、请求堆积或超时。
若 CPU 利用率长期过高，可能影响实例性能和业务稳定性，建议及时排查。
可能原因
TDSQL Boundless 实例 CPU 利用率过高，常见原因如下：
慢 SQL 或低效 SQL
慢 SQL 是 CPU 利用率升高的常见原因之一，通常表现为查询未命中合适索引，或 SQL 存在大范围扫描、排序、聚合、回表等高开销操作。在这类场景下，通常会同时看到慢查询数、SQL 平均执行时间、P95 SQL 执行时间、P99 SQL 执行时间上升。
业务请求量突增
当业务高峰流量突增，或批量任务、抽数任务、迁移任务在短时间内集中执行时，实例 CPU 可能快速升高。此时常伴随总 QPS、读 QPS、写 QPS、每秒处理的事务数抬升。
热点访问或负载分布不均
TDSQL Boundless 为分布式数据库。如果请求长期集中在少量热点数据、热点分片或少数节点上，可能导致个别节点负载明显偏高，出现单节点 CPU 打满的情况。此时通常会看到节点维度 CPU 利用率、活跃线程数、总 QPS、数据盘 IO 时耗等指标明显高于其他节点。
元数据访问频繁
频繁执行 SHOW TABLES、SHOW TABLES LIKE 或大量查询表结构、系统对象信息等元数据操作时，也可能带来较高 CPU 开销。尤其是在单个数据库表数量较多时，影响会更加明显。
内存或 I/O 压力放大 CPU 问题
在部分场景下，CPU 升高并不是首要原因，而是由资源瓶颈间接引起。例如内存利用率偏高、读 IOPS 或写 IOPS 持续高位、数据盘 IO 最大时耗升高等，都会导致 SQL 执行变慢，进而放大 CPU 压力。
处理步骤
步骤1： 查看实例监控
建议重点关注以下几类监控指标：
|
资源类指标 | 用于判断是否存在资源瓶颈或节点负载异常，建议重点关注： CPU 利用率 CPU 最大使用率 内存利用率 内存最大使用率 数据盘最大使用率 磁盘利用率 读 IOPS 写 IOPS 总 IOPS 数据盘 IO 最大时耗 |
连接类指标 | 用于判断是否存在连接堆积或线程压力，建议重点关注： 当前打开连接数 最大连接数 汇总活跃线程数 连接数利用率 |
访问类指标 | 用于判断是否存在流量突增、慢 SQL 增多或 SQL 执行效率下降，建议重点关注： 慢查询数 总 QPS 读 QPS 写 QPS 每秒处理的事务数 SQL 失败数 SQL 平均执行时间 P95 SQL 执行时间 P99 SQL 执行时间 |
如果实例为多节点部署，建议同时查看节点维度监控，确认是否仅有个别节点异常。若仅单节点 CPU 明显偏高，通常需要重点排查热点访问或负载倾斜问题。
步骤2：通过 DBbrain 查看异常诊断
TDSQL Boundless 支持通过 DBbrain 进行异常诊断和慢 SQL 分析。
2. 在左侧导航中选择诊断优化。
3. 在页面顶部选择数据库类型为 TDSQL Boundless，并选择目标实例。
4. 单击异常诊断页签，查看近3小时内触发的诊断事件。
5. 单击具体事件，查看事件详情、现场描述、智能分析和优化建议。
如果实例存在慢 SQL，建议同时查看慢 SQL 分析页面，重点确认异常时间段内是否存在高耗时、高频或扫描行数偏大的 SQL。详细操作请参见 异常诊断。 步骤3：排查慢 SQL 和低效 SQL
若 CPU 利用率升高伴随慢查询数增多或 SQL 平均执行时间上升，建议优先排查 SQL 执行效率。
可执行以下语句查看当前会话：
对于可疑 SQL，建议查看执行计划：
重点关注以下情况：
查询是否命中合适索引
是否存在全表扫描
是否存在大量回表
是否存在高成本排序、聚合、临时表操作
异常 SQL 的执行时间是否与监控中的异常时间段一致
如果确认是索引设计不合理或 SQL 写法低效导致，建议根据实际查询条件进行索引和 SQL 优化。
步骤4：排查热点访问
若实例为多节点部署，且仅个别节点 CPU 明显偏高，建议进一步排查是否存在热点访问问题。
建议重点确认以下信息：
某类 SQL 是否长期访问同一业务 key
某个节点是否在高峰时段持续 CPU 偏高
异常节点的总 QPS、活跃线程数、读 IOPS、写 IOPS、数据盘 IO 时耗是否同步升高
异常节点的连接和线程指标是否明显高于其他节点
若确认存在热点访问，建议从以下方向处理：
优化相关 SQL，降低单次查询开销
优化业务模型，避免请求长期集中在单一热点数据
通过扩容分散负载
步骤5：排查业务流量和后台任务
若 CPU 异常与业务高峰、定时任务、批处理、迁移或巡检时间一致，建议进一步排查是否存在流量突增或任务集中执行的情况。
建议重点关注：
总 QPS
读 QPS
写 QPS
每秒处理的事务数
SQL 失败数
如果上述指标在异常时间段明显升高，则可能是业务请求量突增、任务集中执行或应用重试放大导致。建议通过错峰执行任务、控制并发度、应用侧限流等方式缓解。
步骤6：检查是否存在内存或 I/O 压力
若 CPU 升高的同时，还伴随以下现象，则说明问题可能与资源瓶颈有关：
内存利用率 持续偏高
读 IOPS、写 IOPS、总 IOPS 持续高位
数据盘 IO 最大时耗 或节点维度数据盘 IO 时耗明显升高
SQL 平均执行时间、P95 SQL 执行时间、P99 SQL 执行时间整体变长
节点维度出现是否发生 OOM
此时建议综合评估当前实例规格是否满足业务负载需求，并结合实际情况考虑升配或扩容。
步骤7：必要时进行实例扩容
如果经过排查确认 CPU 高是由当前规格不足导致，建议结合实际业务情况进行扩容。
若实例整体 CPU 长期处于高位，可考虑升配。详细请参见 调整实例配置。 若仅个别节点负载明显偏高，可优先考虑扩容以分散热点负载。
若同时存在内存和 I/O 压力，建议综合评估后统一扩容。
说明：
CPU 利用率升高不一定完全由 CPU 本身引起，建议结合慢查询数、总 QPS、SQL 平均执行时间、P95 SQL 执行时间、P99 SQL 执行时间、读 IOPS、写 IOPS、内存利用率等指标综合判断。
对于多节点实例，建议同时查看实例维度和节点维度监控，避免遗漏单节点热点问题。
在未确认原因前，不建议直接进行高风险参数调整，应优先完成 SQL、流量和资源侧排查。
如果业务中存在大量元数据访问，建议尽量降低调用频率，并避免在业务高峰期执行。
若节点维度出现是否发生 OOM，建议优先排查内存压力、异常 SQL 和缓存命中情况。
若排查后仍无法定位原因，建议进一步收集异常时间段的监控数据、慢 SQL、执行计划及业务变更信息后再做深入分析。