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

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

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

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

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

5、用=代替 或者 =代替.三 待处理问题1. 占用CPU较高进程在近几天的日常监控中经常发现有个别进程占用单个CPU超过40%，且占用率长时间没有降低，如下图所示通过该进程号对应的内存地址在数据库中查询，查询结果为SMS9588.exe应用程序。将该程序进程Kill或重新启动该程序后CPU占用率降低，证明确实为该程序占用较高的内存，因此需分析一下导致该程序占用CPU较高的原因并解决。2. 问题SQL关于问题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 FRO