是否向SQL Server添加索引是一個壞主意？

我們有一個沒有定義索引的中型SQL Server應用程序。甚至不在身份欄上。我建議我們這個價格適中的應用顧問，或許我們可以通過在適當的領域創建一些索引來獲得更好的性能（特別是在我們的數據庫增長時），他說：是否向SQL Server添加索引是一個壞主意？

「索引將顯着影響應用程序和客戶的其他領域不應該在任何情況下創造它們。「

有人聽說過這樣的事嗎？在任何情況下，不會產生任何索引？我可以看到這個應用程序沒什麼特別的 - 它有int標識列，然後是很多字符串列，一堆關係表，但沒有什麼特別的或奇怪的，我可以看到。

謝謝！

[編輯：標識列沒有使用「身份規範」，他們似乎由程序設定，尋找與Management Studio中的數據庫，我可以找到NO指數...]

跟進：在一次會議上，我問了生產這款產品的公司的首席執行官（首席架構師），他的迴應是，他們覺得中小型部署，與維護索引相關的開銷會對整體用戶造成更多負面影響經驗（應用程序做了很多寫操作）比索引的好處會抵消，但對於大型數據庫，它們確實創建索引。技術支持人員過分熱心，對他的回答非常無益。謎團已揭開。

來源

2010-05-21 Aerik

僱用我，我會爲你創建索引。 14年的Sybase/SQL Server經驗告訴我創建這些！darn！索引。除非您的表格每個記錄少於500條記錄。

我的想法是，一個索引散列節點大致尺寸爲1000

你需要看出來的是你的顧問是否已歸一化的表中的其他事情。也許，這個表格有500個字段/列，其中包含多個概念實體或者全部概念實體。這就是爲什麼他對創建索引感到緊張的原因，因爲如果表中有12個概念實體，那麼至少有12組索引 - 在這種情況下，他絕對是真實的 - 在任何情況下都不會......等等等等。但是，如果他確實每列有500列或可檢測到多個概念實體 - 他是一個非常糟糕的數據設計工程師。在我所有的時間裏，我與更有經驗的數據工程師一起工作，我們的桌子很少超過20列偏低5人，平均10人。有時候爲了提高性能，我們允許在一個表中混合兩個實體，或者將行的出現水平化到一個表的列中。

當你看着桌子的設計，你可以用未經訓練的眼睛看到Product，Project，BuildSheet，FloorPlan，Equipment等記錄全部捲成一長排。您不能將所有這些實體混合在一個表中。

這是我知道他爲什麼可以建議你不要有索引的唯一原因。如果他這樣做了，那麼你應該知道他是在欺騙性地向你的公司展示他的數據設計技能，你應該立即將他從你的每週合同費用中扣除。好吧，在閱讀larry的帖子之後 - 我也同意他的看法。

來源

2010-05-21 06:27:48

有一些表格有很多列，但它們似乎並不包含多個概念實體。較大的表格（按列顯示）具有許多屬性數據，這些數據似乎在該表格的合理組中。 – Aerik 2010-05-22 14:59:06

我見過我認爲是30列的好桌子。但是，桌子遵循泊松分佈，集中在5左右。 – Joshua 2010-05-23 16:23:15

的ID列不使索引聽起來確實不尋常，我會找個不包括他們聞到腥很正當的理由。

你應該知道，如果你正在做一個大批量提交到數據庫中，增加更多的指標會影響插入的速度，但在id的指數？哇。

這將是很好得到的究竟是如何增加額外的索引可能導致雖然問題的更好的理由。

來源

2010-05-21 01:14:29 spender

您有磁盤空間可用嗎？我見過索引比表格更重要的情況。

但是，沒有任何索引存在！除了所有讀取操作需要整個表格之外，不能有這種情況。

來源

2010-05-21 01:16:22 Joshua

我們有足夠的磁盤空間。我們的情況非常典型：大表，讀操作通常尋求一個特定的行，或者執行SELECT TOP ... ORDER BY查詢。所以它不是讀整個表。 – Aerik 2010-05-21 01:37:16

其實它是 - 沒有索引。沒有任何索引，它只能讀取整個表的任何內容。 – TomTom 2010-05-21 06:52:46

SELECT TOP ... ORDER BY ORDER BY列上的索引大大受益。 – Joshua 2010-05-21 15:03:40

無論如何，具有關鍵約束的列將具有隱式索引。所以如果你總是用主鍵選擇，那麼添加更多索引就沒有意義了。如果您按照其他標準進行選擇，那麼在您查詢的列上添加索引是有意義的。

這也取決於你的數據如何插入重的。如果插入次數多於查詢次數，那麼保持索引更新的開銷會使插入速度變慢。

但是說你「不應該創建[索引]在任何情況下」是有點多。

我建議是，你運行SQL Server Profiler工具，你的一些疑問。該工具將推薦添加哪些索引對性能產生最大影響。

來源

2010-05-21 01:16:53

該應用程序肯定偏向於讀取而不是寫入 - 它似乎做了很多單獨的SELECTs而不是利用連接 – Aerik 2010-05-21 01:32:59

我已經添加了一些關於SQL Server Profiler工具的信息。比價格昂貴的「顧問」要便宜得多，而且實際上也很有效;） – 2010-05-21 01:42:57

感謝分析器工具的建議 - 我之前只做過「手動」優化。我認爲我們真正的問題在於我們是否願意違背顧問的建議。真正的憤怒在這裏是他從公司寫的應用程序。 – Aerik 2010-05-22 14:56:10

更慢的數據插入和修改的索引越多。確保在適當的時候添加索引並編寫可以利用這些索引的查詢，而且如果索引的選擇性水平較低，則不會有效使用

來源

2010-05-21 01:19:25 SQLMenace

在大多數普通應用程序，索引對插入性能的影響有點不成問題。創建索引通常會更好，如果插入性能急劇下降（可能不會），您可以嘗試其他方法。顯然有一些例外，你應該更加小心，比如用於記錄實例的表。

如前所述，磁盤空間可能是一個問題。

創建不相關的索引（例如重複項）也會浪費微秒並偶爾會導致錯誤的查詢執行計劃。

我看到的另一個問題是奇怪的代碼第三方應用程序在運行時生成數據庫的一部分，並且可以刪除或阻塞他們不知道的索引。

儘管絕大多數情況下，精心挑選的指標只會帶來好處。

來源

2010-05-21 01:23:35 cbp

有這樣的事情，過度索引，特別是在非常大的表的INSERT和UPDATE重度應用程序。因此，標題中對問題的回答是肯定的，添加索引有時候是一個糟糕的主意。

這與您在問題主體中提出的問題完全不同，即「在SQL Server數據庫中沒有索引是否正常？」。答案是，除非您將數據庫用作「只寫」系統，其中添加了數據，但只有在批量提取並轉換爲另一個數據存儲庫後才能讀取數據庫，這非常不尋常，不會在數據庫。

您的顧問陳述很奇怪，讓我相信您可能在描述中留下了一些重要信息。如果沒有，我會說他是瘋了。

來源

2010-05-21 01:44:30

我真的懷疑他正在掩蓋這樣一個明顯的疏忽 - 他的公司寧願給我們不好的建議，也不願意讓我們知道他們錯過了他們設計中的數據庫索引。 – Aerik 2010-05-21 01:59:15

要麼，要麼他是個白癡。在很多項目中，也看到了這一點 - 包括一些總Bunkhead數據庫專家將所有字段的TEXT字段設置爲長度不是對象模型的一部分（ergo：不可轉位 - 即使是產品編號）。人們喜歡那個AREA，有時甚至是顧問。可悲的是， – TomTom 2010-05-21 06:55:08

如果我必須沒有長度，我會使用postgresql，其中varchar（2000000000）是有效和可索引的，並且如果結果爲varchar（100）是您所需要的，那麼花費不會超過varchar（100）。 – Joshua 2010-06-15 19:53:57

是否向SQL Server添加索引是一個壞主意？

回答

相關問題