如何提高數據庫的性能？

Question

我在公司裏多次設計過數據庫。爲了提高數據庫的性能，我只查找規範化和索引。

如果您被要求提高一個數據庫的性能，這個數據庫有大約250個表格和一些包含數百萬條記錄的表格，您會尋找什麼不同的東西？

在此先感謝。

Answer 1

優化邏輯設計

的邏輯電平是有關查詢和表本身的結構。嘗試首先將其最大化。目標是在邏輯層次上訪問儘可能少的數據。

• 擁有最高效的SQL查詢
• 設計，支持應用程序的需要（如類型列等）
• 設計權衡，以支持一些使用情況下比其他
更好的邏輯架構
• 關係約束
• 正常化

優化物理設計

物理層面處理非邏輯考慮，如索引類型，表格參數等。目標是優化始終是瓶頸的IO。調整每張桌子以適應它的需要。小表可以在DBMS緩存中永久加載，低寫入率的表可以具有與高更新率的表不同的設置，以佔用更少的磁盤空間等。根據查詢，可以使用不同的索引等。您可以透明地與物化視圖非規範化數據等

• 表paremeters（分配大小等）
• 指標（結合，類型等）
• 全系統的參數（高速緩存大小等）
• 分區
• 非規範化

先嚐試改進邏輯設計，然後進行物理設計。 （但兩者之間的界限是模糊的，所以我們可以爭論我的分類）。

優化維護

必須將數據庫操作正確停留儘可能高效。這包括一些可能影響性能的維護措施，例如，

• 保持統計最新
• 重新排序的關鍵定期表
• 磁盤維護
• 系統所有的東西有一個岩石

Answer 2

對於標準化和索引編制工具包，如果使用非常大的表格，您可能還需要考慮分配表格的優缺點。但你已經有關鍵的那個。

Answer 3

如果某個查詢非常關鍵，您可能需要考慮-normalizing，以減少每個查詢的表查找次數。 除此之外，如果您需要的性能超出了索引和反規範化的範圍，您可能需要查看程序端：緩存，優化查詢/存儲過程等。

Answer 4

這是一個非常含糊的問題。

你說你在尋找索引，但你不能單獨看索引。您必須查看正在運行的查詢，執行計劃，正在使用的索引以及如何使用它們。 Profiler工具可以幫助您確定哪些查詢效率低下。

除此之外 - 確保設置維護計劃。您應該至少每週在繁忙的事務數據庫中更新統計信息和碎片整理/重建索引。

如果您有基礎架構，請查看您的文件和文件組設置。如果可能的話，您應該嘗試將大型且經常用於不同物理驅動器的表和/或索引。如果你有任何非常大的表，你可能會考慮對它們進行分區。

如果你仍然有性能問題，非規範化有時可以幫助 - 但這一切都取決於情況。

我將停在那裏 - 不希望這個答案成爲世界上最隨機的SQL性能提示列表。我建議你更具體地考慮你認爲性能問題的位置，並告訴我們更多關於數據庫的信息（規模，當前索引策略，交易頻率，任何需要生成的大型報告等）。

Answer 5

In爲了提高性能，您需要首先監控數據庫。您可以跟蹤並在sql server profiler中加載它，以找出哪些是最慢的查詢。之後，你可以專注於他們。

您還可以使用動態視圖和管理功能來找出哪些索引丟失。您還將能夠檢索有關現有索引的統計信息，如索引使用情況和錯過的索引。

Answer 6

優化用於訪問該數據庫的查詢是最重要的。只需添加索引，您不保證查詢將使用它們。

Answer 7

壓縮。對於我嘗試過的絕大多數負載來說，使用壓縮技術是一次巨大的免費搭乘。數據量減小意味着I/O的減少意味着更好的吞吐量。在SQL Server 2005中，壓縮選項是有限的（vardecimal）。但是我會認真考慮單獨升級到2008年的頁面壓縮。或者2008 R2，如果經常使用nvarchar來獲得Unicode壓縮。

數據保留。建立保留策略並積極刪除舊數據。數據量少意味着更少的I/O，意味着更好的吞吐量。通常這被看作是可操作的，而不是設計，但我喜歡把這個問題看作應用程序設計問題。

當然，我假設您已經監視每個查詢，以確保沒有愚蠢的端到端表掃描。

還有更多的性能助推器大多運營或部署，而不是設計：維護（碎片整理，索引重建等），I/O和存儲設計等

最後但並非最不重要的瞭解各種又將隱藏成本鍵解決方案。比如說，複製或數據庫鏡像。

Answer 8

我們還沒有寫過一個性能位：

硬件。

數據庫是強烈的I/O驅動。轉向更快的硬盤應該會提高數據庫查詢的速度。將數據庫拆分成許多快速硬盤驅動器可能會進一步改善它。

Answer 9

有很多事情你可以做，其中很多已經建議上面。一些我會看（按此順序）：

• 錯誤/日誌 - 許多數據庫引擎都有報告工具，指出數據庫中的問題區域。從這裏開始，看看是否有任何事情可以馬上關注。
• 數據保留 - 檢查業務規範應該保留多長時間的數據，確保將任何較舊的數據移出到數據倉庫以保持表的大小。 （爲什麼要保留5年的數據，如果只需要最後3個月？）
• 尋找表掃描，索引數據，如果它會幫助（你必須衡量這與表寫入）。您的服務器日誌可能可以幫助您查找表掃描。
• 工作的原子元素，是否有一些寫入在達到提交點之前在不同的表上保留鎖定？這些工作要素可以簡化還是提交點以加快績效？這是您需要開發人員查看代碼的地方。
• 查找長時間運行的SQL語句，可以使它更高效嗎？有時結構不佳的查詢可能會導致應用程序停滯。您可能需要建議編碼更改以提高性能。
• dba realm：看看如何分配表格：頁面大小，多個細分等。這就是供應商的診斷工具派上用場的地方，因爲他們通常可以建議如何根據使用歷史記錄來構建表格。有經驗的dba在這裏很有用。
• 尋找硬件/網絡瓶頸。這是你需要硬件人員的地方。 :)

這些都是非常高的水平，我還會看看你的數據庫引擎的供應商建議作爲性能改進。

另外，我會根據我的老闆願意支付的費用以及我有多少時間來計算一份這樣的清單。 ;）

希望這會有所幫助。

Answer 10

我在MySpace上卷是「服務器性能增強DBA /開發人員「。我想說規範化和索引是高性能數據庫的一個要求，但是你必須真正分析你的表結構和索引，才能真正解開數據庫設計的威力。

這裏有一些建議，我會爲你;

1. 瞭解數據庫引擎。通過對下劃線I/O結構的瞭解，在設計適當的索引或表格方面有很長的路要走。通過使用PerfMon和Profiler，以及您對讀/寫I/O的瞭解，您可以在理論上形成完善的表格/索引解決方案。

2. 瞭解羣集和非聚集索引以及何時使用它們之間的差異。

3. 使用sys.dm_os_waiting_tasks和sys.dm_os_wait_stats動態管理視圖。他們會告訴你應該在哪些方面減少等待時間。

4. 使用DBCC SET STATISTICS IO/TIME ON，並評估執行計劃，看看是否一個查詢減少或增加頁面的讀取次數或持續時間。

5. DBCC SHOWCONTIG會告訴你，如果你的表是大量碎片。從性能的角度來看，開發人員和小型數據庫管理員通常忽略這一點 - 但是，這會對讀取的頁面數量產生非常大的影響。如果一個表的頁面密度達到20％，那麼這意味着您讀取的數據大約是數據的5倍，否則，如果該表及其索引經過了碎片整理，那麼數據將是該數據的5倍。

6. 評估髒讀（nolock，未讀未讀）。如果您可以在讀取時取消毫秒精度，請保存鎖！

7. 考慮取出不必要的外鍵。它們在Dev環境中非常有用，而不是在高性能事務處理系統中。

8. 分區的大表有很大的不同 - 只是如果設計得當。

9. 應用程序更改 - 如果您可以爲異步事務計劃批量更新，請將它們放入無索引堆並按計劃進行處理，這樣您就不會持續更新大量查詢的表。

10. 永遠始終永遠!!!使用相同的數據類型變量來查詢目標列;例如，以下語句用BIGINT變量用於SMALLINT柱：

DECLARE @i BIGINT 組@i = 0

SELECT * FROM MyTable的其中Col01SmallInt> = @i

在評估索引/表頁面的過程中，查詢引擎可能會選擇將smallint列數據轉換爲bigint數據類型。相反，改變你的varialbe類型，或者至少在你的搜索條件下將它轉換爲smallint。

1. SQL 2005/08爲您提供管理應用程序中的「報告」，查看關於您的索引如何執行的報告。他們正在被掃描，尋找？你最後一次表掃描是什麼時候？如果它是最近的，你的索引沒有完成所有必要的查詢。如果你有一個很難被使用（查找或者掃描）但是不斷更新的索引，考慮放棄它。它可以爲你節省大量不必要的行鎖和鍵鎖。 ..

這是所有我能想到的把我的頭頂部。如果遇到更具體的問題，我會給你一個更具體的答案。