從sql server 2005中的單個表訪問數據太慢

以下是表的腳本。從這個表訪問數據太慢了。從sql server 2005中的單個表訪問數據太慢

SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 
CREATE TABLE [dbo].[Emails](
    [id] [int] IDENTITY(1,1) NOT NULL, 
    [datecreated] [datetime] NULL CONSTRAINT [DF_Emails_datecreated] 
     DEFAULT (getdate()), 
    [UID] [nvarchar](250) COLLATE Latin1_General_CI_AS NULL, 
    [From] [nvarchar](100) COLLATE Latin1_General_CI_AS NULL, 
    [To] [nvarchar](100) COLLATE Latin1_General_CI_AS NULL, 
    [Subject] [nvarchar](max) COLLATE Latin1_General_CI_AS NULL, 
    [Body] [nvarchar](max) COLLATE Latin1_General_CI_AS NULL, 
    [HTML] [nvarchar](max) COLLATE Latin1_General_CI_AS NULL, 
    [AttachmentCount] [int] NULL, 
    [Dated] [datetime] NULL 
) ON [PRIMARY]

以下查詢需要50秒來獲取數據。

select id, datecreated, UID, [From], [To], Subject, AttachmentCount, 
    Dated from emails

如果我有身體和的Html在選擇那麼時間是事件雪上加霜。

指標上：

ID唯一聚集
從非唯一的非聚集
要非唯一的非聚集

Tabls擁有目前180000+記錄。

每個月可能會有100,000條記錄，所以隨着時間的流逝，這會變得更慢。

是否將數據拆分成兩個表將解決問題？還有哪些其他指標？

來源

2010-06-14 Kashif

等一下：檢索180K記錄需要50秒？你爲什麼檢索180K記錄？你對他們做什麼？爲什麼要50秒？這不像人類可以在屏幕上處理180K記錄。所以我的問題是你是否真的需要所有的記錄，或者你有沒有從你的例子中省略的WHERE子句？ – MJB 2010-06-14 13:19:22

我不認爲索引會起作用，因爲你沒有where子句。無論如何，你都在進行全表掃描。 – Blorgbeard 2010-06-14 13:19:24

爲什麼你需要從表中檢索所有記錄？你不能使用一些restrcitive子句嗎？ – pcent 2010-06-14 13:32:57

這幾乎可以肯定是造成問題的數據量。因此，在您需要之前，您不應該獲取Subject列。即使提取SUBSTRING(Subject, 100)可能會明顯更快。

這可能是無關緊要的，但舊版本的SQL Server的遭遇，如果BLOB列不是最後一排的，所以只是作爲一個實驗我希望移居[AttachmentCount]和[Dated]三個nvarchar(max)列以上。

來源

2010-06-14 14:56:19 egrunin

感謝您的幫助。我將通過SQL文檔來驗證您對BLOB的評論。 – Kashif 2010-06-14 15:49:53

從sql server 2005中的單個表訪問數據太慢

回答

相關問題