业务场景:大批量更新时，数据库长时间CPU占用超过90，影响其余正常业务流程，参考阿里云上的一篇文章：https://help.aliyun.com/knowledge_detail/43562.htmlhtml
在数据库运维当中，一个DBA比较常遇到又比较紧急的问题，就是突发的CPU满（CPU利用率达到100%），致使业务停滞。遇到CPU满，每每须要从后端数据库开始排查，追溯到具体SQL，最终定位到业务层。下面是这个问题具体的处理方法。sql
CPU利用率到达100%，首先怀疑，是否是业务高峰活跃链接陡增，而数据库预留的资源不足形成的结果。咱们须要查看下，问题发生时，活跃的链接数是否比平时多不少。对于RDS for PG，数据库上的链接数变化，能够从控制台的监控信息中看到。而当前活跃的链接数>能够直接链接数据库，使用下列查询语句获得：数据库
select count( * ) from pg_stat_activity where state not like '%idle';
若是活跃链接数的变化处于正常范围，则很大几率多是当时有性能不好的SQL被大量执行致使。因为RDS有慢SQL日志，咱们能够经过这个日志，定位到当时比较耗时的SQL来进一步作分析。但一般问题发生时，整个系统都处于停滞状态，全部SQL都慢下来，当时记录的>慢SQL可能很是多，并不容易排查罪魁祸首。这里咱们介绍几种在问题发生时，即介入追查慢SQL的方法。后端
1. 第一种方法是使用pg_stat_statements插件定位慢SQL，步骤以下。markdown
1.1. 若是没有建立这个插件，须要手动建立。咱们要利用插件和数据库系统里面的计数信息（如SQL执行时间累积等），而这些信息是不断累积的，包含了历史信息。为了更方便的排查当前的CPU满问题，咱们要先重置计数器。并发
create extension pg_stat_statements; select pg_stat_reset(); select pg_stat_statements_reset();
1.2. 等待一段时间（例如1分钟），使计数器积累足够的信息。app
1.3. 查询最耗时的SQL（通常就是致使问题的直接缘由）。运维
select * from pg_stat_statements order by total_time desc limit 5;
1.4. 查询读取Buffer次数最多的SQL，这些SQL可能因为所查询的数据没有索引，而致使了过多的Buffer读，也同时大量消耗了CPU。性能
select * from pg_stat_statements order by shared_blks_hit+shared_blks_read desc limit 5;
2. 第二种方法是，直接经过pg_stat_activity视图，利用下面的查询，查看当前长时间执行，一直不结束的SQL。这些SQL对应形成CPU满，也有直接嫌疑。优化
select datname, usename, client_addr, application_name, state, backend_start, xact_start, xact_stay, query_start, query_stay, replace(query, chr(10), ' ') as query from
(select pgsa.datname as datname, pgsa.usename as usename, pgsa.client_addr client_addr, pgsa.application_name as application_name,
pgsa.state as state, pgsa.backend_start as backend_start, pgsa.xact_start as xact_start, extract(epoch from (now() - pgsa.xact_start)) as xact_stay, pgsa.query_start as query_start, extract(epoch from (now() - pgsa.query_start)) as query_stay , pgsa.query as query from pg_stat_activity as pgsa where pgsa.state != 'idle' and pgsa.state != 'idle in transaction' and pgsa.state != 'idle in transaction (aborted)') idleconnections order by query_stay desc limit 5;
3. 第3种方法，是从数据表上表扫描（Table Scan）的信息开始查起，查找缺失索引的表。数据表若是缺失索引，大部分热数据又都在内存时（例如内存8G，热数据6G），此时数据库只能使用表扫描，并须要处理已在内存中的大量的无关记录，而耗费大量CPU。特别是对于表记录数超100的表，一次表扫描占用大量CPU（基本把一个CPU占满），多个链接并发（例如上百链接），把全部CPU占满。
3.1. 经过下面的查询，查出使用表扫描最多的表：
select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;
3.2. 查询当前正在运行的访问到上述表的慢查询：
select * from pg_stat_activity where query ilike '%<table name>%' and query_start - now() > interval '10 seconds';
3.3. 也能够经过pg_stat_statements插件定位涉及到这些表的查询：
select * from pg_stat_statements where query ilike '%<table>%'order by shared_blks_hit+shared_blks_read desc limit 3;
对于上面的方法查出来的慢SQL，首先须要作的多是Cancel或Kill掉他们，使业务先恢复：
select pg_cancel_backend(pid) from pg_stat_activity where query like '%<query text>%' and pid != pg_backend_pid(); select pg_terminate_backend(pid) from pg_stat_activity where query like '%<query text>%' and pid != pg_backend_pid();
若是这些SQL确实是业务上必需的，则须要对他们作优化。这方面有“三板斧”：
1. 对查询涉及的表，执行ANALYZE <table>或VACUUM ANZLYZE <table>，更新表的统计信息，使查询计划更准确。注意，为避免对业务影响，最好在业务低峰执行。
2. 执行explain <query text>或explain (buffers true, analyze true, verbose true) <query text>命令，查看SQL的执行计划（注意，前者不会实际执行SQL，后者会实际执行并且能获得详细的执行信息），对其中的Table Scan涉及的表，创建索引。
3. 从新编写SQL，去除掉没必要要的子查询、改写UNION ALL、使用JOIN CLAUSE固定链接顺序等到，都是进一步深度优化SQL的手段，这里再也不深刻说明。