30 分钟快快乐乐学 SQL Performance Tuning

30 分钟快快乐乐学 SQL Performance Tuning

有些程序员在撰写数据库应用程序时，常专注于 OOP 及各种 framework 的使用，却忽略了基本的 SQL 语句及其「性能 (performance) 优化」问题。版工曾听过台湾某半导体大厂的新进程序员，所组出来的一段
PL/SQL 跑了好几分钟还跑不完；想当然尔，即使他的 AJAX 及 ooxx 框架用得再漂亮，系统性能也会让使用者无法忍受。以下是版工整理出的一些数据库规划、SQL performance tuning 简单心得，让长年钻研 .NET、AJAX、一堆高深 ooxx framework，却无暇研究 SQL statement 的程序员，透过最短时间对本帖的阅读，能避免踩到一些
SQL 的性能地雷。

(注：本帖的 SQL 语句皆经过测试可正常执行无误。有兴趣实验者，可直接拷贝后，粘贴至 SQL Server 中执行。)

1、数据库设计与规划

• Primary Key 字段的长度尽量小，能用 small integer 就不要用 integer。例如员工数据表，若能用员工编号当主键，就不要用身分证号码。
• 一般字段亦同。若该数据表要存放的数据不会超过 3 万笔，用 small integer 即可，不必用 integer。
• 文字字段若长度固定，如：身分证号码，就不要用 varchar 或 nvarchar，应该用 char 或 nchar。
• 文字字段若长度不固定，如：地址，则该用 varchar 或 nvarchar。除了可节省存储空间外，存取硬盘时也会较有效率。
• 设计字段时，若其值可有可无，最好也给一个默认值，并设成「不允许 NULL」(一般字段默认为「允许 NULL」)。因为 SQL Server 在存放和查询有
NULL 的数据表时，会花费额外的运算动作 [2]。
• 若一个数据表的字段过多，应垂直切割成两个以上的数据表，并可用同名的 Primary Key 一对多连结起来，如：Northwind 的 Orders、Order
Details 数据表。以避免在存取数据时，以「集簇索引 (clustered index)」扫描时会加载过多的数据，或修改数据时造成互相锁定或锁定过久。
------------------------------
2、适当地建立索引
• 记得自行帮 Foreign Key 字段建立索引，即使是很少被 JOIN 的数据表亦然。
• 替常被查询或排序的字段建立索引，如：常被当作 WHERE 子句条件的字段。
• 用来建立索引的字段，长度不宜过长，不要用超过 20 个 Byte 的字段，如：地址。
• 不要替内容重复性高的字段建立索引，如：性别；反之，若重复性低的字段则适合建立索引，如：姓名。
• 不要替使用率低的字段建立索引，以免浪费硬盘空间。
• 不宜替过多字段建立索引，否则反而会影响到「INSERT、UPDATE、DELETE」的性能，尤其是以「OLTP (联机事务处理；在线交易)」为主的网站数据库。
• 若数据表存放的数据很少，就不必刻意建立索引。否则可能数据库沿着存放索引的「树状结构」(Balanced
Tree) 去搜寻索引中的数据，反而比扫描整个数据表还慢。
• 若查询时符合条件的数据很多，则透过「非集簇索引 (non-clustered
index)」搜寻的性能，反而 可能不如整个数据表逐笔扫描。
• 建立「集簇索引」的字段选择至为重要，会影响到整个索引结构的性能。要用来建立「集簇索引」的字段，务必选择「整数」类型
(键值会较小)、唯一、不可为 NULL。
------------------------------
3、适当地使用索引
• 有些书籍会提到，使用「LIKE、%」做模糊查询时，即使您已替某个字段建立索引
(如下方代码的 CustomerID 字段)，但以常量字符开头才会使用到索引，若以万用字符 (%) 开头则不会使用索引，如下所示：

USE Northwind; GO SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引 SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引

在 SQL Server 2005 执行完成后按
Ctrl + L，可检阅如下图的「执行计划」。



图 1　可看出「查询最佳化程序」有使用到索引做搜寻



图 2　在此的「集簇索引」扫描，并未直接使用索引，性能上几乎只等于扫描整个数据表
但经版工反复测试，这种语法是否会使用到索引，抑或会逐笔扫描，并非绝对的。仍要看所下的查询关键词，以及字段内 所存储的数据内容而定。但对于存储数据笔数庞大的数据表，最好还是少用
LIKE 做模糊查询。

• 以下的运算符会造成「负向查询」，常会让「查询最佳化程序」无法有效地使用索引，最好能用其它运算符和语法改写 (经版工测试，并非有负向运算符，就绝对无法使用索引)：

NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE
• 避免让 WHERE 子句中的字段，去做字符串的串接或数字运算，否则可能导致「查询最佳化程序」无法直接使用索引，而改采「集簇索引扫描」(经版工测试并非绝对)。
• 数据表中的数据，会依照「集簇索引」字段的顺序存放，因此当您下 BETWEEN、GROUP BY、ORDER BY 时若有包含「集簇索引」字段，由于数据已在数据表中排序好，因此可提升查询速度。
• 若使用「复合索引」，要注意索引顺序上的第一个字段，才适合当作过滤条件。
------------------------------
4、避免在 WHERE 子句中对字段使用函数
对字段使用函数，也等于对字段做运算或串接的动作，一样可能会让「查询最佳化程序」无法有效地使用索引。但真正对性能影响最重大的，是当您的数据表内若有
10 万笔数据，则在查询时就需要呼叫函数 10 万次，这点才是真正的性能杀手。程序员应注意，在系统开发初期可能感觉不出差异，但当系统上线且数据持续累积后，这些语法细节所造成的性能问题就会逐步浮现。

SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7 可改成 SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'

SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D' 可改成 SELECT * FROM Orders WHERE CustomerID LIKE 'D%'

注意当您在下 UPDATE、DELETE 语句时，若有采用 WHERE 子句，也应符合上述原则。。
------------------------------
5、AND 与 OR 的使用
在 AND 运算中，「只要有一个」条件有用到索引
(如下方的 CustomerID)，即可大幅提升查询速度，如下图 3 所示：

SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，会出现下图 3 的画面

SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，会出现上图 2 的画面

图 3

但在 OR 运算中，则要「所有的」条件都有可用的索引，才能使用索引来提升查询速度。因此 OR
运算符的使用必须特别小心。
若您将上方 AND 的范例，逻辑运算符改成 OR 的话，如下所示：

SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800

由于无法有效地使用索引，也会出现图 2 的画面。
在使用 OR 运算符时，只要有一个条件 (字段) 没有可用的索引，则其它所有的条件
(字段) 都有索引也没用，只能如图 2 般，把整个数据表或整个集簇索引都扫描过，以逐笔比对是否有符合条件的数据。

据网络上文件的说法 [1]，上述的 OR 运算语句，我们还可用 UNION 联集适当地改善，如下：

SELECT * FROM Orders WHERE CustomerID='VINET' UNION SELECT * FROM Orders WHERE Freight=32.3800

此时您再按 Ctrl + L
检阅「执行计划」，会发现上半段的查询会使用索引，但下半段仍用集簇索引扫描，对性能不无小补。
------------------------------
6、适当地使用子查询
相较于「子查询 (Subquery)」，若能用 JOIN 完成的查询，一般会比较建议使用后者。原因除了 JOIN 的语法较容易理解外，在多数的情况下，JOIN
的性能也会比子查询较佳；但这并非绝对，也有的情况可能刚好相反。
我们知道子查询可分为「独立子查询」和「关联子查询」两种，前者指子查询的内容可单独执行，后者则无法单独执行，亦即外层查询的「每一次」查询动作都需要引用内层查询的数据，或内层查询的「每一次」查询动作都需要参考外层查询的数据。
以下我们看一个比较极端的例子 [2]。若我们希望所有查询出来的数据，都能另外给一个自动编号，版工我在之前的文章「ASP.NET
数据分页第一篇 - 探讨分页原理及 SQL Server 2005 的 ROW_NUMBER 函数」中有介绍过，可用 SQL Server 2005 中新增的 ROW_NUMBER 函数轻易地达成，且 ROW_NUMBER 函数还能再加上「分群 (PARTITION
BY)」等功能，而且执行性能极佳。



图 4　将 Orders 数据表的 830 笔数据都捞出来，并在右侧给一组自动编号

现在我们要如上图 4 般，将 Northwind 数据库中 Orders
数据表的 830 笔数据都捞出来，并自动给一组编号，若用 ROW_NUMBER 函数的写法如下所示，而且性能极佳，只要 2 ms (毫秒)，亦即千分之二秒。

SET STATISTICS TIME ON SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 编号 FROM dbo.Orders

但如果是传统的「子查询」写法，或
辅以 AS 关键词的「衍生数据表」的语法，写法必须如下 (拷贝后在 SQL Server 中实际可执行)：

SET STATISTICS TIME ON SELECT OrderID, (SELECT COUNT(*) FROM dbo.Orders AS 内圈 WHERE 内圈.OrderID <= 外圈.OrderID) AS 编号 FROM dbo.Orders AS 外圈 ORDER BY 编号

但这种旧写法，会像先前所提到的，外层 (外圈) 查询的「每一次」查询动作都需要引用内层 (内圈) 查询的数据。以上方示例而言，外层查询的每一笔数据，都要等内层查询「扫描整个数据表」并作比对和计数，因此
830 笔数据每一笔都要重复扫描整个数据表 830 次，所耗用的时间也因此爆增至 170 ms。
若您用相同的写法，去查询 AdventureWorks 数据库中，有 31,465 笔数据的 Sales.SalesOrderHeader 数据表，用 ROW_NUMBER
函数要 677 ms，还不到 1 秒钟；但用子查询的话，居然要高达 233,835 ms，将近快 4 分钟的时间。

-- 用 ROW_NUMBER 的写法，改查询 AdventureWorks 数据库 (31,465 笔数据，要 677 ms，还不到 1 秒钟) SELECT SalesOrderID, ROW_NUMBER() OVER(ORDER BY SalesOrderID) AS rownum FROM Sales.SalesOrderHeader

-- 用「子查询」的写法，改查询 AdventureWorks 数据库 (31,465 笔数据，要 233,835 ms，将近 4 分钟) SELECT SalesOrderID, (SELECT COUNT(*) FROM Sales.SalesOrderHeader AS 内圈 WHERE 内圈.SalesOrderID <= 外圈.SalesOrderID) AS 编号 FROM Sales.SalesOrderHeader AS 外圈 ORDER BY 编号

虽然这是较极端的范例，但由此可知子查询的撰写，在使用上不可不慎，尤其是「关联子查询」。程序员在系统开发初期、数据量还很少时感受不到此种
SQL 语法的重大陷阱；但等到系统上线几个月或一两年后，就会有反应迟缓的现象， 不可不慎。

注：AS 关键词及「衍生数据表」是 SQL Server 的语法，「衍生数据表」只会存在内存中，AS 关键词的作用是赋予一个别名。过去许多必须用暂存数据表或 View (视图)
的情况，现在都可以用「衍生数据表」来取代，如此一来不但可以降低数据库管理工作的负担，亦可提升查询性能。
------------------------------
7、其他查询技巧
• DISTINCT、ORDER BY 语法，会让数据库做额外的计算。此外「联集」的使用，若没有要剔除重复数据的需求，使用
UNION ALL 会比 UNION 更优，因为后者会加入类似 DISTINCT 的算法。
• 在 SQL Server 2005 中，存取数据库对象时，最好明确指定该对象的「结构描述 (Schema)」，也就是使用两节式的名称，如下方代码所示。否则若呼叫者的预设
Schema 不是 dbo，则 SQL Server 在执行时，会先寻找该使用者预设 Schema 所搭配的对象，找不到的话才会转而使用预设的 dbo，会多耗费寻找的时间。因此若要执行一个叫做 dbo.mySP1 的 Stored Procedure，应使用以下的两节式名称：

EXEC dbo.mySP1

------------------------------
8、尽可能用 Stored Procedure 取代应用程序直接存取数据表

Stored Procedure 除了经过事先编译、性能较好以外，亦可节省 SQL 语句传递的网络频宽，也方便商业逻辑的重复使用。再搭配自订函数和
View 的使用，将来若要修改数据表结构、重新切割或「反正规化」时亦较方便。
------------------------------
9、尽可能在数据来源层，就先过滤数据
使用 SELECT 语法时，尽量避免传回所有的数据至前端而不设定 WHERE 等过滤条件。虽然 ASP.NET 中 SqlDataSource、ObjectDataSource
控件的 FilterExpression 可再做筛选，GridView 控件的 SortExpression 可再做排序，但会多消耗掉数据库的系统资源、web server 的内存和网络频宽。最好还是在数据库和数据来源层，就先用 SQL 条件式或Stored
Procedure 筛选出所要的资料。有关这方面，网友们可参考版工我之前写的「ASP.NET 数据分页」系列的四篇帖子。
------------------------------

结论：

本文的观念，不管是写 SQL statement、Stored Procedure、自订函数或 View 皆然。本文只是挑出程序员较容易犯的 SQL 语法性能问题，以期能在短时间浏览过本文后，在写 ADO.NET 程序时能修正以往随兴的 SQL 语句撰写习惯。文中提到的几点，只不过是
SQL 语法性能议题的入门。市面上有很多更进阶的书籍，例如：「The
Art of SQL」、「SQL
Tuning」，亦有针对 Oracle 或 SQL Server 数据库撰写的 performance
tuning 相关书籍，有兴趣者可自行翻阅。

------------------------------------------------------------

------------------------------------------------------------

参考文件：
[1] SQL 查询最佳化 (网际乌托邦)：

http://www.ithome.com.tw/plog/index.php?op=ViewArticle&articleId=5421&blogId=620
------------------------------

参考书籍：
[2] SQL Server 2005 Performance Tuning 效能调校 (台湾书籍)：

作者：胡百敬、姚巧枚、刘承修

出版社：悦知出版社

http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789866761225&sid=41966
[3] SQL Server 2005 完全实战 (台湾书籍)：

作者：章立民

出版社：碁峰出版社

http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789861810454&sid=31975
------------------------------
相关文件：
[4] 台大医院数据库分割疏失，系统几近停摆 (ITHome)：

http://www.ithome.com.tw/itadm/article.php?c=43597
[5]] 当 DataGrid 遇见100 万笔资料：

http://blog.sina.com.tw/4907/article.php?pbgid=4907&entryid=3921
[6] ASP.NET 2.0 GridView 范例集 - 「4-8-4、GridView 的效能」：

http://blog.csdn.net/Code6421/archive/2007/12/22/1958167.aspx
[7] 有关开启页面时，一次加载数千笔数据的性能问题：

http://www.blueshop.com.tw:80/board/show.asp?subcde=BRD200709141021458MV

------------------------------



分类: SQL Server 效能調校, SQL
Server 程式開發

绿色通道： 好文要顶 关注我 收藏该文与我联系





WizardWu

关注 - 10

粉丝 - 237

荣誉：推荐博客
+加关注

2

0

(请您对文章做出评价)

« 上一篇：Custom
Control 开发 (1) - Organizing Your Custom Controls

» 下一篇：Chart
Controls 简介与下载点

posted on 2008-10-27 00:09 WizardWu 阅读(11820) 评论(41) 编辑 收藏

Feedback

#1楼 2008-10-27
00:18 Anders Cui

很不错，感谢分享！
支持(0)反对(0)



#2楼 2008-10-27
00:22 povy

字太小了~
支持(0)反对(0)



#3楼 2008-10-27
07:35 付博

学习～！

感觉TW地区的学风非常不错啊！
支持(0)反对(0)



#4楼 2008-10-27
08:54 StevenChennet

谢谢lz这么辛苦整理的资料
支持(0)反对(0)



#5楼 2008-10-27
08:59 工本

不错不错
支持(0)反对(0)



#6楼 2008-10-27
09:07 路人甲居然被人注册了[未注册用户]

对tw的同行的待遇比较感兴趣

-_-!!



#7楼[楼主] 2008-10-27
09:12 WizardWu

感谢各位的回复。

台湾的产业主要以电子产品代工、硬件代工为主，

写纯软件、网站程序不被重视，赚不了钱，只能刚好不饿死而已。

支持(0)反对(0)



#8楼 2008-10-27
09:38 U2U

页面在FF下现实不正常。。。正文字体偏小
支持(0)反对(0)



#9楼 2008-10-27
09:54 lola

支持这位台湾兄弟的文章，很有价值！
支持(0)反对(0)



#10楼 2008-10-27
10:29 代码乱了

不错的说
支持(0)反对(0)



#11楼 2008-10-27
10:46 IamV

不错,谢谢楼主,学习了.
支持(0)反对(0)



#12楼[楼主] 2008-10-27
10:56 WizardWu

尝试在 FrontPage 打完、排版完，才转贴上来，

没注意到在 FireFox 下的字体过小问题。

只好麻烦用 ff 的网友，暂时将 browser字体调大，

造成不便敬请见谅。

支持(0)反对(0)



#13楼 2008-10-27
11:28 戏水

身分证号码 是 文字数字字段 怎么 地址 也是 文字数字字段呢？
支持(0)反对(0)



#14楼 2008-10-27
12:07 萧七[未注册用户]

行文流畅，言之有物。谢谢楼主的经验分享。



#15楼[楼主] 2008-10-27
12:20 WizardWu

回 13 F，已修正:

>> 文字数据字段

已改为「文字字段」

原本是指「文字 Data Column」

繁体中文的「資料」，用软件翻译成简体中文会变成「数据」

支持(0)反对(0)



#16楼 2008-10-27
12:45 Kevin-moon

学习了 呵呵
支持(0)反对(0)



#17楼 2008-10-27
13:56 andy.wu

收藏之。
支持(0)反对(0)



#18楼 2008-10-27
15:09 chenleinet

where 中能使用函数吗，还有as这个东西，早就有了吧
支持(0)反对(0)



#19楼 2008-10-27
15:27 南桥一梦

习惯了ORM工具。。。。。不了解这些
支持(0)反对(0)



#20楼 2008-10-27
15:40 NeilChen

nice article. thank you.
支持(0)反对(0)



#21楼 2008-10-27
20:31 巴山游子

非常好，谢谢分享！
支持(0)反对(0)



#22楼[楼主] 2008-10-27
20:43 WizardWu

回应 18 楼，

下午找到一台旧的 SQL Server 2000，证实「衍生数据表 + AS 关键词」确实如您所言，在 SQL Server 2000 即可执行。

书上写错，说是最新的语法，我跟着抄也抄错。

另本帖的 SQL statement 拷贝后，粘贴至 SQL Server 后，都可执行无误。

支持(0)反对(0)



#23楼 2008-12-07
19:15 明星程序员之魔者侠情

LZ,我们也对台湾同行的工资比较感兴趣，

能不能向大家透露一下，

你月薪多少台币？
支持(0)反对(0)



#24楼 2009-01-03
22:27 zagelover

不错，学习了！
支持(0)反对(0)



#25楼 2009-01-04
11:04 为理想而努力

感谢楼主分享，学习了！
支持(0)反对(0)



#26楼[楼主] 2009-01-04
12:38 WizardWu

在此推荐一位台湾资深 SQL Server/.NET 高手 - 胡百敬，及他写的 SQL Server 书籍。

他曾是唯一代表台湾地区，到美国微软参加 SQL Server 2005 / 2008 发表会的数据库高手。

版工我日前看到他写的一本「SQL Server 2005 Performance Tuning性能调校」也有简体中文版的 :

电子工业出版社, ISBN：978-7-121-06296-4

http://www.china-pub.com/39978

http://space.itpub.net/1818400/viewspace-432950

建议不论是 DBA 还是 .NET 程序员，该本书建议都人手一本，即使只花 30 分钟快速翻过，

也会对自己的 SQL 语句 / 数据库设计优化…等观念有所帮助。

他亦有写过一系列的 SQL Server 程序开发 / 商业智能 (BI) 书籍，但我不知是否有简体中文翻译本。

相关连结：

http://blog.csdn.net/softart/archive/2007/12/14/1935262.aspx

http://topic.csdn.net/t/20060623/17/4839786.html


支持(0)反对(0)



#27楼[楼主] 2009-01-05
23:33 WizardWu

楼主补充第 6 点 - 适当地使用子查询 (2009/01/05) :

子查询有分「关联子查询 (correlated subquery)」、「独立子查询」，前者应尽可能少用。

以下两句 SQL 语句功能相同，都是要找出每位客户最近一笔订单的日期。

前者每次处理一笔记录时，都会执行一次内部查询 (关联子查询)，有点类似双层循环 (loop)，

会导致性能大幅低落。

有经验的 SQL 程序员，会改用后者 JOIN + GROUP BY 的做法，因为这样做，不会执行任何内部查询，会比前者更有效率。

当两个数据表的记录笔数越多时，在较极端的情况下，性能的差距，可能就是不到一秒钟，和十几分钟的差别。

USE Northwind

go

SELECT CompanyName,

　　(SELECT MAX(OrderDate)

　　 FROM Orders

　　 WHERE Customers.CustomerID = Orders.CustomerID) AS 最近一笔订单日期

FROM Customers

ORDER BY CompanyName

USE Northwind

go

SELECT CompanyName, MAX(OrderDate) AS 最近一笔订单日期

FROM Customers

INNER JOIN Orders ON Customers.CustomerID = Orders.CustomerID

GROUP BY CompanyName

ORDER BY CompanyName

支持(0)反对(0)



#28楼 2009-01-07
15:29 kevin_chen[未注册用户]

謝謝,受益良多.

下午就呆在你的部落格裏了.



#29楼 2009-09-22
09:41 咒语

真不错。 哈哈，有些我现在才知道！

支持(0)反对(0)



#30楼 2009-09-22
12:39 不死鸟之魂

关于最后一点“9、尽可能在数据来源层，就先过滤数据”就涉及到性能和架构的平衡问题了。

如果所有过滤操作都在数据层，效率当然会高，不够从架构分成上来说，就会显得比较混乱。
支持(0)反对(0)



#31楼[楼主] 2009-09-22
17:14 WizardWu

感谢两位的回复，和不死鸟提供的意见。
支持(0)反对(0)



#32楼 2009-11-18
19:31 鹰翱星空

不错，LZ辛苦了，学习ing
支持(0)反对(0)



#33楼[楼主] 2010-08-06
02:41 WizardWu

SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引

SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引，造成資料表掃描 (Table Scan)

SELECT * FROM Orders WHERE CustomerID LIKE '%D%'; --不使用索引，造成資料表掃描 (Table Scan)

以上的寫法，經我自己測試，即使是沒建索引的欄位，也會有明顯的效能差別。

「叢集索引掃描 (Clustered Index Scan)」和「資料表掃描 (Table Scan)」 幾近相同，沒有什麼效率可言。

執行計劃中的「索引搜尋 (index seek)」代表著 SQL Server 以垂直的方式使用索引，從 root 開始用高效率的二分搜尋法來找尋它要的資料；而

執行計劃中的「索引掃描 (index scan)」代表著 SQL Server 以水平的方式使用索引，逐筆掃描整個索引的層級。

--------------------------------------

以下的運算子，不會影響 SQL Server 的查詢最佳化功能，透過索引 (二分搜尋法)，以最佳化的方式執行搜尋，而不用逐筆掃描所有的資料 :

= < > >= <= BETWEEN

以下的「負向」運算子，可能會影響 SQL Server 的查詢最佳化功能，「可能」造成無法用索引做二分搜尋，只好逐筆掃描所有的資料 :

NOT != <> !> !< NOT EXISTS NOT IN NOT LIKE

--------------------------------------

小心使用 OR 運算子

在 AND 運算中，只要一個欄位有合適的索引，就可大幅提升查詢的速度，如下 (假設 charge 資料表只有 id 欄位有設索引) :

SELECT * FROM charge WHERE id=1 AND num=1

以上可透過索引，在大量的記錄中，快速找出符合的資料列；再在少量的記錄中，去過濾 num=1 的資料列。

但若使用的是 OR 運算子，則需要「所有」的欄位都有可用的索引，才能發揮索引的搜尋最佳化功能。在使用 OR 運算子時，若多個查詢條件中，

只要「任一個」欄位沒有合適的索引，則其他再多的欄位都有設索引也沒用。如下 :

SELECT * FROM charge WHERE id=1 OR num=1

上方，雖然 id 欄位有設索引，但觀看 SQL Server 執行計劃，仍是全資料表逐筆掃描。若再替 num 欄位也加上索引，才能透過索引，

讓 SQL Server 透過查詢最佳化功能，同時採用兩個索引做過濾和有效地查詢。

--------------------------------------

儘量避免對 WHERE 條件中的欄位，做「字串相加」或「數字運算」，如下 :

正確寫法 :

SELECT Title FROM Person.Contact

WHERE LastName='David' AND FirstName='Nancy'

不適寫法 (字串相加) :

SELECT Title FROM Person.Contact

WHERE LastName + ',' + FirstName='David,Nancy'

兩種不同的寫法，會有明顯的效能差異。前者可讓 SQL Server 的查詢最佳化功能，有效地使用 LastName 欄位上的索引；而後者因為

需要先經過運算或字串相加，才能知道資料是否符合，導致無法直接使用索引，因而改採用「叢集索引掃描 (Clustered Index Scan)」，沒什麼效率可言。

--------------------------------------

儘量避免在 WHERE 條件中，對欄位使用函數

同前一個原則，儘量避免對欄位做運算，對欄位使用函數也等於在對欄位做運算。否則若有 100 萬筆資料，就需要呼叫函數 100 萬次，這將是效能殺手。

如下的 SUBSTRING 函數，或其他 SQL Server 內建的 DATEPART 和 ABS 等各種函數 :

正確寫法 :

SELECT * FROM Employees WHERE LastName LIKE 'D%'

SELECT * FROM Employees WHERE LastName >= 'D' AND LastName < 'E'

不適寫法 (使用函數) :

SELECT * FROM Employees WHERE SUBSTRING(LastName, 1, 1) = 'D'

--------------------------------------

索引的其他提示 :

* 索引建少了，用 WHERE 查詢資料較無效率；但索引建多了，會不利於新增、修改、刪除等維護資料的動作，因這些動作都要連帶立即更新所有相關的索引，另也浪費硬碟空間。

* 當符合 WHERE 條件的記錄，佔總紀錄筆數不小的比例時，透過「非叢集索引」來查詢，仍然是非常沒有效率的(有時甚至比逐筆掃描還慢)，甚至根本不會使用我們所建立的非叢

集索引。

* 當設定「叢集索引」的欄位，裡面擺放的值過大，會導致整個資料表的各種索引、非叢集索引都變得沒有效率 (因為所有的「非叢集索引」裡都會存一份「叢集索引」的鍵值

(key))。因此「叢集索引」應選擇內容存放為整數(非字串)、本身為唯一、不可為 NULL…等。

* SQL Server 裡就算存有上億筆的資料，透過設計良好的索引，仍可在一瞬間找到所要的資料。

* 由於資料表中的記錄，是按照「叢集索引」欄位的順序擺放，因此當您在下 BETWEEN、GROUP BY、ORDER BY 時，若能包含「叢集索引」的欄位，由於記錄已在資料表中排序好，

將可提升查詢速度。

--------------------------------------

--------------------------------------

參考書籍 (台灣書籍，但這本有簡體中譯本) :

SQL Server 2005 Performance Tuning 效能調校

http://tlsj.tenlong.com.tw/WebModule/BookSearch/bookSearchViewAction.do?isbn=9789866761225&sid=41966

作者部落格 :

http://byronhu.spaces.live.com/

--------------------------------------

支持(0)反对(0)



#34楼[楼主] 2010-08-14
01:57 WizardWu

英文、简体中文、繁体中文 IT 词汇对照表 :

http://files.cnblogs.com/WizardWu/080708.zip

支持(0)反对(0)



#35楼 2011-01-18
18:46 助平君

Good Post!
支持(1)反对(0)



#36楼[楼主] 2011-01-18
23:00 WizardWu

thanks 助平君.
支持(0)反对(0)



#37楼 2011-07-28
12:01 阿K&LiveCai

不错，好文章。推荐++
支持(1)反对(0)



#38楼[楼主] 2013-03-19
00:38 WizardWu

調校前端軟體 (Java、.NET、Borland) 使用，強化 SQL Server 效能:

http://www.microsoft.com/taiwan/technet/columns/profwin/strengthsql.mspx
支持(0)反对(0)



#39楼 2013-10-31
17:00 安乐js

学习了.
支持(1)反对(0)



#40楼 2014-04-17
10:14 owen zeng

厉害！
支持(0)反对(0)



#41楼[楼主] 2014-04-17
15:41 WizardWu

thanks owen zeng