由于数据库领域仍相对不成熟，每个平台上的 SQL 开发人员都在苦苦挣扎，一次又一次犯同样的错误。当然，数据库厂商在取得一些进展，并继续在竭力处理较重大的问题。
无论 SQL 开发人员在 SQL Server、Oracle、DB2、Sybase、MySQL，还是在其他任何关系数据库平台上编写代码，并发性、资源管理、空间管理和运行速度都仍困扰着他们。
问题的一方面是，不存在什么灵丹妙药;针对几乎每条最佳实践，我都可以举出至少一个例外。
我们说调优数据库既是门艺术，又是门科学，这是有道理的，因为很少有全面适用的硬性规则。你在一个系统上解决的问题在另一个系统上不是问题，反之亦然。
说到调优查询，没有正确的答案，但这并不意味着就此应该放弃。你可以遵循以下一些原则，有望收到很好的效果。
不要用 UPDATE 代替 CASE
这个问题很常见，却很难发觉，许多开发人员常常忽视这个问题，原因是使用 UPDATE 再自然不过，这似乎合乎逻辑。
以这个场景为例：你把数据插入一个临时表中，如果另一个值存在，需要它显示某个值。
也许你从 Customer 表中提取记录，想把订单金额超过 100000 美元的客户标记为“Preferred”。
因而，你将数据插入到表中，运行 UPDATE 语句，针对订单金额超过 100000 美元的任何客户，将 CustomerRank 这一列设为“Preferred”。
问题是，UPDATE 语句记入日志，这就意味着每次写入到表中，要写入两次。
解决办法：在 SQL 查询中使用内联 CASE 语句，这检验每一行的订单金额条件，并向表写入“Preferred”标记之前，设置该标记，这样处理性能提升幅度很惊人。
不要盲目地重用代码
这个问题也很常见，我们很容易拷贝别人编写的代码，因为你知道它能获取所需的数据。
问题是，它常常获取过多你不需要的数据，而开发人员很少精简，因此到头来是一大堆数据。
这通常表现为 WHERE 子句中的一个额外外连接或额外条件。如果你根据自己的确切要求精简重用的代码，就能大幅提升性能。
需要几列，就提取几列
这个问题类似第 2 个问题，但这是列所特有的。很容易用 SELECT* 来编写所有查询代码，而不是把列逐个列出来。
问题同样是，它提取过多你不需要的数据，这个错误我见过无数次了。开发人员对一个有 120 列、数百万行的表执行 SELECT* 查询，但最后只用到其中的三五列。
因此，你处理的数据比实际需要的多得多，查询返回结果是个奇迹。你不仅处理过多不需要的数据，还夺走了其他进程的资源。
不要查询两次(double-dip)
这是我看到好多人犯的另一个错误：写入存储过程，从一个有数亿行的表中提取数据。
开发人员想提取住在加利福尼亚州，年收入高于 4 万美元的客户信息。于是，他查询住在加利福尼亚州的客户，把查询结果放到一个临时表中。
然后再来查询年收入高于 4 万美元的客户，把那些结果放到另一个临时表中。最后他连接这两个表，获得最终结果。
你是在逗我吧?这应该用一次查询来完成，相反你对一个超大表查询两次。别犯傻了：大表尽量只查询一次，你会发现存储过程执行起来快多了。
一种略有不同的场景是，某个过程的几个步骤需要大表的一个子集时，这导致每次都要查询大表。
想避免这个问题，只需查询这个子集，并将它持久化存储到别处，然后将后面的步骤指向这个比较小的数据集。
知道何时使用临时表
这个问题解决起来要麻烦一点，但效果显著。在许多情况下可以使用临时表，比如防止对大表查询两次。还可以使用临时表，大幅减少连接大表所需的处理能力。
如果你必须将一个表连接到大表，该大表上又有条件，只需将大表中所需的那部分数据提取到临时表中，然后再与该临时表连接，就可以提升查询性能。
如果存储过程中有几个查询需要对同一个表执行类似的连接，这同样大有帮助。
预暂存数据
这是我最爱聊的话题之一，因为这是一种经常被人忽视的老方法。
如果你有一个报表或存储过程(或一组)要对大表执行类似的连接操作，通过提前连接表，并将它们持久化存储到一个表中来预暂存数据，就可以对你大有帮助。
现在，报表可以针对该预暂存表来运行，避免大连接。你并非总是可以使用这个方法，但一旦用得上，你会发现这绝对是节省服务器资源的好方法。
请注意：许多开发人员避开这个连接问题的做法是，将注意力集中在查询本身上，根据连接创建只读视图，那样就不必一次又一次键入连接条件。
但这种方法的问题是，仍要为需要它的每个报表运行查询。如果预暂存数据，你只要运行一次连接(比如说报表前 10 分钟)，别人就可以避免大连接了。
你不知道我有多喜欢这一招，在大多数环境下，有些常用表一直被连接起来，所以没理由不能先预暂存起来。
批量删除和更新
这是另一个经常被忽视的技巧，如果你操作不当，删除或更新来自大表的大量数据可能是一场噩梦。
问题是，这两种语句都作为单一事务来运行。如果你需要终结它们，或者它们在执行时系统遇到了问题，系统必须回滚(roll back)整个事务，这要花很长的时间。
这些操作在持续期间还会阻塞其他事务，实际上给系统带来了瓶颈，解决办法就是，小批量删除或更新。
这通过几个方法来解决问题：
无论事务因什么原因而被终结，它只有少量的行需要回滚，那样数据库联机返回快得多。
小批量事务被提交到磁盘时，其他事务可以进来处理一些工作，因而大大提高了并发性。
同样，许多开发人员一直固执地认为：这些删除和更新操作必须在同一天完成。事实并非总是如此，如果你在归档更是如此。
如果你需要延长该操作，可以这么做，小批量有助于实现这点;如果你花更长的时间来执行这些密集型操作，切忌拖慢系统的运行速度。
使用临时表来提高游标性能
如果可能的话，最好避免游标。游标不仅存在速度问题，而速度问题本身是许多操作的一大问题，还会导致你的操作长时间阻塞其他操作，这大大降低了系统的并发性。
然而无法总是避免使用游标，避免不了使用游标时，可以改而对临时表执行游标操作，以此摆脱游标引发的性能问题。
不妨以查阅一个表，基于一些比较结果来更新几个列的游标为例。你也许可以将该数据放入临时表中，然后针对临时表进行比较，而不是针对活动表进行比较。
然后你可以针对小得多，锁定时间很短的活动表运行单一的 UPDATE 语句。
进行这样的数据修改可大大提高并发性。最后我要说，你根本不需要使用游标，总是会有一种基于集合的解决方法。
使用表值函数
这是一直以来我最爱用的技巧之一，因为它是只有专家才知道的那种秘诀。
在查询的 SELECT 列表中使用标量函数时，该函数因结果集中的每一行而被调用，这会大幅降低大型查询的性能。
然而可以将标量函数转换成表值函数，然后在查询中使用 CROSS APPLY，就可以大幅提升性能，这个奇妙的技巧可以显著提升性能。
不要对同一批次的许多表执行大型操作
这个似乎很明显，但实则不然。我会用另一个鲜活的例子，因为它更能说明问题。
我有一个系统存在大量的阻塞，众多操作处于停滞状态。结果查明，每天运行几次的删除例程在删除显式事务中 14 个表的数据。处理一个事务中的所有 14 个表意味着，锁定每个表，直到所有删除完成。
解决办法就是，将每个表的删除分解成单独的事务，以便每个删除事务只锁定一个表。
这解放了其他表，缓解了阻塞，让其他操作得以继续运行。你总是应该把这样的大事务分解成单独的小事务，以防阻塞。
不要使用触发器
这个与前一个大体一样，但还是值得一提。触发器的问题：无论你希望触发器执行什么，都会在与原始操作同一个的事务中执行。
如果你写一个触发器，以便更新 Orders 表中的行时将数据插入到另一个表中，会同时锁定这两个表，直到触发器执行完毕。
如果你需要在更新后将数据插入到另一个表中，要将更新和插入放入到存储过程中，并在单独的事务中执行。
如果你需要回滚，就很容易回滚，不必同时锁定这两个表。与往常一样，事务要尽量短小，每次不要锁定多个资源。
不要在 GUID 上聚类
这么多年后，我难以相信我们居然还在为这个问题而苦恼。但我仍然每年遇到至少两次聚类 GUID。
GUID(全局唯一标识符)是一个 16 字节的随机生成的数字。相比使用一个稳定增加的值(比如 DATE 或 IDENTITY)，按此列对你表中的数据进行排序导致表碎片化快得多。
几年前我做过一项基准测试，我将一堆数据插入到一个带聚类 GUID 的表中，将同样的数据插入到另一个带 IDENTITY 列的表中。
GUID 表碎片化极其严重，仅仅过了 15 分钟，性能就下降了几千个百分点。
5 小时后，IDENTITY 表的性能才下降了几个百分点，这不仅仅适用于 GUID，它适用于任何易失性列。
如果只需查看数据是否存在，就不要计数行
这种情况很常见，你需要查看数据存在于表格中，根据这番检查的结果，你要执行某个操作。
我经常见到有人执行 SELECT COUNT(*)FROMdbo.T1来检查该数据是否存在：
SET @CT=(SELECT COUNT(*) FROM
dbo.T1);
If@CT>0
BEGIN
END
这完全没必要，如果你想检查数据是否存在，只要这么做：
If EXISTS (SELECT 1 FROM dbo.T1)
BEGIN
END
不要计数表中的一切，只要取回你找到的第一行。SQL Server 聪明得很，会正确使用 EXISTS，第二段代码返回结果超快。
表越大，这方面的差距越明显。在你的数据变得太大之前做正确的事情。调优数据库永不嫌早。
实际上，我只是在我的其中一个生产数据库上运行这个例子，针对一个有 2.7 亿行的表。
第一次查询用时 15 秒，包含 456197 个逻辑读取，第二次查询不到 1 秒就返回结果，只包含 5 个逻辑读取。
然而如果你确实需要计数表的行数，表又很大，另一种方法就是从系统表中提取，
SELECT rows fromsysindexes 将为你获得所有索引的行数。
又由于聚类索引代表数据本身，所以只要添加 WHERE indid = 1，就能获得表行，然后只需包含表名称即可。
所以，最后的查询是：
SELECT rows from sysindexes where object_name(id)='T1'and indexid =1
在我 2.7 亿行的表中，不到 1 秒就返回结果，只有 6 个逻辑读取，现在性能不一样了。
不要进行逆向搜索
以简单的查询 SELECT * FROMCustomers WHERE RegionID <> 3 为例。你不能将索引与该查询结合使用，因为它是逆向搜索，需要借助表扫描来逐行比较。如果你需要执行这样的任务，可能发现如果重写查询以使用索引，性能会好得多。
该查询很容易重写，就像这样：
SELECT * FROM Customers WHERE RegionID<3 UNION ALL SELECT * FROM Customers WHERE RegionID
这个查询将使用索引，所以如果你的数据集很大，其性能会远胜过表扫描版本。
当然，没有什么是那么容易的，也许性能更糟，所以使用之前先试一下。它百分之百管用，虽然涉及太多的因素。
最后，我意识到这个查询违反了第 4 条规则：不要查询两次，但这也表明没有硬性规则。虽然我们在这里查询两次，但这么做是为了避免开销很大的表扫描。
你无法一直运用所有这些技巧，但如果牢记它们，有一天你会用它们来解决一些大问题。
要记住的最重要一点是，别将我说的话当成教条。在你的实际环境中试一下，同样的解决办法不是在每种情况下都管用，不过我排查糟糕的性能时一直使用这些方法，而且屡试不爽。
本文转自微信公众号：ITPUB 公众号id：itpuber
