如何处理大桌子

Question

我们有几个表的问题，这些表非常大，会减慢系统速度。所以我的问题是，对于表中的行数来说，这个大小是否正常，以及可以做些什么来使它更小更轻，它不应该减慢一切。

CREATE TABLE [dbo].[TransactionEntry](
    [TransactionEntryID] [uniqueidentifier] NOT NULL,
    [TransactionID] [uniqueidentifier] NULL,
    [ItemStoreID] [uniqueidentifier] NULL,
    [Sort] [int] NULL,
    [TransactionEntryType] [int] NOT NULL,
    [Taxable] [bit] NULL,
    [Qty] [decimal](19, 3) NULL,
    [UOMPrice] [money] NULL,
    [UOMType] [money] NULL,
    [UOMQty] [decimal](19, 3) NULL,
    [Total] [money] NULL,
    [RegUnitPrice] [money] NULL,
    [DiscountPerc] [decimal](19, 3) NULL,
    [DiscountAmount] [money] NULL,
    [SaleCode] [nvarchar](50) NULL,
    [PriceExplanation] [nvarchar](50) NULL,
    [ParentTransactionEntry] [uniqueidentifier] NULL,
    [AVGCost] [money] NULL,
    [Cost] [money] NULL,
    [ReturnReason] [int] NULL,
    [Note] [nvarchar](50) NULL,
    [DepartmentID] [uniqueidentifier] NULL,
    [DiscountOnTotal] [decimal](19, 3) NULL,
    [Status] [smallint] NULL,
    [DateCreated] [datetime] NULL,
    [UserCreated] [uniqueidentifier] NULL,
    [DateModified] [datetime] NULL,
    [UserModified] [uniqueidentifier] NULL,
    [TotalAfterDiscount] [decimal](18, 3) NULL,
    [TaxID] [uniqueidentifier] NULL,
    [TaxRate] [decimal](18, 4) NULL,
 CONSTRAINT [PK_TransactionEntry] PRIMARY KEY CLUSTERED 
(
    [TransactionEntryID] 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]

GO

Answer 1

这不是一个大表，假设您在服务器级硬件上运行，SQL-Server 应该能够轻松处理。如果您的硬件严重不足，那么我们告诉您的任何内容都无法完全解决问题。

您可能会遇到与使用 GUID 相关的性能问题。您的 PK 是聚集的并且是一个 GUID，这意味着它在插入时不断移动行以保持聚集索引的正确性。如果您没有使用newsequentialidGUID 的默认值，那么您就有问题了。当然，使用 int 键连接会更快，但要完全重新设计它可能为时已晚。

您可能需要尝试使用索引 - 您希望索引可以处理您的查询，但太多会显着减慢插入速度。

您上次更新统计信息或重新索引表是什么时候？

您可以查看按日期对表进行分区。这可能会加快速度。如果您没有企业版和正确的分区硬件，您可以存档旧记录，并仅通过将主表中的活动记录与存档表中的非活动记录合并来将它们用于报告。这样一来，您要处理的主要工作的记录就会少得多。

但很明显，您最迫切需要的是一个优秀的、扎实的 DBA，他知道如何进行性能调优。一个不会让你在未来犯设计错误并且有技能和能力重构你的系统以使其工作的人。性能调优不是你可以通过在这样的板上提问来学习的东西。这是一个复杂的主题，需要通过多年学习和使用许多数据库获得大量专业知识。如果你没有 DBA，那就雇一个。对于以后的项目，您可能应该在设计时雇用一个；数据库很难重构，它们需要从一开始就针对性能进行设计。