概述
因为每天需要审核程序员发布的SQL语句，所以收集了一些程序员的一些常见问题，还有一些平时收集的其它一些问题，这也是很多人容易忽视的问题，在以后收集到的问题会补充在文章末尾，欢迎关注，由于收集的问题很多是针对于生产数据，测试且数据量比较大，这里就不把数据共享出来了，大家理解意思就行。
步骤
大写T-SQL 语言的所有关键字都使用大写，规范要求。
使用“;”作为 Transact-SQL 语句终止符。虽然分号不是必需的，但使用它是一种好的习惯,对于合并操作MERGE语句的末尾就必须要加上“;”
（cte表表达式除外）
避免使用ntext、text 和 image 数据类型，用 nvarchar(max)、varchar(max) 和 varbinary(max)替代
后续版本会取消ntext、text 和 image 该三种类型
---使用计算列查询（走的是索引扫描）
---不使用计算列（走的是索引查找）
对比两个查询显然绝大部分情况下走索引查找的查询性能要高于走索引扫描，特别是查询的数据库不是非常大的情况下，索引查找的消耗时间要远远少于索引扫描的时间，如果想详细了解索引的体系结构可以查看了我前面写的几篇关于聚集、非聚集、堆的索引体系机构的文章。
发现很多人在建表的时候不会注意这一点，在接下来的工作中当你需要查询数据的时候你往往需要在WHERE条件中多加一个判断条件IS NOT NULL,这样的一个条件不仅仅增加了额外的开销，而且对查询的性能产生很大的影响，有可能就因为多了这个查询条件导致你的查询变的非常的慢；还有一个比较重要的问题就是允许为空的数据可能会导致你的查询结果出现不准确的问题，接下来我们就举个例子讨论一下。
实际情况customerid=3是没有订单的，数量应该是0，但是结果是1,count()里面的字段是左连接右边的表字段，如果你用的是主表字段结果页是错误的。
大家发现下面语句有没有什么问题，查询结果是怎样呢？
正确查询结果下查询出的结果是没有customerid为3的值
为什么结果会这样呢？
大家仔细看应该会发现子查询的orders表中没有Customerid字段，所以SQL取的是Customer表的Customerid值作为相关子查询的匹配字段。
所以我们应该给子查询加上表别名，如果加上表别名，如果字段错误的话会有错误标示
正确的写法：
l 查询时一定不能使用”*”来代替字段来进行查询，无论你查询的字段有多少个，就算字段太多无法走索引也避免了解析”*”带来的额外消耗。
l 查询字段值列出想要的字段，避免出现多余的字段，字段越多查询开销越大而且可能会因为多列出了某个字段而引起查询不走索引。
创建测试数据库
创建索引
查询测试
由于建的索引‘IX1_Customer’没有包含ModifiedDate字段，所以需要通过键查找去聚集索引中获取该字段的值
由于查询语句中没有对ModifiedDate字段进行查询，所以只走索引查找就可以查询到需要的数据，所以建议在查询语句中列出你需要的字段而不是为了方便用*来查询所有的字段，如果真的
需要查询所有的字段也同样建议把所有的字段列出来取代‘*’。
减少网络通信量。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别，可是如果存储过程包含上百行SQL语句，那么其性能绝对比一条一条的调用SQL语句要高得多。
执行速度更快。有两个原因：首先，在存储过程创建的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程缓存计划，这样下次再执行同样的存储过程时，可以从内存中直接调用。
更强的适应性：由于存储过程对数据库的访问是通过存储过程来进行的，因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动，而这些改动不会对应用程序造成影响。
布式工作：应用程序和数据库的编码工作可以分别独立进行，而不会相互压制。
更好的封装移植性。
安全性，它们可以防止某些类型的 SQL 插入攻击。
理解TRUNCATE和DELETE的区别
TRUNCATE操作没有记录删除日志操作
主要的原因是因为TRUNCATE操作不会激活触发器,因为TRUNCATE操作不会记录各行的日志删除操作,所以当你需要删除一张表的数据时你需要考虑是否应该如有记录日志删除操作，而不是根据个人的习惯来操作。
事务的理解
1.简单的事务提交
2.TRY...CATCH
3.打开XACT_ABORT
当 SET XACT_ABORT 为 ON 时，如果执行 Transact-SQL 语句产生运行时错误，则整个事务将终止并回滚。
当 SET XACT_ABORT 为 OFF 时，有时只回滚产生错误的 Transact-SQL 语句，而事务将继续进行处理。如果错误很严重，那么即使 SET XACT_ABORT 为 OFF，也可能回滚整个事务。OFF 是默认设置。
编译错误（如语法错误）不受 SET XACT_ABORT 的影响。
所以我们应该根据自己的需求选择正确的事务。
你平时在写T_SQL语句的时候WHERE条件后面的字段的先后顺序你有注意吗？
如果这是你的写的查询语句
我现在根据你的查询语句创建一条索引
分别执行三条查询语句
执行计划分别为
从上面三天查询语句可以看出，只有第一条语句走的是索引查找，另外两条语句走的是索引扫描，而我们从字段的名称应该可以看的出OID字段应该是该表的一个外键字段也是经常会被用作查询的字段。
接下来我们重新换一下索引顺序
依然执行前面的三条查询语句分析执行计划
分析执行计划前面两条查询语句都走的是索引查找，第三条查询的是索引扫描，而根据一般单独用第三条查询的业务应该不会常见，所以现在一条索引解决了两个常用查询的索引需求，避免了建两条索引的必要（所以当你建索引的时候索引的顺序很重要，一般把查询最频繁的字段设第一个字段，可以避免建多余的索引）。
为什么要把这个问题提出来呢，因为平时有遇到程序员在写查询语句的时候对于同一个查询条件每次的写法都不一样，往往是根据自己想到哪个字段就写哪个字段先，这样的习惯往往是不好的，就好比上面的例子如果别人看到你的查询条件建一个索引也是这样写的话往往一个表会出现很多多余的索引（或许有人会说DBA建好索引的顺序就好了，这里把这个因素排除吧），像后面的那个索引就解决了两个查询的需求。
所以这里我一般是这样规定where条件的，对于经常用作查询的字段放在第一个位置（比如上面例子的OID）,其它的字段根据表的实际字段顺序排列，这样往往你的查询语句走索引的概率会更大。
看到这结果是不是有点疑惑，我在连接条件里面写了TA.stats<>'1'，为什么结果还会查询出。
接下来我们换一种写法吧！
接下来我就解释一下原因：对于外连接，连接条件不会改变主表的数据，即不会删减主表的数据
对于上面的查询主表是orders，所以无论你在连接条件on里面怎样设置主表的条件都不影响主表数据的输出，影响主表数据的输出只在where条件里，where条件影响最后数据的输出。而对于附表Customer 的条件就应该写在连接条件（on）里而不是where条件里，这里说的是外连接（包括左连接和右连接）。
对于inner join就不存在这种情况，无论你的条件是写在where后面还是on后面都是一样的，但是还是建议写在where后面。
1.谓词类型与字段类型不一致
由于定义表的phone字段类型是字符型，而上面的查询条件phone写成了整形，导致执行计划走了索引扫描，且执行计划select也有提示。
2.谓词类型与字段类型一致
第二种查询phone谓词类型与字段类型一致，所以查询走了索引查找
在日常的语句编写过程中需要注意这类问题，这将直接影响性能。
避免使用长字节字段排序
上面的语句查询结果是一样的，只是写法不一样，O.create_date是表的创建时间而object_id 是一个自增值根据两者的倒序排序得到的结果是一样的，但是二者的执行效率却不一样。无论是从执行时间还是执行计划明显是后者的效率要好，从执行计划可以看出后者的不需要进行排序操作因为object_id 本身就是排序好的，而且object_id 是整形而create_date是时间类型，如果是两个大表进行连接操作再进行排序效率更明显甚至前面用时间排序还可能查询很久不出来。
总结
后面收集到类似的问题会补充在文章的末尾，文章持续更新中....，欢迎关注讨论。
本文转自pursuer.chen(陈敏华)博客园博客，原文链接：http://www.cnblogs.com/chenmh/p/3999475.html，如需转载请自行联系原作者