如何確定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年