我在同一个 SQL 服务器实例上的两个独立数据库中有两个相同的表,定义如下(注意,这是第三方软件,因此我无法更改表架构):-
EDIT:[RouteParamXml] nvarchar NOT NULL 始终为空字符串
EDIT:所有 UserDef 字段都是空字符串,只有 110 行包含 SecondaryOrderID、ActionUserId 和 FIXBrokerOrderID 中的数据均已填充,我看不出空间差异如此之大的原因
CREATE TABLE blah(
[AuditEventID] [int] NOT NULL,
[ActionCode] [tinyint] NOT NULL,
[ActionDate] [datetime] NOT NULL,
[ActionUserID] [nvarchar](15) NOT NULL,
[OrderID] [int] NOT NULL,
[PlaceID] [int] NOT NULL,
[FIXMsgType] [int] NOT NULL,
[FIXOrderStatus] [int] NOT NULL,
[FIXBrokerOrderID] [nvarchar](60) NOT NULL,
[FilledQty] [float] NOT NULL,
[Stamp] [varbinary](8) NOT NULL,
[MarkForDelete] [smallint] NOT NULL,
[NewOrderAuditTime] [datetime] NOT NULL,
[ReplaceOrderAuditTime] [datetime] NOT NULL,
[SendRecvTime] [datetime] NOT NULL,
[QueueID] [int] NOT NULL,
[SecondaryOrderID] [nvarchar](255) NOT NULL,
[RouteParamXml] [nvarchar](max) NOT NULL,
[UserDef1] [nvarchar](255) NOT NULL,
[UserDef2] [nvarchar](255) NOT NULL,
[UserDef3] [nvarchar](255) NOT NULL,
[UserDef4] [nvarchar](255) NOT NULL,
[UserDef5] [nvarchar](255) NOT NULL,
[UserDef6] [nvarchar](255) NOT NULL,
[FIXOrderID] [int] NOT NULL,
[OrigFIXOrderID] [int] NOT NULL,
CONSTRAINT [blah_PK] PRIMARY KEY CLUSTERED
(
[OrderID] ASC,
[PlaceID] ASC,
[AuditEventID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
一个表有 130 万行,占用约 22MB(兆字节)的磁盘空间。另一个表有 100 万行,占用 15GB(千兆字节)的磁盘空间。
我一直在研究各种 DBCC 选项,但没有发现任何错误 DBCC CHECKALLOC 输出(好表)
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594046316544 (type LOB data). FirstIAM (1:390). Root (1:389). Dpages 0.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594046316544 (type LOB data). 241 pages used in 29 dedicated extents.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198687744 (type In-row data). FirstIAM (1:362878). Root (1:549074). Dpages 27571.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198687744 (type In-row data). 27646 pages used in 3457 dedicated extents.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198753280 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198753280 (type Row-overflow data). 0 pages used in 0 dedicated extents.
DBCC CHECKALLOC 输出(坏表)
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594046316544 (type LOB data). FirstIAM (1:2845). Root (1:2844). Dpages 0.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594046316544 (type LOB data). 1880724 pages used in 235090 dedicated extents.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197901312 (type In-row data). FirstIAM (1:1155704). Root (1:2024010). Dpages 25147.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197901312 (type In-row data). 25216 pages used in 3153 dedicated extents.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197966848 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197966848 (type Row-overflow data). 0 pages used in 0 dedicated extents.
有什么想法我应该从哪里开始探究为什么这张桌子如此巨大
答案1
表格里有什么数据?
我的直觉是,并不是所有的字段都真正填写在了小表中。
统计数据显示,“LOB数据”是主要差异;每 MS,这个 bucket 包含:
页面包含 varchar(max)、nvarchar(max)、varbinary(max)、text、ntext、xml 和 image 数据。
换句话说,请仔细看看本专栏的内容:
[RouteParamXml] [nvarchar](max)