小编Ser*_*ook的帖子

我认为我可以提出问题的最佳方式是从一个例子开始。

想象一下这两个查询：

SELECT CAR.SerialNumber, TIRE.SerialNumber
FROM dbo.tCar AS CAR
INNER JOIN dbo.tTire AS TIRE ON ( TIRE.CarID = CAR.ID)
WHERE CAR.Brand = 'Jaguar'

和

SELECT CAR.SerialNumber, TIRE.SerialNumber
FROM dbo.tCar AS CAR
CROSS APPLY (
    SELECT TIRE.SerialNumber
    FROM dbo.tTire AS TIRE 
    WHERE TIRE.CarID = CAR.ID
) AS TIRE
WHERE CAR.Brand = 'Jaguar'

注意：tTire.CarID 被索引，tCar.Brand 被索引

这两个将返回相同的输出。

我知道第二个查询只是愚蠢的，但同样，它只是作为我问题的一个例子。

现在，我猜（即使我不知道详细信息）SQL Server 将对第一个查询（JOIN）读取的数据执行一个巧妙且有限的锁定。

但我想知道它将如何为第二个查询（APPLY）读取的数据执行锁定，主要（显然是 imo）在“tTire”数据读取上。

万一加锁APPLY怎么办SQL Server perfom？

编辑：这个例子很简单，似乎 SQL Server 设法创建了相同的执行计划，但我的“应用”问题应该是在 RBAR 效应发生的地方。

几年前我读到软删除会提高删除的性能，因为它不会实际删除项目并影响聚集（和所有其他）索引，它只会改变一个值。

我最近尝试了这个，但我的表现非常令人失望。

所以我在网上搜索了一个很好的软删除实现，我最终阅读的第一件事是文章/博客说“软删除是不好的”。

显然，当桌子变大时，它弊大于利......

我不认为我所做的会使表格变得更大，因为每晚（每天）的维护都会删除（真正的）所有标记为删除的行。

那么，软删除真的不利于性能吗？真正的删除是否会导致整个聚簇表完全重新排序（这将是很多磁盘操作！！！）？