任何人都可以解释SQL Server 2005表的大小

Question

我正在使用SQL Server 2005并有一个表:

int Code1,
int Code2, 
real Val1,
real Val2,
real Val3,

Code1和Code2充当主键,是聚集索引的一部分(只有一个索引).每个参数占用4个字节(每行占用20个字节).

表中有2450万条记录,填充因子为100%,索引占2MB,页面大小为4k.

假设每个页面都填充了尽可能多的记录,那么每个页面应该包含204条记录,这些记录是4080字节(%99.6页填充)

所以,我希望磁盘上占用的磁盘大小约为500MB(20字节*24.5 M记录),但事实是该表占用773MB.

我尝试缩小和重新索引,但表格大小没有变化.

我不是SQL专家,有人可以帮忙吗？

Answer 1

首先,SQL Server中的页面大小为8 KB,无法更改; 这是一个你无法控制的系统设置.

在这8192个字节中,作为用户,您可以随意使用大约8060个 - 其余的是标题和控制结构等等.

因此,在您的情况下,每行占用20个字节,您应该能够获得每页403行.所以这给你大约60'795个数据页,8 KB一件= 486 MB.

但是:出于性能原因,SQL Server不会根据需要分配每个页面 - SQL Server将为您的数据库预先分配给定的大小.在SQL Server Management Studio中创建新数据库时,您将看到默认情况下,SQL Server分配3 MB空间,并在需要更多空间时增加1 MB.这些设置是可变的 - 你没有提到它们是什么.

此外,出于性能原因,SQL Server通常不会将未使用的数据页"返回"回操作系统.这是一项相当昂贵的操作,并且很有可能在某个时候再次需要这些操作.索引页面也是如此 - 如果您可能在该表上有另一个索引(甚至只是为了尝试一些东西)并且它使用了许多页面,那么默认情况下这些页面将不会返回到操作系统.

此外,根据数据如何插入表中,数据结构中可能存在一些"漏洞" - 并非所有页面都可能完全达到100%填充.为了保持b树的平衡,SQL Server甚至可能会选择将页面拆分为两个,即使它们还没有100%完整.

总而言之:是的,理论上和数学上,你的数据库应该大约为486 MB的数据和2 MB的索引 - 但实际上有多糟糕,如果文件的大小是770+ MB而不是？它真的疼吗？

使用这个检查DMV(动态管理视图)的T-SQL脚本,您可以深入细致地了解表索引结构,以及在索引的每个级别上使用了多少页,以及填充因子如何您的数据页面非常有用且有用!

SELECT 
    t.NAME 'Table name',
    i.NAME 'Index name',
    ips.index_type_desc,
    ips.alloc_unit_type_desc,
    ips.index_depth,
    ips.index_level,
    ips.avg_fragmentation_in_percent,
    ips.fragment_count,
    ips.avg_fragment_size_in_pages,
    ips.page_count,
    ips.avg_page_space_used_in_percent,
    ips.record_count,
    ips.ghost_record_count,
    ips.Version_ghost_record_count,
    ips.min_record_size_in_bytes,
    ips.max_record_size_in_bytes,
    ips.avg_record_size_in_bytes,
    ips.forwarded_record_count
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
    sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN  
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
    T.NAME = 'your-table-name-here'
ORDER BY
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count