查询VARBINARY(MAX)列非空行数耗时过长，如何优化？

这个问题其实挺常见的——虽然表只有5000行，但VARBINARY(MAX)类型的列藏着不小的坑。这种大对象列（LOB）在查询IS NOT NULL时，数据库往往得去读取实际的LOB存储页，哪怕只是判断是否非空，IO开销也会比普通列大很多，导致看起来简单的查询变慢。给你几个实用的解决办法：

1. 创建计算列+非聚集索引（最推荐） #

我们只需要判断列是否非空，完全没必要每次都去碰庞大的VARBINARY(MAX)数据。可以先建一个持久化的计算列，把非空判断的结果存成体积极小的BIT类型：

ALTER TABLE [Table] ADD Column_Is_NotNull AS CASE WHEN [Column] IS NOT NULL THEN 1 ELSE 0 END PERSISTED;

然后给这个计算列建非聚集索引：

CREATE NONCLUSTERED INDEX IX_Table_Column_Is_NotNull ON [Table] (Column_Is_NotNull);

之后你可以直接用计算列查询：

SELECT COUNT(*) FROM [Table] WHERE Column_Is_NotNull = 1;

哪怕不改查询语句，SQL Server的查询优化器也会自动利用这个索引加速原查询——索引里只存1/0两种值，扫描起来极快，完全不用访问LOB数据，性能提升会非常明显。

2. 改用COUNT([Column])并检查执行计划 #

COUNT([Column])本身就是统计非空值的数量，和你的需求完全匹配。虽然COUNT(*)和COUNT(1)在SQL Server里通常优化逻辑一致，但COUNT([Column])可能会让优化器更精准地定位需求。你可以查看执行计划，看看是否能利用现有的索引：比如如果表上有其他非聚集索引，且该索引包含了这个VARBINARY(MAX)列（不过不推荐长期这么做，会让索引体积变大）。

3. 更新统计信息 #

有时候查询慢只是因为统计信息过时，导致优化器选错了执行计划。可以简单更新一下表的统计信息：

UPDATE STATISTICS [Table];

这一步操作成本极低，尤其是如果表的数据最近有过大量变更的话，大概率能帮优化器生成更高效的执行计划。

4. 检查LOB数据的存储方式 #

如果VARBINARY(MAX)里存的都是小于8000字节的小数据，可以看看数据库是否把它们存在了行外（LOB_DATA）——行外存储的读取开销会比行内（IN_ROW_DATA）大不少。用这个查询查看存储方式：

SELECT 
    name AS column_name,
    max_in_row_length,
    is_located_on_filegroup
FROM sys.columns 
WHERE object_id = OBJECT_ID('Table') AND name = 'Column';

如果确实是行外存储且数据都很小，可以尝试修改列的存储选项（操作前请备份数据）：

ALTER TABLE [Table] ALTER COLUMN [Column] VARBINARY(MAX) FILESTREAM_ON NULL;

让小数据存储在行内，能降低读取时的IO开销。

内容的提问来源于stack exchange，提问作者user3518663