数据库优化方案(四)
2012-06-26 15:11
78 查看
7、尽量使用索引
建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,索引的选择和使用方法是SQLSERVER的优化器自动作的选择,而它选择的根据是查询语句的条件以及相关表的统计信息,这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引。
为了使得优化器能高效使用索引,写语句的时候应该注意:
A、不要对索引字段进行运算,而要想办法做变换,比如
SELECT ID FROM T WHERE NUM/2=100
应改为:
SELECT ID FROM T WHERE NUM=100*2
SELECT ID FROM T WHERE NUM/2=NUM1
如果NUM有索引应改为:
SELECT ID FROM T WHERE NUM=NUM1*2
如果NUM1有索引则不应该改。
发现过这样的语句:
SELECT年,月,金额FROM结余表
WHERE100*年+月=2007*100+10
应该改为:
SELECT年,月,金额FROM结余表
WHERE年=2007 AND月=10
B、不要对索引字段进行格式转换
日期字段的例子:
WHERE CONVERT(VARCHAR(10),日期字段,120)=’ 2008-08-15’
应该改为
WHERE日期字段〉=’2008-08-15’AND日期字段<’2008-08-16’
ISNULL转换的例子:
WHEREISNULL(字段,’’)<>’’应改为:WHERE字段<>’’
WHEREISNULL(字段,’’)=’’不应修改
WHEREISNULL(字段,’F’)=’T’应改为:WHERE字段=’T’
WHERE ISNULL(字段,’F’)<>’T’不应修改
C、不要对索引字段使用函数
WHERE LEFT(NAME,3)='ABC'或者WHERESUBSTRING(NAME,1,3)='ABC'
应改为:
WHERE NAME LIKE'ABC%'
日期查询的例子:
WHERE DATEDIFF(DAY,日期,'2005-11-30')=0应改为:WHERE日期>='2005-11-30'AND日期<'2005-12-1'
WHERE DATEDIFF(DAY,日期,'2005-11-30')>0应改为:WHERE日期<'2005-11-30'
WHERE DATEDIFF(DAY,日期,'2005-11-30')>=0应改为:WHERE日期<'2005-12-01'
WHERE DATEDIFF(DAY,日期,'2005-11-30')<0应改为:WHERE日期>='2005-12-01'
WHERE DATEDIFF(DAY,日期,'2005-11-30')<=0应改为:WHERE日期>='2005-11-30'
D、不要对索引字段进行多字段连接
比如:
WHERE FNAME+'.'+LNAME=‘HAIWEI.YANG’
应改为:
WHEREFNAME=‘HAIWEI’ANDLNAME=‘YANG’
8、注意连接条件的写法
多表连接的连接条件对索引的选择有着重要的意义,所以我们在写连接条件条件的时候需要特别的注意。
A、多表连接的时候,连接条件必须写全,宁可重复,不要缺漏。
B、连接条件尽量使用聚集索引
C、 注意ON部分条件和WHERE部分条件的区别
9、其他需要注意的地方
经验表明,问题发现的越早解决的成本越低,很多性能问题可以在编码阶段就发现,为了提早发现性能问题,需要注意:
A、程序员注意、关心各表的数据量。
B、编码过程和单元测试过程尽量用数据量较大的数据库测试,最好能用实际数据测试。
C、 每个SQL语句尽量简单
D、不要频繁更新有触发器的表的数据
E、注意数据库函数的限制以及其性能
10、 学会分辩SQL语句的优劣
自己分辨SQL语句的优劣非常重要,只有自己能分辨优劣才能写出高效的语句。
A、 查看SQL语句的执行计划,可以在查询分析其使用CTRL+L图形化的显示执行计划,一般应该注意百分比最大的几个图形的属性,把鼠标移动到其上面会显示这个图形的属性,需要注意预计成本的数据,也要注意其标题,一般都是CLUSTEREDINDEX SEEK 、INDEX SEEK 、CLUSTEREDINDEX SCAN 、INDEX SCAN 、TABLESCAN等,其中出现SCAN说明语句有优化的余地。也可以用语句SETSHOW PLAN_ALLON
要执行的语句SETSHOW PLAN_ALL OFF查看执行计划的文本详细信息。
B、用事件探查器跟踪系统的运行,可疑跟踪到执行的语句,以及所用的时间,CPU用量以及I/O数据,从而分析语句的效率。
C、可以用WINDOWS的系统性能检测器,关注CPU、I/O参数
建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,索引的选择和使用方法是SQLSERVER的优化器自动作的选择,而它选择的根据是查询语句的条件以及相关表的统计信息,这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引。
为了使得优化器能高效使用索引,写语句的时候应该注意:
A、不要对索引字段进行运算,而要想办法做变换,比如
SELECT ID FROM T WHERE NUM/2=100
应改为:
SELECT ID FROM T WHERE NUM=100*2
SELECT ID FROM T WHERE NUM/2=NUM1
如果NUM有索引应改为:
SELECT ID FROM T WHERE NUM=NUM1*2
如果NUM1有索引则不应该改。
发现过这样的语句:
SELECT年,月,金额FROM结余表
WHERE100*年+月=2007*100+10
应该改为:
SELECT年,月,金额FROM结余表
WHERE年=2007 AND月=10
B、不要对索引字段进行格式转换
日期字段的例子:
WHERE CONVERT(VARCHAR(10),日期字段,120)=’ 2008-08-15’
应该改为
WHERE日期字段〉=’2008-08-15’AND日期字段<’2008-08-16’
ISNULL转换的例子:
WHEREISNULL(字段,’’)<>’’应改为:WHERE字段<>’’
WHEREISNULL(字段,’’)=’’不应修改
WHEREISNULL(字段,’F’)=’T’应改为:WHERE字段=’T’
WHERE ISNULL(字段,’F’)<>’T’不应修改
C、不要对索引字段使用函数
WHERE LEFT(NAME,3)='ABC'或者WHERESUBSTRING(NAME,1,3)='ABC'
应改为:
WHERE NAME LIKE'ABC%'
日期查询的例子:
WHERE DATEDIFF(DAY,日期,'2005-11-30')=0应改为:WHERE日期>='2005-11-30'AND日期<'2005-12-1'
WHERE DATEDIFF(DAY,日期,'2005-11-30')>0应改为:WHERE日期<'2005-11-30'
WHERE DATEDIFF(DAY,日期,'2005-11-30')>=0应改为:WHERE日期<'2005-12-01'
WHERE DATEDIFF(DAY,日期,'2005-11-30')<0应改为:WHERE日期>='2005-12-01'
WHERE DATEDIFF(DAY,日期,'2005-11-30')<=0应改为:WHERE日期>='2005-11-30'
D、不要对索引字段进行多字段连接
比如:
WHERE FNAME+'.'+LNAME=‘HAIWEI.YANG’
应改为:
WHEREFNAME=‘HAIWEI’ANDLNAME=‘YANG’
8、注意连接条件的写法
多表连接的连接条件对索引的选择有着重要的意义,所以我们在写连接条件条件的时候需要特别的注意。
A、多表连接的时候,连接条件必须写全,宁可重复,不要缺漏。
B、连接条件尽量使用聚集索引
C、 注意ON部分条件和WHERE部分条件的区别
9、其他需要注意的地方
经验表明,问题发现的越早解决的成本越低,很多性能问题可以在编码阶段就发现,为了提早发现性能问题,需要注意:
A、程序员注意、关心各表的数据量。
B、编码过程和单元测试过程尽量用数据量较大的数据库测试,最好能用实际数据测试。
C、 每个SQL语句尽量简单
D、不要频繁更新有触发器的表的数据
E、注意数据库函数的限制以及其性能
10、 学会分辩SQL语句的优劣
自己分辨SQL语句的优劣非常重要,只有自己能分辨优劣才能写出高效的语句。
A、 查看SQL语句的执行计划,可以在查询分析其使用CTRL+L图形化的显示执行计划,一般应该注意百分比最大的几个图形的属性,把鼠标移动到其上面会显示这个图形的属性,需要注意预计成本的数据,也要注意其标题,一般都是CLUSTEREDINDEX SEEK 、INDEX SEEK 、CLUSTEREDINDEX SCAN 、INDEX SCAN 、TABLESCAN等,其中出现SCAN说明语句有优化的余地。也可以用语句SETSHOW PLAN_ALLON
要执行的语句SETSHOW PLAN_ALL OFF查看执行计划的文本详细信息。
B、用事件探查器跟踪系统的运行,可疑跟踪到执行的语句,以及所用的时间,CPU用量以及I/O数据,从而分析语句的效率。
C、可以用WINDOWS的系统性能检测器,关注CPU、I/O参数
相关文章推荐
- 数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案(转)
- 数据库优化设计方案(转)
- 百万级数据库优化方案
- SQL优化大总结之 百万级数据库优化方案
- 数据库SQL优化百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库查询优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库SQL优化大总结之百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- sql百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库查询优化方案(处理上百万级记录如何提高处理查询速度)
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库SQL优化大总结之 百万级数据库优化方案(转)
- 数据库优化设计方案
- 数据库SQL优化大总结之 百万级数据库优化方案