Question

我有一个项目，它生成数据库的快照，将其转换为XML，然后将XML存储在单独的数据库中。不幸的是，这些快照正在成为巨大的文件，现在每个大约10兆字节。幸运的是，我只需将它们存放大约一个月才能再次丢弃，但仍然，一个月的快照结果变得非常不利于它的性能......

我认为有一个提高性能的方法很多。不，不是将XML存储在某个单独的文件夹中，因为我没有对该服务器上任何位置的写访问权限。 XML必须保留在数据库中。但不知何故，字段[内容]可能会以某种方式进行优化，所以事情会加快......
我不需要在这个领域有任何全文搜索选项。我永远不会根据这个领域进行任何搜索。那么可能通过禁用此字段来搜索指令或其他什么？

该表没有引用其他表，但结构是固定的。我无法重命名，或更改字段类型。所以我想知道是否仍然可以进行优化。
嗯，是吗？

结构，由SQL Server生成：

CREATE TABLE [dbo].[Snapshots](
    [Identity] [int] IDENTITY(1,1) NOT NULL,
    [Header] [varchar](64) NOT NULL,
    [Machine] [varchar](64) NOT NULL,
    [User] [varchar](64) NOT NULL,
    [Timestamp] [datetime] NOT NULL,
    [Comment] [text] NOT NULL,
    [Content] [text] NOT NULL,
 CONSTRAINT [PK_SnapshotLog] 
    PRIMARY KEY CLUSTERED ([Identity] ASC) 
    WITH (PAD_INDEX  = OFF, 
    STATISTICS_NORECOMPUTE  = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ALLOW_ROW_LOCKS  = ON, 
    ALLOW_PAGE_LOCKS  = ON, 
    FILLFACTOR = 90) ON [PRIMARY],
 CONSTRAINT [IX_SnapshotLog_Header] 
    UNIQUE NONCLUSTERED ([Header] ASC) 
    WITH (PAD_INDEX  = OFF, 
    STATISTICS_NORECOMPUTE  = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ALLOW_ROW_LOCKS  = ON, 
    ALLOW_PAGE_LOCKS  = ON, 
    FILLFACTOR = 90) 
    ON [PRIMARY],
 CONSTRAINT [IX_SnapshotLog_Timestamp] 
    UNIQUE NONCLUSTERED ([Timestamp] 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] TEXTIMAGE_ON [PRIMARY]

从此表中选择数据时，以及在此数据库中的其他表中选择或插入数据时，性能不仅很慢！当我从该表中删除所有记录时，整个系统很快。当我开始添加快照时，性能开始下降。在大约30个快照之后，性能变差并且连接超时的风险增加。
也许问题不在数据库本身，尽管在通过管理工具使用时它仍然很慢。（当快照为空时快速。）我主要使用ASP.NET 3.5和实体框架连接到此数据库，然后读取多个表。也许这里可以获得一些性能，虽然这无法解释为什么数据库在管理工具中也很慢，以及通过直接连接的其他应用程序使用时...

Answer 1

该表位于PRIMARY文件组中。你可以将这个表移动到另一个文件组，甚至是受限制的吗？如果可以，您应该将其移动到具有自己的物理文件的其他文件组。这应该会有很大帮助。 Check out如何创建新文件组并将对象移动到新文件组。

Answer 2

鉴于您的约束，您可以尝试压缩XML，然后以二进制形式插入数据库。这应该会显着降低此数据的存储成本。

你提到这对性能有害，你多久从这张快照表中读取一下？如果这只是存储它应该只影响写入时的性能。如果你经常阅读这个，你确定性能问题是数据存储而不是解析10MB的XML吗？

Answer 3

当我使用NVARCHAR（MAX）数据类型替换TEXT数据类型时，整个系统变得更快。 HLGEM向我指出TEXT数据类型已经过时，因此很麻烦。但是，如果可以使用更现代的数据类型轻松替换这些列的数据类型，这仍然是一个问题。（翻译：我需要测试代码是否可以使用更改的数据类型...）
那么，如果我将数据类型从TEXT更改为NVARCHAR（MAX），是否有任何因此而中断？我可以期待的问题？
现在，这似乎解决了这个问题，但在我被允许做出这个改变之前，我需要做一些游说。所以我需要确保它不会导致任何（意外）问题。

使用巨大的文本字段优化表格

3 个答案: