這是一個表的糟糕索引策略嗎？

有問題的表是供應商軟件在我們的網絡上使用的數據庫的一部分。該表包含有關文件的元數據。表的模式如下這是一個表的糟糕索引策略嗎？

Metadata 
ResultID (PK, int, not null) 
MappedFieldname (char(50), not null) 
Fieldname (PK, char(50), not null) 
Fieldvalue (text, null)

ResultID和Fieldname上有一個聚集索引。該表通常包含數百萬行（在一種情況下，它包含5億）。該表由24名工作人員組成，每個工作人員在處理數據時運行4個線程。這導致許多非順序插入。稍後處理後，我們的一些內部軟件會將更多數據插入此表中。給定表的碎片至少爲50％。在最大的桌子的情況下，它是在90％。我們沒有DBA。我知道我們迫切需要一個數據庫維護策略。就我的背景而言，我是在這家公司兼職的大學生。

我的問題是，這是一個聚集索引最好的方式去呢？是否應該考慮另一個指標？有沒有這種類型和類似的臨時DBA任務的良好參考？

來源

2009-02-15 llamaoo7

索引策略完全取決於您如何查詢表以及您需要從各個查詢中獲得多少性能。

聚簇索引可能會強制在進行亂序插入（這稱爲「頁面拆分」）時在物理上（磁盤上）重新排序行。在索引頁上沒有可用空間的大表中，這可能需要一些時間。

如果你不是絕對是需要跨越兩個字段的聚集索引，那麼不要。如果它更像是一種UNIQUE約束，那麼通過一切手段使它成爲一個UNIQUE約束。這些人不需要重新分類。

確定對錶的典型查詢是什麼，並相應地放置索引。你有更多的索引，更慢的數據更改（插入/更新/刪除）將會消失。不要創建太多的索引，例如在不太可能被過濾/排序的字段上。

創建組合索引僅在一起過濾/排序的字段上，通常。

來源

2009-02-15 19:52:05 Tomalak

典型的查詢將是非順序插入，沒有更新，沒有刪除，並且選擇的頻率不如插入（寫入很多，讀取很少）。我想我需要閱讀並定期查看哪些查詢正在運行。 – llamaoo7 2009-02-15 19:57:28

這聽起來像是刪除聚集索引的好方案。另外，請查看索引填充因子。確保有足夠的空間來減少索引頁拆分的需要。默認的填充因子80可能對您的需求太高。 – Tomalak 2009-02-15 20:06:08

就我所見，聚集索引是可以的。關於其他索引，您將需要提供在此表上運行的典型SQL查詢。只需創建一個索引就不是一個好主意。您正在討論碎片和索引，是否意味着您懷疑查詢執行速度變慢？或者你只是想縮小/碎片整理數據庫/索引？

在下班時間有一項任務需要對索引進行碎片整理是一個不錯的主意，不過您必須考慮頻繁/隨機插入操作，因此在表中留有一些空餘空間以防止它受到傷害頁面拆分（這會影響性能）。

來源

2009-02-15 20:02:07 liggett78

看看你的疑問 - 那些打擊數據的人。索引是否會提供服務？如果您按照（ResultID，FieldName）的順序具有索引，但是您正在查詢給定Fieldname的可能ResultID值，那麼DBMS很可能會忽略該索引。相比之下，如果您有（FieldName，ResultID）上的索引，它可能會使用索引 - 當然可以用於簡單值查找（WHERE FieldName = 'abc'）。在唯一性方面，兩個指數都表現良好;在查詢優化方面，存在（至少潛在的）巨大差異。

使用EXPLAIN來查看您的查詢如何由您的DBMS處理。

集羣與非集羣索引通常是DBMS中的二階優化效果。如果索引是正確的，則聚集索引與非聚集索引之間存在一個小差異（對於聚集索引，更小的更新罰分作爲對較小選擇時間的補償）。在擔心二階效應之前，確保一切都已經過優化。

來源

2009-02-15 22:02:24

我知道我們非常需要一個數據庫維護策略。

+1用於確定需要

至於我的背景，我是一個大學生，在這家公司工作的兼職

堅持學習，獲得經驗，但在此期間找一位經驗豐富的顧問。

該表是通過運行4個線程每個

我想這是在工作日相當關鍵任務，和停機時間是個壞消息24名工人居住？如果是這樣的話，不要使用它。

上有ResultID和字段名

一個聚集索引ResultID在PK的第一列，因爲你說明什麼？

如果是這樣，我敢打賭它沒有足夠的選擇性，並且根據查詢的需求，PK字段的順序應該交換（儘管這個複合鍵看起來是一個糟糕的選擇集羣PK）

什麼結果：

SELECT COUNT（*），COUNT（DISTINCT ResultID）FROM MyTable的

如果第一計數，比方說，4個大如第二或更重要的是，由於ResultsID的選擇性較低，因此您最有可能獲得掃描優先搜索，並且一些簡單的更改將會給予巨大的性能改進。

此外，字段名是相當寬（50個字符），所以任何二級索引將有50 + 4個字節添加到每個索引條目。這些字段是否真的是CHAR而不是VARCHAR？

就我個人而言，我會考慮增加葉頁的密度。在90％的情況下，您只會留下一些差距 - 可能每頁只有一個。但是對於一張5億行的大型表格，較高的封裝密度可能意味着樹中的層次更少，因此需要更少的查找。相反，對於給定頁面，幾乎每個插入都需要分頁。這將有利於集羣插入，因此可能不合適（因爲您的插入數據可能未集羣）。像很多事情一樣，你需要做一個測試來確定哪個索引密鑰密度最好。SQL Server具有幫助分析查詢如何被解析，它們是否被緩存，它們引起的表的掃描次數，哪些查詢「運行緩慢」等等的工具。

請諮詢顧問來看看並給你一些建議。這不是一個回答這裏的問題將給你一個安全的解決方案來實現。

對於每天擁有500萬行數據表和插入數據流的表，您真的需要仔細考慮維護策略。對不起，但我對進入這種狀態的公司感到非常沮喪。

該表需要進行碎片整理（如果沒有聚簇索引，選項會變得更少，因此請保留該選項，直到您確定存在更好的候選項爲止）。「在線」碎片整理方法將對性能產生適度影響，並且可能會突然消失 - 如果它們超出時間/ CPU限制（儘管這很可能需要一些編程），可以安全地中止。如果你有一個「安靜」的插槽，然後用它進行表碎片整理並更新索引的統計信息。不要等到週末才試着去做所有的桌子 - 在每天的安靜時間（大概是在夜間）儘可能多/儘可能多地做。

對錶進行碎片整理可能會導致事務日誌使用量大幅增加，因此請確保任何TLogs都經常備份（我們有10分鐘的TLog備份策略，我們在表碎片整理過程中每分鐘增加一次）磁盤碎片整理過程不會成爲所需的Tlog空間的定義！）

來源

2009-02-15 22:39:34 Kristen

這是一個表的糟糕索引策略嗎？

回答

相關問題