数据库服务器CPU占用率太高原因分析及后续改进措施

1、.数据库服务器 CPU 占用率太高原因分析及后续改进措施一原因分析本次正式数据库服务器CPU 占用率太高导致应用无法连接数据库无法链接主要有以下两个方面的原因：1.作为维护人员责任心不够，未能及时发现数据库存在的问题导致问题积累以致系统无法响应。2.在开发过程中还是存在部分SQL 语句不规范以及索引未创建或者创建不合理的问题。二改进措施1. 数据库日常监控在日常维护工作中增加对数据库服务器CPU 及内存占用情况的监控，定期抽取占用CPU 及内存较大的 SQL 语句基于以下两个原则进行优化：1.1 、因未创建索引或者因索引创建不合理导致为起到应有作用原因导致的占用CPU 或内存较高或运行时间较长

2、的SQL ，在找到原因后直接进行处理以达到解决问题的目的。1.2 、如因 SQL 本身不够优化导致占用CPU 或内存较高或运行时间较长的，提取出后将SQL 发给相关开发人员，由开发人员在应用中进行修改。2. 增加性能及压力测试与甘工沟通后，就公司后期项目特别是 B/S 类项目，在项目正式上线 前增加性能及压力测试，同时在数据库方面尽量模拟系统实际上线后的环境，以便通过性能及压力测试及时发现数据库方面的瓶颈，及时发现不够合理的 SQL 并进行优化。3. 在日常开发中 SQL 优化方面注意的问题SQL Select语句完整的执行顺序：1 、 from子句组装来自不同数据源的数据；2 、 where

3、子句基于指定的条件对记录行进行筛选；3 、 group by子句将数据划分为多个分组；.4 、使用聚集函数进行计算；5 、使用 having 子句筛选分组；6 、计算所有的表达式；7 、使用 order by 对结果集进行排序。SQL 优化方面注意问题1、ORACLE 采用自下而上的顺序解析WHERE 子句根据这个原理 ,表之间的连接必须写在其他WHERE条件之前 , 那些可以过滤掉最大数量记录的条件必须写在WHERE 子句的末尾 .2、 FROM 子句中的表明采用从右往左的的顺序处理，因此在FROM 子句中写在最后的表（基础表）最先被处理。因此在如FROM 子句中有多个表，需选择记录数最少的

4、表作为基础表。3、 SELECT 子句中避免使用 *4、使用表的别名 (Alias) ，且在 SQL 中有多个表时，需将别名前缀到每个列前。5、尽量避免使用 in ，建议使用 EXISTS( 或 NOT EXISTS) ，关于此点需具体情况具体分析。6、避免使用 having函数7、建立索引时，索引列可选择性一定要高（可选择性即索引列里存储不同值的数目和记录数的比），如公司防伪码所建立的索引的可选择性为1 非常好。8、及时关闭对数据库的链接。9、计算记录条数： count(*) 比 count(1)稍快，最快的是对索引列的计数， 也就是说如果需要计数时，如果有索引列需使用索引列进行计数。10

5、、针对索引列需要注意的：避免使用NOT, 避免使用计算，避免使用NULL,NOT NULL,11 、SQL 语句使用大写。12 、尽量使用 >= 代替 >或者<= 代替 <.三待处理问题.1.占用 CPU 较高进程在近几天的日常监控中经常发现有个别进程占用单个CPU 超过 40% ，且占用率长时间没有降低，如下图所示通过该进程号对应的内存地址在数据库中查询，查询结果为SMS9588.exe应用程序。将该程序进程Kill 或重新启动该程序后CPU 占用率降低， 证明确实为该程序占用较高的内存，因此需分析一下导致该程序占用CPU 较高的原因并解决。2. 问题 SQL关于问题

6、SQL ，详细请参考优化SQL 列表 .xlsx 文件。、3. 其他个别应用在监控过程中发现其他占用资源较高的应用有模糊查询类工具，以美赞臣为例如需对一个数码进行模糊查询需对接近 20 张表进行 like 及 Union 操作，此类操作会耗费系统大量的资源，如果在数据库系统本身资源就紧张的情况下再进行此类操作，极有可能会对数据库造成较大的影响，因此对于此类工具建议尽量少用或不用。四SQL 语句性能监控方法1. 通过在 V$SQL 表中查询近期运行语句，如 BUFFER_GETS 或 DISK_GETS 太高一般情况下 SQL 需要进行优化。2. 通过SELECT b.sql_textFROM V$SESSION a LEFT OUTER JOIN v$sqlarea b ON a.sql_address=b.addressWHERE EXISTS(SELECT 1 F