具体要注意的:
1应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
2应尽量避免在 where 子句中使用!=或<> *** 作符,否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
3应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10
union all
select id from t where num=20
4in 和 not in 也要慎用,因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如:
select id from t where num in(1,2,3)
对于连续的数值,能用 between 就不要用 in 了:
select id from t where num between 1 and 3
5尽量避免在索引过的字符数据中,使用非打头字母搜索。这也使得引擎无法利用索引。
见如下例子:
SELECT FROM T1 WHERE NAME LIKE ‘%L%’
SELECT FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
SELECT FROM T1 WHERE NAME LIKE ‘L%’
即使NAME字段建有索引,前两个查询依然无法利用索引完成加快 *** 作,引擎不得不对全表所有数据逐条 *** 作来完成任务。而第三个查询能够使用索引来加快 *** 作。
6必要时强制查询优化器使用某个索引,如在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
select id from t where num=@num
可以改为强制查询使用索引:
select id from t with(index(索引名)) where num=@num
7应尽量避免在 where 子句中对字段进行表达式 *** 作,这将导致引擎放弃使用索引而进行全表扫描。如:
SELECT FROM T1 WHERE F1/2=100
应改为:
SELECT FROM T1 WHERE F1=1002
SELECT FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
应改为:
SELECT FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
应改为:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即:任何对列的 *** 作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将 *** 作移至等号右边。
8应尽量避免在where子句中对字段进行函数 *** 作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
10在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。
11很多时候用 exists是一个好的选择:
select num from a where num in(select num from b)
用下面的语句替换:
select num from a where exists(select top 1 from b where num=anum)
SELECT SUM(T1C1)FROM T1 WHERE(
(SELECT COUNT()FROM T2 WHERE T2C2=T1C2>0)
SELECT SUM(T1C1) FROM T1WHERE EXISTS(
SELECT FROM T2 WHERE T2C2=T1C2)
两者产生相同的结果,但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。
如果你想校验表里是否存在某条纪录,不要用count()那样效率很低,而且浪费服务器资源。可以用EXISTS代替。如:
IF (SELECT COUNT() FROM table_name WHERE column_name = 'xxx')
可以写成:
IF EXISTS (SELECT FROM table_name WHERE column_name = 'xxx')
经常需要写一个T_SQL语句比较一个父结果集和子结果集,从而找到是否存在在父结果集中有而在子结果集中没有的记录,如:
SELECT ahdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替
WHERE NOT EXISTS (SELECT FROM dtl_tbl b WHERE ahdr_key = bhdr_key)
SELECT ahdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON ahdr_key = bhdr_key WHERE bhdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三种写法都可以得到同样正确的结果,但是效率依次降低。
12尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
13避免频繁创建和删除临时表,以减少系统表资源的消耗。
14临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。
15在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。
16如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。
17在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
18尽量避免大事务 *** 作,提高系统并发能力。
19尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。
20 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化 *** 作。例如:
SELECT name FROM employee WHERE salary > 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。
21充分利用连接条件,在某种情况下,两个表之间可能不只一个的连接条件,这时在 WHERE 子句中将连接条件完整的写上,有可能大大提高查询速度。
例:
SELECT SUM(AAMOUNT) FROM ACCOUNT A,CARD B WHERE ACARD_NO = BCARD_NO
SELECT SUM(AAMOUNT) FROM ACCOUNT A,CARD B WHERE ACARD_NO = BCARD_NO AND AACCOUNT_NO=BACCOUNT_NO
第二句将比第一句执行快得多。
22、使用视图加速查询
把表的一个子集进行排序并创建视图,有时能加速查询。它有助于避免多重排序 *** 作,而且在其他方面还能简化优化器的工作。例如:
SELECT custname,rcvblesbalance,……other columns
FROM cust,rcvbles
WHERE custcustomer_id = rcvlbescustomer_id
AND rcvbllsbalance>0
AND custpostcode>“98000”
ORDER BY custname
如果这个查询要被执行多次而不止一次,可以把所有未付款的客户找出来放在一个视图中,并按客户的名字进行排序:
CREATE VIEW DBOV_CUST_RCVLBES
AS
SELECT custname,rcvblesbalance,……other columns
FROM cust,rcvbles
WHERE custcustomer_id = rcvlbescustomer_id
AND rcvbllsbalance>0
ORDER BY custname
然后以下面的方式在视图中查询:
SELECT * FROM V_CUST_RCVLBES
WHERE postcode>“98000”
视图中的行要比主表中的行少,而且物理顺序就是所要求的顺序,减少了磁盘I/O,所以查询工作量可以得到大幅减少。
23、能用DISTINCT的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改为:
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24能用UNION ALL就不要用UNION
UNION ALL不执行SELECT DISTINCT函数,这样就会减少很多不必要的资源
35尽量不要用SELECT INTO语句。
SELECT INOT 语句会导致表锁定,阻止其他用户访问该表。
上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试,看实现相同功能的SQL语句哪个执行时间最少,但是数据库中如果数据量很少,是比较不出来的,这时可以用查看执行计划,即:把实现相同功能的多条SQL语句考到查询分析器,按CTRL+L看查所利用的索引,表扫描次数(这两个对性能影响最大),总体上看询成本百分比即可。
今天在itput上看了一篇文章,是讨论一个语句的优化:
原贴地址: >
避免或简化排序;
消除对大型表行数据的顺序存取;
避免相关子查询;
避免困难的正规表达式;
使用临时表加速查询。
数据表有两种含义,一是指数据库最重要的组成部分之一,二是指电子元件,电子芯片等的数据手册(datasheet)。
数据表一般为产品或资料提供一个详细具体的数据资料,方便人们使用和工作时能够清楚方便的获得相应的数据信息。
没有数据表,关键字、主键、索引等也就无从谈起。在数据库画板中可以显示数据库中的所有数据表(即使不是用PowerBuilder创建的表),创建数据表,修改表的定义等数据表是数据库中一个非常重要的对象,是其他对象的基础。
1、主键就是聚集索引
2、只要建立索引就能显著提高查询速度
3、把所有需要提高查询速度的字段都加进聚集索引,以提高查询速度
(四)其他书上没有的索引使用经验总结
1、用聚合索引比用不是聚合索引的主键速度快
2、用聚合索引比用一般的主键作order by时速度快,特别是在小数据量情况下
3、使用聚合索引内的时间段,搜索时间会按数据占整个数据表的百分比成比例减少,而无论聚合索引使用了多少个
4 、日期列不会因为有分秒的输入而减慢查询速度
(五)其他注意事项
1 不要索引常用的小型表
2 不要把社会保障号码(SSN)或身份z号码(ID)选作键
3 不要用用户的键
4 不要索引 memo/notes 字段和不要索引大型文本字段(许多字符)
5 使用系统生成的主键
二、改善SQL语句
1、Like语句是否属于SARG取决于所使用的通配符的类型
2、or 会引起全表扫描
3、非 *** 作符、函数引起的不满足SARG形式的语句
4、IN 的作用相当与OR
5、尽量少用NOT
6、exists 和 in 的执行效率是一样的
7、用函数charindex()和前面加通配符%的LIKE执行效率一样
8、union并不绝对比or的执行效率高
9、字段提取要按照“需多少、提多少”的原则,避免“select ”
10、count()不比count(字段)慢
11、order by按聚集索引列排序效率最高
12、高效的TOP
1:使用select in 的话不会使用任何索引,全表扫描,所以数据量大的话较慢
2:in里面的数据转换为表变量或者临时表的话,可以使用排序
3:如果是使用in的话,2008不会比2000快到哪里,都是全表扫描
以上就是关于关于SQL数据库优化全部的内容,包括:关于SQL数据库优化、数据库表数据量大怎么优化查询速度、如何在 SQL 数据库优化 索引,SQL索引优化等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)