在庞大的业务系统背后,一定有数据库管理系统的支持。在现代以数据为中心的开发时代,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
–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后面没有区别,但是感觉两者职责不分,代码不够幽雅。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号

TechTarget
官方微博

TechTarget中国
作者
相关推荐
-
Linux支持的引入 推动了SQL Server 2016集成服务的发展
随着SQL Server的不断发展,集成服务也在发生相应的变化。在最新的SSIS更新中,增加Linux支持和SQL Server 2016升级向导。
-
Notre Dame对云端SQL Server性能基准的探索实践
确立SQL Server的性能基准,对于云端迁移来说是至关重要的第一步,一位来自于University of Notre Dame 的DBA表示,他正在试图通过数据库监控软件,找出SQL server的性能基准。
-
DBA必须掌握的数据库恢复管理技术
如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。
-
横向扩展SQL Server应用程序:提高工作负载的选项
SQL Server管理员面临的最大挑战之一就是扩展数据库以适应更为繁重的数据处理工作负载。然而事情越发复杂的是,虽然Microsoft提供了许多不同的SQL Server可扩展性选项,但它们并不都适合于每种情况。