T-SQL动态查询（1）——简介

起因：

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

 

前言：

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

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

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

本文出处： http://blog.csdn.net/dba_huangzj/article/details/49928527

简介：

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

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

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

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

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

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

基础知识：

本文出处： http://blog.csdn.net/dba_huangzj/article/details/49928527

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

• 执行计