数据库访问性能优化(四)

4.2、合理使用排序

Oracle的排序算法一直在优化，可是整体时间复杂度约等于nLog(n)。普通OLTP系统排序操做通常都是在内存里进行的，对于数据库来讲是一种CPU的消耗，曾在PC机作过测试，单核普通CPU在1秒钟能够完成100万条记录的全内存排序操做，因此说因为如今CPU的性能加强，对于普通的几十条或上百条记录排序对系统的影响也不会很大。可是当你的记录集增长到上万条以上时，你须要注意是否必定要这么作了，大记录集排序不只增长了CPU开销，并且可能会因为内存不足发生硬盘排序的现象，当发生硬盘排序时性能会急剧降低，这种需求须要与DBA沟通再决定，取决于你的需求和数据，因此只有你本身最清楚，而不要被别人说排序很慢就吓倒。

如下列出了可能会发生排序操做的SQL语法：

Order by

Group by

Distinct

Exists子查询

Not Exists子查询

In子查询

Not In子查询

Union（并集），Union All也是一种并集操做，可是不会发生排序，若是你确认两个数据集不须要执行去除重复数据操做，那请使用Union All 代替Union。

Minus（差集）

Intersect（交集）

Create Index

Merge Join，这是一种两个表链接的内部算法，执行时会把两个表先排序好再链接，应用于两个大表链接的操做。若是你的两个表链接的条件都是等值运算，那能够采用Hash Join来提升性能，由于Hash Join使用Hash 运算来代替排序的操做。具体原理及设置参考SQL执行计划优化专题。

 

4.3、减小比较操做

咱们SQL的业务逻辑常常会包含一些比较操做，如a=b，a之类的操做，对于这些比较操做数据库都体现得很好，可是若是有如下操做，咱们须要保持警戒：

Like模糊查询，以下所示：

a like ‘c%’

 

Like模糊查询对于数据库来讲不是很擅长，特别是你须要模糊检查的记录有上万条以上时，性能比较糟糕，这种状况通常能够采用专用Search或者采用全文索引方案来提升性能。

不能使用索引定位的大量In List，以下所示：

a in (:1,:2,:3,…,:n)   ----n>20

若是这里的a字段不能经过索引比较，那数据库会将字段与in里面的每一个值都进行比较运算，若是记录数有上万以上，会明显感受到SQL的CPU开销加大，这个状况有两种解决方式：

a、  将in列表里面的数据放入一张中间小表，采用两个表Hash Join关联的方式处理；

b、  采用str2varList方法将字段串列表转换一个临时表处理，关于str2varList方法能够在网上直接查询，这里不详细介绍。

 

以上两种解决方案都须要与中间表Hash Join的方式才能提升性能，若是采用了Nested Loop的链接方式性能会更差。

若是发现咱们的系统IO没问题可是CPU负载很高，就有多是上面的缘由，这种状况不太常见，若是遇到了最好能和DBA沟通并确认准确的缘由。

 

4.4、大量复杂运算在客户端处理

什么是复杂运算，通常我认为是一秒钟CPU只能作10万次之内的运算。如含小数的对数及指数运算、三角函数、3DES及BASE64数据加密算法等等。

若是有大量这类函数运算，尽可能放在客户端处理，通常CPU每秒中也只能处理1万-10万次这样的函数运算，放在数据库内不利于高并发处理。

 

5、利用更多的资源

5.1、客户端多进程并行访问

多进程并行访问是指在客户端建立多个进程(线程)，每一个进程创建一个与数据库的链接，而后同时向数据库提交访问请求。当数据库主机资源有空闲时，咱们能够采用客户端多进程并行访问的方法来提升性能。若是数据库主机已经很忙时，采用多进程并行访问性能不会提升，反而可能会更慢。因此使用这种方式最好与DBA或系统管理员进行沟通后再决定是否采用。

 

例如：

咱们有10000个产品ID，如今须要根据ID取出产品的详细信息，若是单线程访问，按每一个IO要5ms计算，忽略主机CPU运算及网络传输时间，咱们须要50s才能完成任务。若是采用5个并行访问，每一个进程访问2000个ID，那么10s就有可能完成任务。

那是否是并行数越多越好呢，开1000个并行是否只要50ms就搞定，答案确定是否认的，当并行数超过服务器主机资源的上限时性能就不会再提升，若是再增长反而会增长主机的进程间调度成本和进程冲突机率。

 

如下是一些如何设置并行数的基本建议：

若是瓶颈在服务器主机，可是主机还有空闲资源，那么最大并行数取主机CPU核数和主机提供数据服务的磁盘数两个参数中的最小值，同时要保证主机有资源作其它任务。

若是瓶颈在客户端处理，可是客户端还有空闲资源，那建议不要增长SQL的并行，而是用一个进程取回数据后在客户端起多个进程处理便可，进程数根据客户端CPU核数计算。

若是瓶颈在客户端网络，那建议作数据压缩或者增长多个客户端，采用map reduce的架构处理。

若是瓶颈在服务器网络，那须要增长服务器的网络带宽或者在服务端将数据压缩后再处理了。

 

5.2、数据库并行处理

数据库并行处理是指客户端一条SQL的请求，数据库内部自动分解成多个进程并行处理，以下图所示：

 

 

并非全部的SQL均可以使用并行处理，通常只有对表或索引进行所有访问时才可使用并行。数据库表默认是不打开并行访问，因此须要指定SQL并行的提示，以下所示：

select  * from employee;

 

并行的优势：

使用多进程处理，充分利用数据库主机资源（CPU,IO），提升性能。

并行的缺点：

1、单个会话占用大量资源，影响其它会话，因此只适合在主机负载低时期使用；

2、只能采用直接IO访问，不能利用缓存数据，因此执行前会触发将脏缓存数据写入磁盘操做。

 

注：

1、并行处理在OLTP类系统中慎用，使用不当会致使一个会话把主机资源所有占用，而正常事务得不到及时响应，因此通常只是用于数据仓库平台。

2、通常对于百万级记录如下的小表采用并行访问性能并不能提升，反而可能会让性能更差。