系统优化

优化流程：
检查、测试、分析－－找出性能瓶颈－－寻找优化方案－－评估优化方案－－制定优化计划

系统优化过程：
检查环境配置－－检查数据库设计－－检查数据库索引－－视图－－检查SQL(静态、动态)－－检查应用程序代码(页面、代码)－－第三方工具新技术－－更改程序数据库设计
系统优化中普遍遵循 2：8 原则：
80%的工作只能产生20%的效果；
80%的时间只能产生20%的效果；
80%的性能问题由20%的代码引起；
20%的sql占用了80%的资源；
木桶原理：
木桶能装多少水，是由最短的木板决定的
瓶颈是由最短的木板引起的；
优化的关键是加长最短的木板；
永远有最短的木板，优化要适可而止
优化中常见的误区：
1、没有找到瓶颈；
2、只进行软优化、不进行硬优化；
3、没有经过sql优化就进行更改程序数据库设计；
4、未考虑使用第三方工具、新技术进行优化；
DB2数据库的优化：
监视开关：
db2 update monitor switches using lock ON sort ON bufferpool ON uow ON table ON statement ON
==收集数据库信息
db2 get db cfg for db_irs
-Lock timeout (sec) (LOCKTIMEOUT) = -1 超时时间

更改设置（连接超时）
db2 update db cfg for db_irs using LOCKTIMEOUT 15
==数据库信息
db2 get snapshot for database on db_irs
-Lock list memory in use (Bytes)= 576 锁列表内存
-Database files closed = 0 关闭文件数 MAXFILOP

-Total sorts = 1 排序开销：Sort overflows/Total sorts <0.003
-Sort overflows = 0


==表信息
db2 get snapshot for tables on db_irs
-Rows Read= 98857 正在读取行
-Overflows= 0 溢出


db2 list tablespaces show detail
-Extent size (pages) = 32 表空间设置
-Prefetch size (pages) = 96
-Number of containers = 3

SQL 静态优化：

大小写（数据库中都会转换为大写）


WHERE子句的执行顺序： 从后到前；
－逐表，关系

FROM子句的执行顺序： 从后到前；
－关系表在后；

JOIN连接执行的顺序： 从后到前；
索引：唯一索引、聚集索引、索引、复合索引
－索引是为查询优化而设计，以降低数据增、删、改效率为代价；
－索引可以提高查询的效率，但会降低操作的效率；
－何时使用：经常在where、order或group by子句中出现的列；
－何时不使用：重复多、包含NULL值的列；
在WHERE中尽量不要使用 OR ，!= , in , like

尽量不要使用SELECT * 语句,使用明确列名；

尽量不要在WHERE中包含子查询

尽量少用子查询，用JOIN代替

子查询中，尽量用EXISTS替代IN、用NOT EXISTS替代NOT IN

避免不同类型值的比较

使用存储过程和视图

用EXISTS替代IN、用NOT EXISTS替代NOT IN；

避免在索引列上使用计算：WHERE SAL*12>25000；

用IN来替代OR： WHERE LOC_ID=10 OR LOC_ID=15 OR LOC_ID=20

避免在索引列上使用IS NULL和IS NOT NULL；

总是使用索引的第一个列；

用UNION-ALL替代UNION；
SQL优化的顺序：
－检查SQL或存储过程的语法，考虑其写法是否还有可优化内容

－检查、优化 索引的使用

－检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
查看锁信息：
db2 get snapshot for locks on db_irs
db2 list applications for db db_irs show detail
db2 list applications
db2 select * from table(snapshot_lock('db_irs',-1)) as locktable


死锁的优化：

1. 等待锁：
－查找修改产生死锁的逻辑，保证业务逻辑顺序的一致；

2. 队列锁： 消减队列
－调整配置(LOCKTIMEOUT)
－增强硬件处理速度
－优化系统占用资源时间()
－减少用户数

3. 混合锁：
锁: （Lock） 是在多用户环境下为保证数据一致性对资源访问的一种限制


从数据库系统的角度来看 锁分为以下三种类型：

独占锁（Exclusive Lock）
独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放。
共享锁（Shared Lock）
共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。
更新锁（Update Lock）
更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定。

从程序员的角度看 锁分为以下两种类型：

乐观锁（Optimistic Lock）
乐观锁假定在处理数据时，不需要在应用程序的代码中做任何事情就可以直接在记录上加锁、即完全依靠数据库来管理锁的工作。一般情况下，当执行事务处理时SQL Server会自动对事务处理范围内更新到的表做锁定。
悲观锁（Pessimistic Lock）
悲观锁对数据库系统的自动管理不感冒，需要程序员直接管理数据或对象上的加锁处理，并负责获取、共享和放弃正在使用的数据上的任何锁。

锁的级别：
未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。
Websphere:
1．Java 虚拟机初始堆大小和最大堆大小 512
2．web容器的线程池最小大小和最大大小 客户数
3．Jdbc连接池属性 100 ~ 客户数
4．servlet高速缓存 启用
5．语句高速缓存大小
http server: httpd.conf
1．KeepAlive 保持客户与HTTP SERVER的连接 OFF
2．ThreadsPerChild 服务器响应线程的数量 客户数
3．CustomLog 日志记录