Question

我有一个包含大量数据的SQL Server数据库（6500万行主要是文本，总共8Gb）。数据每周只更改一次。我有一个ASP.NET Web应用程序，它将对此数据运行多个SQL查询，这些查询将计算满足各种条件的行数。由于数据每周只更改一次，因此在本周存储SQL查询及其计数的最有效方法是什么？我应该将它存储在数据库中还是应用程序中？

Answer 1

如果数据仅每周修改一次，作为该过程的一部分（ETL？）过程，请执行“基本”计数并将结果存储在数据库的表中。此后，您可以只查询那些小的汇总表，而不是对大表进行冗长的查询。

Answer 2

如果您不需要100％的最新准确行数，则可以查询SQL Server的内部信息：

Select so.name as 'TableName', si.rowcnt as 'RowCount'
from sysobjects so
inner join sysindexes si on so.id = si.id 
where so.type = 'u' and indid < 2

执行速度非常快，无需额外的表格。在许多更新发生的地方不准确，但可能在您的预期用途中足够准确。 [感谢评论者！]

更新：做了一些挖掘，这确实产生了准确的计数（由于总和较慢，但仍然很快）：

SELECT OBJECT_SCHEMA_NAME(ps.object_id) AS SchemaName, 
       OBJECT_NAME(ps.object_id) AS ObjectName, 
       SUM(ps.row_count) AS row_count
FROM sys.dm_db_partition_stats ps
JOIN sys.indexes i ON i.object_id = ps.object_id
                      AND i.index_id = ps.index_id
WHERE i.type_desc IN ('CLUSTERED','HEAP')
AND OBJECT_SCHEMA_NAME(ps.object_id) <> 'sys'
GROUP BY ps.object_id
ORDER BY OBJECT_NAME(ps.object_id), OBJECT_SCHEMA_NAME(ps.object_id)

Ref

请记住，存储的计数信息并非总是100％准确的SQL Server 2000.对于2005年创建的新表计数是准确的。但对于2000年和现在存在的表格通过还原或更新驻留在2005年，您需要运行（仅限一旦移动到2005年之后）sp_spaceused @updateusage = 使用COUNT_ROWS选项进行N'true'或DBCC UPDATEUSAGE。

Answer 3

查询应存储为存储过程或视图，具体取决于复杂程度。

根据您的情况，我会调查indexed views.

它们允许您存储查询和结果集，用于聚合等无法编制索引的内容。

作为奖励，查询优化器“知道”它也具有此数据，因此如果您检查另一个查询中的视图索引中存储的计数或其他内容（即使没有直接引用该视图），它仍然可以使用存储的数据。

存储查询和大型SQL数据计数的最有效方法

3 个答案: