SQL Server 2000表優化

我一整天都在努力優化具有〜900萬行的SQL Server 2000數據庫表。我唯一的數據庫經驗是用幾百行的表格，所以我從來沒有真正需要處理優化。SQL Server 2000表優化

我正在做基於21位數字的選擇和更新。

使用索引字符（21）類型，查詢需要超過2秒，SQL Server進程需要1.5g的ram和100％cpu。

使用索引bigint類型，我的查詢需要幾毫秒，過程需要大約100MB的ram。

我只是想了解這裏發生了什麼，這是正常的，還是有一種特定的方式可以索引字符類型以獲得更好的性能？

繼承人我的一些SQL語句：

CREATE TABLE data 
(
    tableID int NOT NULL IDENTITY PRIMARY KEY, 
    tag char(21) NOT NULL UNIQUE, 
    dataColumn1 datetime NULL, 
    dataColumn2 char(8) NULL, 
    lastModified datetime NOT NULL 
)

從C＃參數化查詢：

SELECT tag FROM data WHERE tag = @tag;

感謝您的幫助。

來源

2010-01-16 Matt

對我來說看起來沒問題，假設這是一個準確的表示方式，並且有'tag'上的索引......另外一個建議，在測試每個查詢之前嘗試'DBCC FREEPROCCACHE'和'DBCC DROPCLEANBUFFERS'，確定它沒有使用緩存結果。另請參閱是否可以發佈執行計劃（'SET SHOWPLAN ON'）。如果您在計劃中看到聚集索引查找（或常規索引查找）並且沒有掃描，書籤查找或RID查找，那麼可能沒有多少可以提高速度。 – Aaronaught 2010-01-16 02:02:54

這實際上並不罕見，SQL處理數字要比字符好得多。 bigInt字段使用8個字節，它們整齊地放入內存頁面中。一個字段需要21個字節，幾乎將存儲量的三倍放到一個索引中。

另一個考慮，是索引聚集？聚集索引的執行速度比非聚集索引快得多。除了簡單的一般性陳述外，還有很多額外的因素需要考慮，數字在指數中的表現會更好並且佔用更少的空間。

來源

2010-01-16 00:45:49 Sparky

有道理，它會變慢，但預計它只會稍微慢一點。我有一個主鍵索引以及有問題的列索引。由於我只選擇單行，因此兩者都是非羣集的。我的理解是，聚集索引只能提高範圍查詢的性能。由於我還有很多更新，我認爲聚集查詢會帶來大磁盤I/O性能影響。 – Matt 2010-01-16 01:05:03

我的錢是在你試圖對焦炭塔的一些功能，即類似查詢的可能性：

SELECT Column 
FROM Table 
WHERE UPPER(CharColumn) = 'ABC'

很顯然，我只是猜測，但是這是性能的常用源問題與char/varchar/nvarchar列。如果你正在寫這樣的查詢，你必須認識到，將列封裝在函數中會阻止SQL Server執行索引查找。

還要考慮到實際返回的行數;表中有900萬行不一定很多，但即使是100,000行也是結果集中的一大部分。有時候瓶頸只是把所有的結果都放在一起。

如果這些都不能描述您的問題，那麼我建議您更新您的文章，並提供一些有關架構，索引和運行速度慢的查詢的信息。還有進一步的優化你可以做，儘管SQL Server 2000年已經開始，所以你的選擇是有限的。

根據您發佈的方案，假設你對tag列的索引，您只選擇tag以及可能不包括在內沒有其他列，您WHERE條件是在一個簡單的等式tag列，並且返回的結果數量相當小，我不認爲您可以進行任何進一步的優化。你幾乎將這個簡化爲最簡單的情況。

來源

2010-01-16 00:57:15 Aaronaught

我直接在列上選擇和更新單行而不使用任何函數。有問題的表上有兩個非聚集索引。 21位數列上的一個主鍵和一個簡單索引。 – Matt 2010-01-16 01:07:12

更具體的內容仍然有幫助。我無法分辨索引是否爲覆蓋索引，並且有時會有很多索引（或較大的索引）會使更新操作變慢一點。我想我可以給你一個更好的答案，關於模式，索引和查詢的具體信息（如果你想要匿名的話）。 – Aaronaught 2010-01-16 01:26:52

也應該知道CHAR（21）字段用空格填充到其長度，例如，你不會在其中找到一個帶有「ABC」的字段 - 相反，它會包含「ABC ............................ ...「（這裏代表一個空格） – 2010-01-16 11:38:17

字符比較有點慢 - 必須考慮排序順序 - 更不用說21字符字符串和bigint（8字節）之間的物理尺寸差異。索引查找不能高效，因爲它必須評估char（21）值中的每個字節，決定該字符的排序順序，然後決定如何與您要查找的值中的匹配字符進行比較。

由於數據（包括索引頁iirc;我不是DBA）聚集索引對於幾乎任何查詢都會表現更好，因爲它們是按照磁盤尋道順序執行的。或者至少更接近它。

來源

2010-01-16 01:23:52 DaveE

實際上，聚集索引* scan *將比常規索引掃描慢;這就是我爲什麼希望得到更多細節的原因。 – Aaronaught 2010-01-16 01:47:06

SQL Server 2000表優化

回答

相關問題