我正在进行DW项目,在这个项目中我需要查询实时的CRM系统。标准隔离级别对性能有负面影响。我想使用no lock/事务隔离级别read uncommitted。我想知道有多少被选定的行是由脏读所识别的。
我正在进行DW项目,在这个项目中我需要查询实时的CRM系统。标准隔离级别对性能有负面影响。我想使用no lock/事务隔离级别read uncommitted。我想知道有多少被选定的行是由脏读所识别的。
SELECT * FROM T WITH (SNAPSHOT)
EXCEPT
SELECT * FROM T WITH (READCOMMITTED, READPAST)
但这本质上是有风险的。
为什么需要知道这个?
你使用 TRANSACTION ISOLATION LEVER READ UNCOMMITTED
只是为了表明 SELECT
语句不会等待任何更新/插入/删除事务在表/页/行上完成 - 并且将获取甚至是 脏数据 的记录。而你这样做是为了提高性能。试图获取关于哪些记录是脏的信息就像往你的脸上打搅拌机一样。它会伤害你,却并不能给你任何东西,只有痛苦。因为它们曾经是脏的,现在不是了。或者还是脏的?谁知道呢...
更新
现在来谈谈数据质量。
想象一下,你用类似以下查询读取脏数据:
SELECT *
FROM dbo.MyTable
WITH (NOLOCK)
例如,您已经通过id = 1
和name ='someValue'
获取了记录。然后您想要更新名称,将其设置为“anotherValue” - 所以您执行以下查询:
UPDATE dbo.MyTable
SET
Name = 'anotherValue'
WHERE id = 1
@@ROWCOUNT
以确保查询执行了它应该执行的操作,并警告用户结果。
无论如何,它取决于情况和数据的重要性。 如果数据必须是实时的 - 不要使用脏读。
标准隔离级别对性能有负面影响
那么为什么不解决这个问题呢?您知道脏读是不一致的读取, 因此不应使用它们。明显的答案是使用快照隔离。请阅读在SQL Server中实现快照或读取已提交的快照隔离:指南。
但实际上问题更深层次。为什么会出现阻塞?为什么读取会被写入阻塞?DW工作负载不应该放任于操作事务数据,这就是我们拥有ETL和OLAP产品的原因。考虑立方体、列存储、powerpivot等所有可以实现极快速DW和分析的好处。不要将分析型端到端扫描的负担加在业务操作数据库上,否则你只会遇到麻烦。