在前面我们介绍了如何正确使用索引，调整索引是见效最快的性能调优方法，但一般而言，调整索引 只会提高查询性能。除此之外，我们还可以调整数据访问代码和TSQL，本文就介绍如何以最优的方法重构 数据访问代码和TSQL。
第四步：将TSQL代码从应用程序迁移到数据库中
也许你不喜欢我的这个建议，你或你的团队可能已经有一个默认的潜规则，那就是使用ORM(Object Relational Mapping，即对象关系映射)生成所有SQL，并将SQL放在应用程序中，但如果你要优化数据访 问性能，或需要调试应用程序性能问题，我建议你将SQL代码移植到数据库上(使用存储过程，视图，函数 和触发器)，原因如下：
1、使用存储过程，视图，函数和触发器实现应用程序中SQL代码的功能有助于减少应用程序中SQL复制 的弊端，因为现在只在一个地方集中处理SQL，为以后的代码复用打下了良好的基础。
2、使用数据库对象实现所有的TSQL有助于分析TSQL的性能问题，同时有助于你集中管理TSQL代码。
3、将TS QL移植到数据库上去后，可以更好地重构TSQL代码，以利用数据库的高级索引特性。此外， 应用程序中没了SQL代码也将更加简洁。
虽然这一步可能不会象前三步那样立竿见影，但做这一步的主要目的是为后面的优化步骤打下基础。 如果在你的应用程序中使用ORM(如NHibernate)实现了数据访问例行程序，在测试或开发环境中你可能发 现它们工作得很好，但在生产数据库上却可能遇到问题，这时你可能需要反思基于ORM的数据访问逻辑， 利用TSQL对象实现数据访问例行程序是一种好办法，这样做有更多的机会从数据库角度来优化性能。
我向你保证，如果你花1-2人月来完成迁移，那以后肯定不止节约1-2人年的的成本。
OK!假设你已经照我的做的了，完全将TSQL迁移到数据库上去了，下面就进入正题吧!
第五步：识别低效TSQL，采用最佳实践重构和应用TSQL
由于每个程序员的能力和习惯都不一样，他们编写的TSQL可能风格各异，部分代码可能不是最佳实现 ，对于水平一般的程序员可能首先想到的是编写TSQL实现需求，至于性能问题日后再说，因此在开发和测 试时可能发现不了问题。
也有一些人知道最佳实践，但在编写代码时由于种种原因没有采用最佳实践，等到用户发飙的那天才 乖乖地重新埋头思考最佳实践。
我觉得还是有必要介绍一下具有都有哪些最佳实践。
1、在查询中不要使用“select *”
(1)检索不必要的列会带来额外的系统开销，有句话叫做“该省的则省”;
(2)数据库不能利用“覆盖索引”的优点，因此查询缓慢。
2、在select清单中避免不必要的列，在连接条件中避免不必要的表
(1)在select查询中如有不必要的列，会带来额外的系统开销，特别是LOB类型的列;
(2)在连接条件中包含不必要的表会强制数据库引擎检索和匹配不需要的数据，增加了查询执行时间。
3、不要在子查询中使用count()求和执行存在性检查
(1)不要使用
SELECT column_list FROM table WHERE 0 < (SELECT count(*) FROM table2 WHERE ..)
使用
SELECT column_list FROM table WHERE EXISTS (SELECT * FROM table2 WHERE ...)
代替;
(2)当你使用count()时，SQL Server不知道你要做的是存在性检查，它会计算所有匹配的值，要么会 执行全表扫描，要么会扫描最小的非聚集索引;
(3)当你使用EXISTS时，SQL Server知道你要执行存在性检查，当它发现第一个匹配的值时，就会返回 TRUE，并停止查询。类似的应用还有使用IN或ANY代替count()。
4、避免使用两个不同类型的列进行表的连接
(1)当连接两个不同类型的列时，其中一个列必须转换成另一个列的类型，级别低的会被转换成高级别 的类型，转换操作会消耗一定的系统资源;
(2)如果你使用两个不同类型的列来连接表，其中一个列原本可以使用索引，但经过转换后，优化器就 不会使用它的索引了。例如：
SELECT column_list FROM small_table, large_table WHERE
smalltable.float_column = large_table.int_column
在这个例子中，SQL Server会将int列转换为float类型，因为int比float类型的级别低， large_table.int_column上的索引就不会被使用，但smalltable.float_column上的索引可以正常使用。