sql性能优化浅谈

sql性能优化总结：

最近随着数据越来越多，数据库性能问题暴露的越来越严重。几百万，上千万，甚至过亿的数据处理速度会非常的慢。

下面对工作中遇到的问题做下总结，希望以后能对日后的工作有所帮助。

不同的sql语句有不同的性能问题，只有要找到性能差的原因，才能对症下药。

首先说下性能判断的方法：

一.性能分析器：Microsoft的SQL Profiler

Oracle的Audit和AWR ,oracle也可以用PLsql中的explain plan（黄色灯泡）来分析。

二.性能相关SQL语句：（目前先拿sql server 说，其他版本慢慢补充。）

-- 建聚集索引
CREATE CLUSTERED INDEX INDEX_Userid
ON T_UserInfo ( Userid)
-- 建非聚集索引
CREATE NONCLUSTERED INDEX INDEX_Userid
ON T_UserInfo ( Userid)
-- 删除索引
DROP INDEX T_UserInfo. INDEX_Userid
-- 显示有关由 Transact-SQL 语句生成的磁盘活动量的信息
SET STATISTICS IO
ON
-- 关闭有关由 Transact-SQL 语句生成的磁盘活动量的信息
SET STATISTICS IO
OFF
-- 显示 [ 返回有关语句执行情况的详细信息，并估计语句对资源的需求 ]
SET SHOWPLAN_ALL ON
-- 关闭 [ 返回有关语句执行情况的详细信息，并估计语句对资源的需求 ]
SET SHOWPLAN_ALL OFF

-- 建聚集索引

CREATE CLUSTERED INDEX INDEX_Userid  ON T_UserInfo ( Userid)

-- 建非聚集索引

CREATE NONCLUSTERED INDEX INDEX_Userid  ON T_UserInfo ( Userid)

-- 删除索引

DROP INDEX T_UserInfo. INDEX_Userid 

-- 显示有关由 Transact-SQL 语句生成的磁盘活动量的信息

SET STATISTICS IO ON

-- 关闭有关由 Transact-SQL 语句生成的磁盘活动量的信息

SET STATISTICS IO OFF

-- 显示 [ 返回有关语句执行情况的详细信息，并估计语句对资源的需求 ]

SET SHOWPLAN_ALL  ON

-- 关闭 [ 返回有关语句执行情况的详细信息，并估计语句对资源的需求 ]

SET SHOWPLAN_ALL  OFF

*注意：（扫盲高手跳过）聚集索引就是表存储的时候的顺序，一张表只能有一个聚集索引。非聚集索引就表存储的结构不是按索引结构存储的。

具体使用方法看sql server帮助说的很全了，这里总结SHOWPLAN_ALL需要注意的几点：

1.Index Seek(索引查找) ：索引查找意味着查询优化器使用了数据表上的非聚集索引来查找数据。

性能通常会很快，尤其是当只有少数的数据行被返回时。

2.Clustered Index Seek：聚集索引查找。这指查询优化器使用了数据表上的聚集索引来查找数据，性能很快。

3.Clustered Index Scan：聚集索引扫描。聚集索引扫描与表扫描相似，不同的是聚集索引扫描是在一个建有聚集索引的数据表上执行的。和一般的表扫描一样，聚集索引扫描可能表明存在效能问题。

上面3项是性能比较好快的，下面几项从性能上来说是不理想的，避免的越多性能越快：

1.Table Scan：表扫描。如果看到这个信息，就说明数据表上没有聚集索引，或者查询优化器没有使用索引来查找。

2.Index or table scans：索引或者表扫描。可能意味着需要更好的或者额外的索引。

3.Bookmark Lookups：书签查找。考虑修改当前的聚集索引，使用复盖索引，限制 SELECT 语句中的字段数量。

4.Filter：过滤。在WHERE从句中移除用到的任何函数，不要在 SQL 语句中包含视图，可能需要额外的索引。

5.Sort：排序。如果查询的数据本身就是按一定顺序排序的，或者查询结果对排序无要求，那就不需要排序。

写sql文的注意事项：

1.创建索引，在大量甚至海量数据的表里有索引检索的速度要比没有索引检索快上几个数量级。

2.视图，视图本身不能建立索引，但是视图可以应用引用表的索引，当引用表的字段结构未变化时。

3.IN , NOT IN ==>替换方案EXISTS, NOT EXISTS

尤其是NOT IN不能应用表的索引，建议不使用。在 JOIN 关联后也最好不要使用IN.

但是如果是 IN (12,21,13,14) 这种还是可以使用, 这种用法比 OR ....OR...OR 要快一点儿。

4. <> , !=

不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。

a!=0 改为 a>0 or a<0

a!=’’ 改为 a>’’

5. > 或者<

a>1 改为 a>=1 , b < 2 改为 b<=2;

这里涉及到索引的应用问题，利用>= 或 <=能够更好的应用索引。

6. WHERE 后的条件顺序

mysql 采用从左至右的顺序解析WHERE子句,那些可以过滤掉最大数量记录的条件写在WHERE子句的前面。

ORACLE 采用从右至左的顺序解析WHERE子句,那些可以过滤掉最大数量记录的条件写在WHERE子句的末尾。

7. GROUP BY

Group BY 后面跟的分组条件越多越慢，切忌不要无谓的添加分组条件。

8. 在sql文中转换类型会非常的慢尽量不要使用 to_char, to_date 等函数。

9. SELECT子句中避免使用 *

WHERE exsits (select * from XX_table) ==> WHERE exsits (select
id from XX_table)

巴特西

sql性能优化浅谈

最新文章

热门文章