庞大的业务系统数据库管理T-SQL经验总结

 在庞大的业务系统背后，一定有数据库管理系统的支持。在现代以数据为中心的开发时代，SQL编程也显得尤为重要。下面总结下我最近SQL编程的一些经验：

1.SELECT查询要列出所有要查询的字段

2.注意UNION和UNION ALL的区别,在IN，OR，UNION ALL这三种方案中，UNION ALL的执行效率是最高的。

3.视图定义要尽量简单，最好不要包含业务逻辑。比如：在业务系统中，单据会有多种状态，那么在系统与系统交互的过程中，可能两边的状态码定义的不同，那么就需要映射。在这种场景下，强烈建议这种映射不要放在视图定义或SQL查询中，因为这会降低查询的性能。

4.表变量与临时表的选择。表变量会将数据存储在数据库服务的内存中，临时表会将数据存储在数据库服务器的磁盘上，会产生I/O，因此临时表消耗资料要多些，性能显示要差些。一般来说，建议采用表变量。如果数据量大（选取的字段多，有大字段，数据条目超过10W），又要连续使用多次的，建议用临时表。

5.在表变量上设计主键是有百益而无一害的，临时表上更应该设计主键了。设计主键主要是让数据有序存储，提高查询性能。

6.要把握INNER JOIN和LEFT/RIGHT JOIN的区别。选择好了可以使SQL很简洁高效。

7.EXISTS的效率比IN要好十倍的样子。下面三个版本的效果，V1<V2<V3。
--V1
DELETE FROM dbo.Master
WHERE TransactionNumber IN
(
SELECT OriginalTransactionNumber FROM dbo.MasterHistory WITH(NOLOCK)
)

--V2
DELETE FROM dbo.Master
WHERE EXISTS
(
SELECT 1 FROM dbo.MasterHistory b WITH(NOLOCK)
WHERE b.OriginalTransactionNumber=TransactionNumber
)

--V3
DELETE a
FROM dbo.Master a
INNER JOIN dbo.MasterHistory b WITH(NOLOCK)
ON a.TransactionNumber=b.OriginalTransactionNumber

8.WHERE筛选子句要以选择性高的放在前面，选择性低或没有选择性的放在后面。JOIN … ON中的连接条件中要避免左右两边字段的类型转换，比如a.ItemNumber是NCHAR(25),而b.ItemNumber是VARCHAR(25),这样会严重影响性能。解决方案是，一在设计阶段注意规范，二是可以临时在JOIN … ON子句中做显式类型转换。另外，WHERE是筛选子句，JOIN … ON是连接语句，把筛选子句写在JOIN … ON上与写在WHERE后面没有区别，但是感觉两者职责不分，代码不够幽雅。