?

起因：

由于最近工作需要及过去一直的疑问，所以决定着手研究一下动态SQL。由于离开一线开发有点年头了，很多技巧性的东西没有过多研究，作为DBA和《SQL Server性能优化与管理的艺术》一书的独立作者，更多的是关注在满足功能要求前提下的性能问题。但是我认为本文不仅对DBA有用，对数据库开发人员甚至设计师、架构师等都有一定的参考价值。

?

前言：

读者是否遇到过类似功能：一个应用程序（不管是B/S还是C/S结构），有某个/些功能，允许用户选择不同的条件来进行查询（为了简便期间，这里仅针对查询功能）。极端情况下，用户可以通过界面选择结果集的不同的展示列、列展示顺序、排序形式甚至二次查询等。这些功能使用前端编程语言实现未尝不可，有时候甚至更佳，但是前端实现毕竟需要后台数据库的支持，所以这里更加集中在数据库层面。

上面的例子中，用户看到的可能就是这样，但是作为一个开发人员，你需要考虑的东西就不仅仅是这些了，假设我们使用存储过程来实现这个功能的数据支持，那么你需要考虑的是：不同的查询条件可能需要关联不同的表，比如需要同时筛选日期和货号，这两个条件是分布在A、B两表，那么你在查询时就要进行关联。但是当用户选择筛选货号和客户名时，这些数据可能分布在B、C两表，那么你需要在同一个存储过程中进行B、C表的关联。

由于关系数据库理论的限制，你很难做到灵活构建这种逻辑的同时保持代码的简洁及高效。除了用游标加大量判断这种几乎能实现任何功能但又往往极其低效的方式之外，动态SQL就出现在我们的考虑范围里面。我们需要借助某些工具来实现两个目的：得到正确数据和获得合理的性能。

简介：

在现代信息系统中，上面的例子广泛存在。但是随之引发的一个核心问题是：在SQL Server（估计在所有RDBMS中均是），没有一个单一的执行计划可以很好地支持所有的可能的查询条件。同时你也希望SQL Server针对用户的输入进行优化。

通常在数据库层面实现这种要求的方式有两种：

1． 编写带有查询提示（如OPTION(RECOMPILE)）的静态SQL，强制SQL Server每次都对查询进行编译。

2． 使用动态SQL 创建一个可以覆盖用户定义的查询条件的字符串并执行语句。

这两种方式都有适用常见，各有优缺点，不能简单地说哪个好哪个不好，本系列文章将介绍两类的相关内容。

注意：本系列将使用SQL 2008 R2并用微软示例数据库AdventureWorks2008 R2作为演示。

基础知识：

为了让读者有一些知识准备，本问先介绍一些基础知识，这些基础知识有：

注：为了控制文章的篇幅，本系列文章不打算深入探讨上面的知识，更详细的信息可查阅本人书籍《SQL Server性能优化与管理的艺术》中相关信息。

执行计划：

当一个SQL语句（SQL语句/批 或存储过程）提交给SQL Server之后，SQL Server会先分析语句的语法，若不符合要求马上停止后续操作并返回错误信息给客户端。

当SQL语句语法分析通过之后，SQLServer会根据语句的文本在内存的计划缓存中（Plan Cache，属于内存的Buffer Pool一部分）查找是否有可用的执行计划，若有，则直接执行，若无，则进行编译阶段。编译后生成执行计划提交给存储引擎进行执行并缓存。大概流程如下：

?

执行计划是性能的核心之一，存储引擎根据执行计划访问和返回数据给客户端，好的执行计划能高效、快速地完成数据请求，而不合理的执行计划会使一个本来很简单的请求的运行时间从几秒上升到数小时。而且执行计划也是分析性能问题的核心工具。在SQL Server Management Studio（SQL 2000叫查询分析器，SQL2005开始简称SSMS），查看执行计划可以通过快捷键：Ctrl+M（实际执行计划）和Ctrl+L（预估执行计划）来获取，也可以通过图形化界面中的下图来获取：

?

执行计划缓存：

在SQL Server优化器对语句进行编译和优化之后，提交给存储引擎执行，随即把执行计划缓存到内存的Plan Cache中以便后续重用。

计划缓存的最重要的目的是为了减少不必要的编译和重编译，这两个操作在负载很大的系统中会带来明显的CPU压力。如果在一个一秒钟某个存储过程会被调用超百次的系统中，避免一个只需要5ms的编译过程，可以使存储过程的执行计划从5分钟降到100ms。

另外计划缓存与语句的文本有密切关系，后续会介绍，对于下面两个语句，他们的执行计划是可以被重用的：

?

SELECT ID,A,B FROM TB WHERE ID=1
SELECT ID,A,B FROM TB WHERE ID=10

?

但是下面两个语句会被认为两个不同的语句，导致第二个语句被认为新语句而进行编译，通常会导致性能问题和资源浪费：

?

SELECT ID,A,BFROM TB WHERE ID=1
SELECT ID,A,B FROM     TB WHERE ID=10  --注意空格

?

对于这类问题，通常的解决方案是合理的编码规范和使用参数化查询，后续将介绍。

另外，计划缓存有先进先存的特性，假设下面一个存储过程：

?

CREATEPROC TEST (@ID INT)
AS
  SELECT ID,A,B FROM TB WHERE ID=@ID
GO

同时假设表TB上ID列的数据分布极其不均匀，比如ID=1的数据在列上占了90%，而ID=10的数据在列上只有0.01%，数据行超百万，并且有合适的索引支持。在这种情况下，针对ID=1的查询，合理的应该是进行索引扫描，而对于ID=10的查询，合理的应该是索引查找。当第一次运行存储过程并以@ID=1为参数时，执行计划按索引扫描的方式产生并缓存，这是对的。但是当第二次执行是以@ID=10为参数时，可能因为某些原因执行计划被重用，依旧使用索引扫描方式，此时你可能会明显感觉到性能降低。这种情况反之亦然。关于这个情况在后续会整理一个关于参数嗅探的系列文章中详述。

最后，计划缓存是在内存中，也就是说，它是不稳定的，重启服务/服务器或某些命令和操作都可能导致计划被刷出内存。如有必要可以定期收集并存储在专门的监控数据库中或把执行计划另存为文件。

?

统计信息：

统计信息是一个描述表数据的“表”，简单来说就是描述数据的数据。我们常说的数据分布，对于SQL Server来说，就是存储在统计信息中。统计信息可以是自动创建或者手动创建的，并且通常在索引创建时就会附带创建对应的统计信息。关于统计信息的详述可见《SQL Server性能优化与管理的艺术》第六章。

统计信息也是性能优化的核心，SQLServer在分析语句语法之后，会根据统计信息的内容，选择执行计划中使用什么索引及表关联的算法，统计信息的过时和不准确会严重影响执行计划生成和服务器的整体性能。

同时，在优化过程中，如果统计信息足够准确，优化器可以通过判断数据是否有需要关联从而避免不必要的表关联。系列文章的后续部分也会做演示。

提醒：现行统计信息的算法最晚从SQL2000开始沿用至今，但是从SQL 2014开始做了大改动，算法更加合理，所以如有条件，建议使用SQL 2014或后续版本。

?

参数嗅探：