Question

我正在使用SQL Server 2005，并且只有一个表：

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

Code1＆amp; 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

Answer 2

我会尝试估算你的桌子大小，请注意我使用90％进行经验法则填充。

Row header                   4  bytes
Fixed data size             20  bytes (2 X 4 bytes for int + 3 x 4 bytes for real)
Variable size columns count  2  bytes
NULL bitmap columns count    2  bytes
Total for one row           28  bytes
Available page size       8060  bytes
Page header                 96  bytes
Rows per page (max)        284  (Available page size - Page Header) / Total for one row
Rule of thumb page fill     90% 
Rows per page (expected)   255 
Number of rows               2.45E+07 
Number of pages          96079 
Pages per MB               128 
Total MB                   751

Answer 3

您提到主键是聚簇索引的部分。它不是整个聚集索引吗？

只是一个想法，但如果聚集索引不是唯一的（我的意思是实际上明确声明为UNIQUE或PRIMARY KEY），那么SQL Server需要创建一个行ID（RID）我认为是一个GUID，因此占用8个字节。

如果启用快照隔离，您还可以在行中获得额外的开销。如果在读取提交的快照打开时插入或更新了数据，则始终具有该8字节RID以及6字节事务序列号（XTS）。

旁注：你为什么使用100的FILLFACTOR？如果数据永远不会改变，那就好了，但是否则会因页面拆分而导致性能下降。

Answer 4

其他人已正确提到页面大小为8k，但可用于数据的数量为8096,8060数字是页面上存储的单行的最大长度（不使用LoB或SLoB）。（设计时，差异被提到作为建筑保险）。

可以应用各种开销，从行unquifier到可空性位图 - Microsoft发布了有关如何计算聚簇表/堆的大小的指南。

聚集索引：http://msdn.microsoft.com/en-us/library/ms178085(SQL.90).aspx

堆：http://msdn.microsoft.com/en-us/library/ms189124(SQL.90).aspx

关于缩小的主题，也称为“邪恶” - 阅读Paul Randal对缩小的描述，然后尽可能避免使用它：http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

Answer 5

拥有100％的FILLFACTOR并不意味着每个页面都被完全填充到最高容量 - 只是我和SQL Server将尝试这样做，如果它只能用于叶子节点。

此外，您还需要询问有关未来性能与空间使用情况的非常严格的问题。有了这么多的记录，填充因子太紧，意味着每个新插入甚至更新都会触发相当大规模的重新排列，这取决于使用情况，也可能意味着死锁升级。并不是说你可能没有充分的理由来打包并担心磁盘空间，但是你需要非常认真地问这些问题。如今，购买更大的磁盘相当便宜。

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

5 个答案: