我们遇到了一些非常非常大的表的问题,它们会减慢系统速度。所以我的问题是,对于表中的行数来说,这个大小是否正常,以及可以做些什么来使它更小更轻,它不应该减慢一切。
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
那不是一个大表,假设您在服务器级硬件上运行,SQL-Server 应该能够轻松处理。如果您的硬件严重不足,那么我们告诉您的任何事情都无法完全解决问题。
您可能会遇到与使用 GUID 相关的性能问题。您的 PK 是聚集的并且是一个 GUID,这意味着它在插入时不断移动行以保持聚集索引正确。如果您没有使用
newsequentialid
GUID 的默认值,那么您就有问题了。当然,使用 int 键连接会更快,但围绕它完全重新设计可能为时已晚。您可能需要尝试使用索引 - 您想要那些可以处理您的查询的索引,但太多会大大减慢插入速度。
您最后一次更新统计信息或重新索引表是什么时候?
您可以查看按日期对表进行分区。这可能会加快速度。如果您没有 Enterprise Edition 和正确的硬件进行分区,您可以归档旧记录并仅将它们用于报告,方法是将主表中的活动记录与存档表中的非活动记录联合起来。这样一来,您需要处理的主要工作的记录就会少得多。
但很明显,您最迫切需要的是一位知道如何进行性能调优的优秀可靠的 DBA。一个不会让你在未来犯设计错误并且有技能和能力重构你的系统以使其工作的人。性能调整不是你可以通过在这样的板上提问来学习的东西。这是一个复杂的主题,需要多年积累的大量专业知识并通过使用许多数据库。如果你没有 DBA,那就雇一个。对于以后的项目,您可能应该在设计时雇用一个;数据库很难重构,它们需要从一开始就针对性能进行设计。