SQL资源占用过高是数据库运维中非常常见的问题，通常表现为CPU使用率持续飙升、内存占用接近上限，进而导致业务接口响应变慢甚至超时。要解决这个问题，核心是先定位瓶颈出现在CPU还是内存维度，再针对性优化。
一、先判断资源瓶颈类型
首先需要通过系统监控工具确认当前的资源瓶颈归属，不同维度的瓶颈优化方向完全不同。
1. CPU瓶颈判断
如果数据库服务器的CPU使用率长期超过80%，且top命令中mysql、sqlserver等数据库进程占用了大部分CPU资源，基本可以确定是CPU瓶颈。常见表现为大量并发查询、复杂聚合计算、全表扫描等操作。
2. 内存瓶颈判断
如果服务器可用内存持续低于10%，或者数据库缓存命中率低于90%，同时出现频繁的磁盘IO读操作，大概率是内存瓶颈。常见原因是缓存配置过小、大结果集查询未限制、临时表占用过多内存等。
二、CPU瓶颈分析思路与优化方案
1. 定位高CPU占用的SQL
首先通过数据库自带的性能视图找到消耗CPU最多的SQL语句，以MySQL为例，可查询performance_schema库中的语句统计表：
-- 查询CPU耗时排名前10的SQL
SELECT
DIGEST_TEXT, -- SQL语句摘要
COUNT_STAR, -- 执行次数
SUM_TIMER_WAIT/1000000000000 AS CPU_SEC -- 总CPU耗时（秒）
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;
2. 分析SQL执行计划
拿到高耗时的SQL后，使用EXPLAIN命令分析执行计划，重点关注以下字段：
- type：如果是
ALL表示全表扫描，需要添加索引优化 - rows：预估扫描的行数，数值越大CPU消耗越高
- Extra：如果出现
Using temporary、Using filesort，说明需要临时表或额外排序，会增加CPU开销
示例分析语句：
-- 分析目标SQL的执行计划 EXPLAIN SELECT user_id, COUNT(*) FROM order_table WHERE create_time > '2024-01-01' GROUP BY user_id;
3. 针对性优化措施
- 为where条件、group by、order by涉及的字段添加合适索引，避免全表扫描
- 拆分复杂的大查询，避免单次查询处理过多数据
- 减少不必要的聚合计算，尽量在应用层做轻量计算
- 限制单次查询返回的行数，添加合理的分页条件
三、内存瓶颈分析思路与优化方案
1. 定位内存占用过高的原因
先查看数据库的内存配置参数，以MySQL为例，核心参数如下：
| 参数名 | 含义 | 默认值参考 |
|---|---|---|
| innodb_buffer_pool_size | InnoDB存储引擎的缓存池大小，用于缓存数据和索引 | 128M |
| sort_buffer_size | 每个排序线程分配的缓冲区大小 | 256K |
| join_buffer_size | 每个关联查询分配的缓冲区大小 | 256K |
| tmp_table_size | 内存临时表的最大大小，超过会转存到磁盘 | 16M |
2. 内存优化措施
- 合理调整
innodb_buffer_pool_size，通常设置为服务器可用内存的60%-70%，如果服务器内存为16G，可设置为10G左右 - 避免一次性查询过大的结果集，比如查询全表数据不做分页，会占用大量内存缓存结果
- 优化排序和关联查询，避免触发临时表落盘，可适当调大
tmp_table_size但不超过服务器内存上限 - 定期清理无用的历史数据，减少缓存中无效数据的占比
3. 内存泄漏排查
如果内存占用持续增长不释放，需要排查是否存在长连接未关闭、大对象未释放的问题，可通过以下语句查询当前连接的内存占用：
-- 查询每个连接的内存占用情况
SELECT
ID,
USER,
HOST,
DB,
COMMAND,
TIME,
STATE,
MEMORY_USED/1024/1024 AS MEMORY_MB -- 内存占用（MB）
FROM performance_schema.threads
WHERE MEMORY_USED > 0
ORDER BY MEMORY_USED DESC;
四、长期监控建议
解决单次资源占用过高的问题后，建议建立长期的监控机制：
- 定期采集慢查询日志，每周分析一次高资源消耗的SQL
- 设置CPU、内存使用率阈值告警，超过阈值自动通知运维人员
- 每次业务上线前，对新增加的SQL做执行计划评审，避免引入高资源消耗的语句
通过以上思路，基本可以覆盖大部分SQL资源占用过高的场景，实际处理时可以先从监控数据判断瓶颈类型，再按照对应的分析步骤定位问题，最后落地优化措施即可。