也谈SQL Server 2008 处理隐式数据类型转换在运行计划中的增强

Posted 2020-09-29 blfbuaa

在 SQL Server 查询中，不经意思的隐匿数据类型转换可能导致极大的查询性能问题。比方一个看起来没有不论什么问题简单的条件：WHERE c = N’x’ 。假设 c 的数据类型是 varchar。而且表中包括大量的数据，这个查询可能导致极大的性能开销。由于这个操作会导致列 c 的数据类型转换为 nvarchar与常量值匹配，在 SQL Server 2008 及之后的版本号中，这样的操作做了增强，一定程度上减少了性能开销，參考SQL Server 2008 处理隐式数据类型转换在运行计划中的增强
只是在实际应用中发现。这样的增强有时候似乎没有起到作用，还是会存在非常大的性能问题。
近期找时间做了一个測试。找出了一种可能的问题，先创建一个測试表

USE tempdb
GO
CREATE TABLE _t(
    c varchar(50)
);
CREATE INDEX IX_c ON _t( c );
GO

-- 添加 10000 条数据
INSERT _t
SELECT (9999 + id) FROM(
    SELECT TOP 10000 id = ROW_NUMBER() OVER( ORDER BY GETDATE() )
    FROM sys.all_columns a, sys.all_columns
)ID

然后通过运行计划看下查询计划

-- Rebuild索引，确保无索引碎片和统计信息准确
ALTER INDEX IX_c ON _t REBUILD;
GO
SET SHOWPLAN_ALL ON
GO
SELECT * FROM _t WHERE c = N‘10005b‘;
GO
SET SHOWPLAN_ALL OFF;

注意EstimateRows列，该列值为1，表示评估的满足条件的数据是1条，如今看起来一切正常

然后我们把据变一下。将大量数据变成同样值

-- 将 5000 条数据值变成一样，重建索引之后又一次測试
UPDATE _t SET c = ‘15000‘ WHERE c >= ‘15000‘
ALTER INDEX IX_c ON _t REBUILD;
GO
SET SHOWPLAN_ALL ON
GO
SELECT * FROM _t WHERE c = N‘10005‘;
GO
SET SHOWPLAN_ALL OFF;

然后我们发现评估的记录数变大了

继续加大同样值的比例

-- 继续加大同样值的比例。重建索引之后又一次測试
UPDATE _t SET c = ‘11000‘ WHERE c >= ‘11000‘ AND c < ‘15000‘
ALTER INDEX IX_c ON _t REBUILD;
GO
SET SHOWPLAN_ALL ON
GO
SELECT * FROM _t WHERE c = N‘10005‘;
GO
SET SHOWPLAN_ALL OFF;
GO
-- 继续加大同样值的比例，重建索引之后又一次測试
UPDATE _t SET c = ‘10100‘ WHERE c >= ‘10100‘ AND c < ‘11000‘
ALTER INDEX IX_c ON _t REBUILD;
GO
SET SHOWPLAN_ALL ON
GO
SELECT * FROM _t WHERE c = N‘10005‘;
GO
SET SHOWPLAN_ALL OFF;

对应的。预估的行数也在添加

假设我们使用正确的数据类型，WHERE c = ‘10005’，则始终能够得到正确的预估行数。
我不确定 SQL Server是依照什么标准来预估这样的情况下的记录数。从运行计划看，它将 nvarchar值通过 GetRangeThroughConvert 评估出一个范围，实际运行的是一个范围 seek，在试验中，查询的值是一个常量。能够准确评估，难道这个转换之后，把常量当变量评估了。所以是一个泛泛的评估结果值。

这个问题看起来不大，但在实际应用中。假设表的数据量非常大。而且不是平均分布的话，这样的错误的预估结果带来的性能影响是非常大的，比方明明满足条件的非常少，能够 seek, 但评估的结果非常大。运行计划变 Scan了。在复杂的运行计划中，这个带来的影响更大。
看起来，2008（包括R2）还没有那么省心，这样的问题还得控制，特别是程序中，.Net过来的參数通常都是 nvarchar类型，这样的导致性能问题的情况遇到N多了
最后啰嗦一下的是。在 SQL Server 2014中，没有再发现这个问题（不知道 2012中怎么样）