这是我的表的架构:
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)
哇,所有那些MAX列......你真的需要MAX用于URL和标题吗?你真的需要PK作为GUID吗?
由于大多数系统都受I/O限制,因此良好性能的一个关键(除了合理的索引和仅提取您需要的数据之外)是尽可能多地将数据放到每个页面上.由于所有这些LOB列每个都可能存储2GB数据,因此每次抓取页面对SQL Server来说都是一个噩梦.强烈建议尽可能考虑修剪其中一些数据类型,例如
(我也觉得奇怪的是你需要Unicode/nvarchar作为标题,但不需要描述,你需要Unicode/nvarchar用于URL/ImageURL,但不需要DisplayURL.你能解释其中的基本原理吗?我会给出一个提示:如果标题可以包含Unicode然后可以合理地假设标题也可以在描述中提到,所以它也应该支持Unicode.并且你的所有URL都可能只支持varchar;我不记得曾见过其中包含Unicode字符的URL(通常是URL编码的).)
如果您使用的是Enterprise Edition或更高版本,请考虑使用数据压缩.同样,由于大多数系统都受I/O限制,因此我们很乐意为压缩/解压缩数据付出轻微的CPU代价,以便将数据放到更少的页面上,这将大大减少对表执行大量读取操作所需的时间.
| 归档时间: |
|
| 查看次数: |
3175 次 |
| 最近记录: |