2010-09-16 56 views
12

我创建了1个包含2个文件组的数据库:1个主索引和1个索引。SQL Server 2005:索引大于存储的数据

  • 主文件组包括1个数据文件(*密度纤维板):存储所有表
  • Index文件组包括1个索引文件(* .NDF):存储所有索引的索引

大多数是非聚集索引

在使用数据库一段时间后,数据文件为2GB,但索引文件为12GB。我不知道我的数据库中发生了什么问题。

我有一些问题:

  1. 如何减少索引文件的大​​小?
  2. 如何知道索引文件中存储了什么?
  3. 如何跟踪索引文件的所有影响?
  4. 如何限制索引文件的大​​小增长?
+2

你能告诉我们表格和你的指数是什么样子?特别是聚集索引(通常是我们的主键)很感兴趣 – 2010-09-16 14:52:18

+0

我同意我们确实需要查看定义。 – 2010-09-16 15:13:23

+0

大胖字符串(guid)主键在该表的每个索引中得到重复。 – 2010-09-16 18:50:00

回答

10

如何缩小索引文件的大​​小?

删除一些不需要的索引或减少现有索引的列数。请记住,聚簇索引列是所有非聚簇索引中包含的“隐藏”列。

如果你有一个a,b,c,d索引和a,b,c索引,你可以考虑放弃第二个,因为第一个是第二个。

您还可能能够find potential unused indexes通过查看sys.dm_db_index_usage_stats

如何知道什么是存储在索引文件?

它会存储你定义它存储的任何东西!下面的查询将有助于你判断哪些指标使用的是空间,是什么原因(行的数据,LOB数据)

SELECT convert(char(8),object_name(i.object_id)) AS table_name, i.name AS index_name, 
    i.index_id, i.type_desc as index_type, 
    partition_id, partition_number AS pnum, rows, 
    allocation_unit_id AS au_id, a.type_desc as page_type_desc, total_pages AS pages 
FROM sys.indexes i JOIN sys.partitions p 
     ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a 
     ON p.partition_id = a.container_id 
     order by pages desc 
5

我的猜测(我认为这是其中marc_s也为首)是你”已经声明你的聚簇索引至少有一些表是在索引文件组上。聚集索引确定如何(和在哪里)存储表格的实际数据。

发布您的一些代码肯定会帮助其他人找出问题所在。

我认为马丁史密斯非常好地回答了你的其他问题。我只是加上这个...如果你想限制索引大小,你需要评估你的索引。不要仅仅因为你认为你可能需要索引就添加索引。在数据库上使用真实的(或理想的真实世界)负载进行测试,以查看哪些索引实际上会为性能提供所需的提升。索引对他们有成本。除了您看到的空间成本之外,它们还会增加插入和更新的开销,这必须保持索引同步。由于这些成本,您应该始终有一个很好的理由来添加索引,并且您应该有意识地考虑权衡。

5

考虑到索引所需的总存储量大于给定数据库中的表数据所需的存储量实际上非常普遍。

但是,您的特定情况会显得过分。正如其他人指出的那样,如果您已将指定表的聚集索引分配到单独的数据文件(您的索引数据文件)中,那么整个物理表本身也将驻留在此文件中,因为以某种方式说出聚簇索引是表格。

提供您的表格模式和索引结构的详细信息将使我们能够为您提供更具体的指导。

其他海报提到:

其他探索的途径包括审查索引的碎片,因为这会增加存储需求。

重碎片(特别是在包含LOB数据的表的簇索引中)可能导致存储需求显着增加。在包含LOB数据的表上重组聚簇索引将压缩LOB数据。

See Reorganizing and Rebuilding Indexes

0

@马丁 - 史密斯的回答是,我需要什么几乎...

这里是如何排序的GB(MSSQL使用8KB页== 128页/ MB)

索引大小
SELECT 
    object_name(p.object_id) AS table_name 
    , i.name AS index_name 
    , i.index_id 
    , i.type_desc AS index_type 
    -- , partition_id 
    -- , partition_number AS pnum 
    -- , allocation_unit_id AS au_id 
    , rows 
    , a.type_desc as page_type_desc 
    , total_pages/(1024 * 128.0) AS sizeGB 
FROM 
    sys.indexes i 
    JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a ON p.partition_id = a.container_id 
    JOIN sys.all_objects ao ON (ao.object_id = i.object_id) 
    WHERE ao.type_desc = 'USER_TABLE' 
ORDER BY 
    -- table_name 
    sizeGB DESC