在SQL Server中选择大量数据的快速方法

gop*_*pal 2 sql-server-2008

这是我的表的架构:

CREATE TABLE [dbo].[ClassifiedDataStore_MasterTesting]
(
[PK_ID] [uniqueidentifier] NOT NULL,
[FK_SubCategory_Master] [int] NULL,
[FK_IntegratedWeb_Master] [int] NULL,
[FK_City_Master] [int] NULL,
[Title] [nvarchar](max) NULL,
[Description] [varchar](max) NULL,
[Url] [nvarchar](max) NULL,
[DisplayUrl] [varchar](max) NULL,
[Date] [datetime] NULL,
[ImageURL] [nvarchar](max) NULL,
[Price] [decimal](18, 2) NULL,
[Fetch_Date] [datetime] NULL,
[IsActive] [bit] NULL,
[record_id] [int] IDENTITY(1,1) NOT NULL,
CONSTRAINT [PK_ClassifiedDataStore_Master2] PRIMARY KEY CLUSTERED 
(
[PK_ID] ASC
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
Run Code Online (Sandbox Code Playgroud)

Aar*_*and 8

哇,所有那些MAX列......你真的需要MAX用于URL和标题吗?你真的需要PK作为GUID吗?

由于大多数系统都受I/O限制,因此良好性能的一个关键(除了合理的索引和仅提取您需要的数据之外)是尽可能多地将数据放到每个页面上.由于所有这些LOB列每个都可能存储2GB数据,因此每次抓取页面对SQL Server来说都是一个噩梦.强烈建议尽可能考虑修剪其中一些数据类型,例如

  • 如果可行的话,使用IDENTITY列而不是GUID - 为什么两者都有?
  • 对于FK要查找的总是<32K行的任何INT,请使用SMALLINT
  • 对于要查找总是<255行的FK的任何INT,请使用TINYINT
  • 使用行内存储(而不是MAX类型)来处理标题和URL等内容
  • 您可以使用<18位的价格削减几个字节 - 怀疑您将分类物品价值$ 1,000,000,000,000 +
  • 如果Date/Fetch_Date不需要<分钟精度,请使用SMALLDATETIME
  • 如果Date/Fetch_Date不需要<天精度,请使用DATE

(我也觉得奇怪的是你需要Unicode/nvarchar作为标题,但不需要描述,你需要Unicode/nvarchar用于URL/ImageURL,但不需要DisplayURL.你能解释其中的基本原理吗?我会给出一个提示:如果标题可以包含Unicode然后可以合理地假设标题也可以在描述中提到,所以它也应该支持Unicode.并且你的所有URL都可能只支持varchar;我不记得曾见过其中包含Unicode字符的URL(通常是URL编码的).)

如果您使用的是Enterprise Edition或更高版本,请考虑使用数据压缩.同样,由于大多数系统都受I/O限制,因此我们很乐意为压缩/解压缩数据付出轻微的CPU代价,以便将数据放到更少的页面上,这将大大减少对表执行大量读取操作所需的时间.