如何确定SQL Server 2008 R2上的全文索引的大小？

Question

我有一个SQL 2008 R2数据库，其上有一些表格，其中一些表格定义了全文索引。我想知道如何确定特定表的索引大小，以控制和预测它的增长。

有没有办法做到这一点？

Answer 1

目录视图sys.fulltext_index_fragments会跟踪每个片段的大小，而不管目录如何，因此您可以采用SUM这种方式。这假定每个表格的一个全文索引的限制将保持这种情况。以下查询将再次获取数据库中每个全文索引的大小，而不管目录如何，但如果您只关心特定表，则可以使用WHERE子句。

SELECT 
    [table] = OBJECT_SCHEMA_NAME(table_id) + '.' + OBJECT_NAME(table_id), 
    size_in_KB = CONVERT(DECIMAL(12,2), SUM(data_size/1024.0)) 
FROM sys.fulltext_index_fragments 
-- WHERE table_id = OBJECT_ID('dbo.specific_table_name') 
GROUP BY table_id; 

另请注意，如果碎片数很高，您可能会考虑重新组织。

Answer 2

如果你是一个特定的目录 使用SSMS 后 - 的Clik上[数据库]和扩大对象 - 点击【贮藏】 - 右键单击​​{特定的目录} - 选择Propertie并单击。 一般TAB，你会找到的目录大小=“NN”

Answer 3

我用类似这样的东西（这也将计算XML-索引的大小，...如果存在的话）

SELECT S.name, 
     SO.name, 
     SIT.internal_type_desc, 
     rows = CASE WHEN GROUPING(SIT.internal_type_desc) = 0 THEN SUM(SP.rows) 
       END, 
     TotalSpaceGB = SUM(SAU.total_pages) * 8/1048576.0, 
     UsedSpaceGB = SUM(SAU.used_pages) * 8/1048576.0, 
     UnusedSpaceGB = SUM(SAU.total_pages - SAU.used_pages) * 8/1048576.0, 
     TotalSpaceKB = SUM(SAU.total_pages) * 8, 
     UsedSpaceKB = SUM(SAU.used_pages) * 8, 
     UnusedSpaceKB = SUM(SAU.total_pages - SAU.used_pages) * 8 
FROM sys.objects SO 
INNER JOIN sys.schemas S ON S.schema_id = SO.schema_id 
INNER JOIN sys.internal_tables SIT ON SIT.parent_object_id = SO.object_id 
INNER JOIN sys.partitions SP ON SP.object_id = SIT.object_id 
INNER JOIN sys.allocation_units SAU ON (SAU.type IN (1, 3) 
             AND SAU.container_id = SP.hobt_id) 
             OR (SAU.type = 2 
              AND SAU.container_id = SP.partition_id) 
WHERE S.name = 'schema' 
     --AND SO.name IN ('TableName') 
GROUP BY GROUPING SETS(
         (S.name, 
         SO.name, 
         SIT.internal_type_desc), 
         (S.name, SO.name), (S.name),()) 
ORDER BY S.name, 
     SO.name, 
     SIT.internal_type_desc; 

这通常会提供高于sys.fulltext_index_fragments的数字，但当与表格的sys.partitions结合使用时，它将合计从EXEC sys.sp_spaceused @objname = N'schema.TableName';返回的数字。

测试与SQL Server 2016年，但文件说，它应该存在，因为2008年