SQL语句效率

SQL语句效率
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。

调整不良SQL通常可以从以下几点切入：
? 检查不良的SQL，考虑其写法是否还有可优化内容
? 检查子查询考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器
2. 避免出现SELECT * FROM table 语句，要明确查出的字段。

3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。

4. 查询时尽可能使用索引覆盖。

即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。

5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。

6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。

7. 应绝对避免在order by子句中使用表达式。

8. 如果需要从关联表读数据，关联的表一般不要超过7个。

9. 小心使用IN 和OR，需要注意In集合中的数据量。

建议集合中的数据不超过200个。

10. <> 用< 、> 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。

11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。

12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。

只能是F1或F1，F2或F1，F2，F3。

否则不会用到该索引。

13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。

格式如下select sum （table1.je）from table1 table1, table2 table2, table3 table3 where (ta
ble1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。

注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。

14. 子查询问题。

对于能用连接方式或者视图方式实现的功能，不要用子查询。

例如：select name from customer where customer_id in ( select customer_id fro m order where money>1000)。

应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.cu stomer_id where order.money>100。

15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。

比如有些地方substring 可以用like代替。

16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。

17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。

18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。

19. 用union all 代替union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。

当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all 代替union，以提高查询效率。

数据更新的效率
1. 在一个事物中，对同一个表的多个insert语句应该集中在一起执行。

2. 在一个业务过程中，尽量的使insert,update,delete语句在业务结束前执行，以减少死锁的可能性。

数据库物理规划的效率
为了避免I/O的冲突，我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE 举例)：
table和index分离：table和index应该分别放在不同的tablespace中。

"
Rollback Segment的分离：Rollback Segment应该放在独立的Tablespace中。

"
System Tablespace的分离：System Tablespace中不允许放置任何用户的object。

（mssql 中primary filegroup中不允许放置任何用户的object）"
Temp Tablesace的分离：建立单独的Temp Tablespace，并为每个user指定default Temp Tablespace "
避免碎片：但segment中出现大量的碎片时，会导致读数据时需要访问的block数量的增加。

对经常发生DML操作的segemeng来说，碎片是"不能完全避免的。

所以，我们应该将经常做DML操作的表和很少发生变化的表分离在不同的Tablespace中。

当我们遵循了以上原则后，仍然发现有I/O冲突存在，我们可以用数据分离的方法来解决。

连接Table的分离：在实际应用中经常做连接查询的Table，可以将其分离在不同的Taclespace中，以减少I/O冲突。

"
使用分区：对数据量很大的Table和Index使用分区，放在不同的Tablespace中。

"
在实际的物理存储中，建议使用RAID。

日志文件应放在单独的磁盘中。

快速了解影响SQL Server性能的主要原因
[b]问:[/b]影响SQL Server性能的主要原因都有哪些?
[b]答:[/b]影响SQL Server性能的关键主要包括以下几个方面：
[b]第一方面：逻辑数据库和表的设计[/b]
数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。

一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。

下面是一些使用标准化表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速。

B:由于多表，所以多镞的索引成为可能。

C:更窄更紧凑的索引。

D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引多的情况下会对系统性能产生很大的影响。

E:更少的空值和更少的多余值，增加了数据库的紧凑性由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。

太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。

定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。

[b]第二方面:索引的设计[/b]
A:尽量避免表扫描
检查你的查询语句的where子句，因为这是优化器重要关注的地方。

包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。

下面的两个条件可以提高索引的优化查询性能！
第一：在表中的column1列上有一个单索引；
第二：在表中有多索引，但是column1是第一个索引的列。

避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能。

例如：下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
按下面几个列上建立的索引将会是对优化器有用的索引:
au_lname
au_lname, au_fname
而在下面几个列上建立的索引将不会对优化器起到好的作用:
au_address
au_fname, au_lname
考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。

用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。

对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的histogram（柱状图）统计。

根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。

有用的索引会提高select语句的性能，包括insert,uodate,delete。

但是，由于改变一个表的内容，将会影响索引。

每一个insert,update,delete语句将会使性能下降一些。

实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。

在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。

这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。

你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name
假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index
5000 Nonclustered index
20 Clustered index
3 No index
镞索引和非镞索引的选择:
镞索引是行的物理顺序和索引的顺序是一致的。

页级，低层等索引的各个级别上都包含实际的数据页。

一个表只能是有一个镞索引。

由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。

在至少有一个索引的表中，你应该有一个镞索引。

在下面的几个情况下，你可以考虑用镞索引：
例如：某列包括的不同值的个数是有限的（但是不是极少的）
顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。

例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,
select * from sales where ord_date between ’5/1/93’ and ’6/1/93’
例如：对查询时返回大量结果的列可以使用镞索引。

SELECT * FROM phonebook WHERE last_name = ’Smith’
当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。

如果你建立了镞的索引，那么insert的性能就会大大降低。

因为每一个插入的行必须到表的最后，表的最后一个数据页。

当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。

一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

一个非镞的索引就是行的物理次序与索引的次序是不同的。

一个非镞索引的叶级包含了指向行数据页的指针。

在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。

在有很多不同值的列上可以考虑使用非镞索引
例如：一个part_id列在一个part表中
select * from employee where emp_id = ’pcm9809f’
查询语句中用order by 子句的列上可以考虑使用镞索引。

[b]第三方面:查询语句的设计[/b]
SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。

优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。

最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。

在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。

例如下面的例子，
select qty from sales where stor_id=7131
是很有效的比下面这个无限制的查询
select qty from sales
避免给客户的最后数据选择返回大量的结果集。

允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。

这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。

因为优化器关注的焦点就是where子句的查询，以利用有用的索引。

在表中的每一个索引都可能成为包括在where子句中的侯选索引。

为了最好的性能可以遵照下面的用于一个给定列column1的索引。

第一：在表中的column1列上有一个单索引；
第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。

这时多索引是没有用的。

For example, given a multicolumn index on the au_lname,
au_fname columns of the authors table in
the pubs database,
下面这个query语句利用了au_lname上的索引:
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
AND au_fname = ’Johnson’
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = ’White’
下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引:
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = ’Johnson’
1 逻辑数据库和表的设计
数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。

一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。

下面是一些使用标准化表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速
B:由于多表，所以多镞的索引成为可能
C:更窄更紧凑的索引
D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引多的情况下会对系统性能产生很大的影响
E:更少的空值和更少的多余值，增加了数据库的紧凑性
由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。

太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。

定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。

2 索引的设计
A:尽量避免表扫描
检查你的查询语句的where子句，因为这是优化器重要关注的地方。

包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。

下面的两个条件可以提高索引的优化查询性能！
第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列
避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能
例如：下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
按下面几个列上建立的索引将会是对优化器有用的索引
au_lname
au_lname, au_fname
而在下面几个列上建立的索引将不会对优化器起到好的作用
au_address
au_fname, au_lname
考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。

用窄的索引，在每一页上将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。

对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的
histogram（柱状图）统计。

根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。

有用的索引会提高select语句的性能，包括insert,uodate,delete。

但是，由于改变一个表的内容，将会影响索引。

每一个insert,update,delete语句将会使性能下降一些。

实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。

在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。

这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。

你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name
假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index
5000 Nonclustered index
20 Clustered index
3 No index
镞索引和非镞索引的选择
＜1＞镞索引是行的物理顺序和索引的顺序是一致的。

页级，低层等索引的各个级别上都包含实际的数据页。

一个表只能是有一个镞索引。

由于update, delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。

在至少有一个索引的表中，你应该有一个镞索引。

在下面的几个情况下，你可以考虑用镞索引：
例如：某列包括的不同值的个数是有限的（但是不是极少的）
顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。

例如：对返回一定范围内值的列可以使用镞索引，比如用between,＞,＞=,＜,＜=等等来对列进行操作的列上。

select * from sales where ord_date between '5/1/93' and '6/1/93'
例如：对查询时返回大量结果的列可以使用镞索引。

SELECT * FROM phonebook WHERE last_name = 'Smith'
当有大量的行正在被插入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。

如果你建立了镞的索引，那么insert的性能就会大大降低。

因为每一个插入的行必须到表的最后，表的最后一个数据页。

当一个数据正在被插入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。

一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

＜2＞一个非镞的索引就是行的物理次序与索引的次序是不同的。

一个非镞索引的叶级包含了指向行数据页的指针。

在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。

在有很多不同值的列上可以考虑使用非镞索引
例如：一个part_id列在一个part表中
select * from employee where emp_id = 'pcm9809f'
查询语句中用order by 子句的列上可以考虑使用镞索引
3 查询语句的设计
SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。

优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。

最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。

在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。

例如下面的例子，select qty from sales where stor_id=7131是很有效的比下面这个无限制的查询
select qty from sales
避免给客户的最后数据选择返回大量的结果集。

允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。

这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。

因为优化器关注的焦点就是where子句的查询，以利用有用的索引。

在表中的每一个索引都可能成为包括在where 子句中的侯选索引。

为了最好的性能可以遵照下面的用于一个给定列column1的索引。

第一：在表中的column1列上有一个单索引
第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。

这时多索引是没有用的。

For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in
the pubs database,
下面这个query语句利用了au_lname上的索引
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
AND au_fname = 'Johnson'
SELECT au_id, au_lname, au_fname FROM authors
WHERE au_lname = 'White'
下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引SELECT au_id, au_lname, au_fname FROM authors
WHERE au_fname = 'Johnson'。