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后面没有区别,但是感觉两者职责不分,代码不够幽雅。

    先写到这里,以后有更多经验,心得再来更新。如果你有更多经验,不妨民分享于我。谢谢。

posted on 2011-01-11 21:12  James.H.Fu  阅读(...)  评论(...编辑  收藏

导航