SQL Server選擇索引之查詢VS 的性能修改
以下的文章主要描述的是SQL Server選擇索引之查詢VS 的性能修改，I/O主要是決定查詢性能的最重要的因素。SQL Server設計者的挑戰是構建物理數據模型來對高效的數據訪問進行提高。在數據庫表中創建索引允許SQL Server降低I/O數來訪問數據。
在邏輯和物理模型階段定義有用的索引是關鍵。SQL Server優化器嚴重依賴于索引鍵值的分布和索引密度來決定查詢使用哪一個索引。SQL Server優化器能使用查詢中的多個索引（通過索引交叉）降低I/O的數量來檢索信息。若缺少索引，優化器執行表掃描，從IO角度來講，它花費的代價更高。
盡管索引提供了一種快速訪問數據的途徑，但它們減緩了數據修改語句，因為當插入、修改和刪除時，需要額外的負擔來維護索引。
在決策支持系統中（DSS），定義更多的索引能幫助你的查詢并且不會帶來太多的性能問題，因為這些數據相對來講是靜態的并且不會頻繁修改。你典型地會加載數據、創建索引。只要你需要索引來支持用戶查詢，并且它們能獲得相當不錯的響應時間，太多的索引的缺點只是不被使用的索引所浪費的空間。
另一方面，在OLTP環境下，太多的索引可能導致相當大的性能下降，特別是，假如一個表中索引數量超過4或5個。仔細想下，每個單行插入至少是一個數據頁的寫或者是為表中的每個索引所進行的更多索引頁寫（依賴于頁分裂是否發生）。
若有8個非聚集索引，單行插入最少將有9次寫數據庫，所以，對OLTP環境，你必須創建盡可能少的索引——典型地需要支持修改和刪除操作的索引和你的關鍵查詢，以及強制你唯一性約束的索引。
所以在理想世界中，自然的解決方法是，在DSS環境下創建許多SQL Server選擇索引，在OLTP環境下創建少許索引。不幸的是，在真實世界中，你典型地需要支持DSS和OLTP。你如何來解決兩種環境下的對索引要求的競爭？為了滿足DSS和OLTP應用的索引需求需要一些平衡技術。
其中一種方法是分別創建兩個數據庫——一個為DSS應用另外一個為OLTP。明顯，這種方法需要一些方法來保持數據庫的同步。這種方法選擇依靠如何更新***的DSS數據庫。假如你更新的時間總是滯后的，你可以考慮使用dump-and-load機制，比如Log Shipping 或者周期性地數據庫存儲。如果你的DSS系統要求up-to-the -minute 并發，你可能會考慮使用replication技術。
另外一種選擇是在日常工作中只為OLTP提供要求的索引。在忙的時間創建DSS查詢和報表需要的索引。當DSS報表完成后，刪除這些額外的報表。注意這種方法假定創建額外的索引需要的時間可以用加速DSS查詢所獲得時間得到補償。
所以，小心選SQL Server擇索引以在數據搜索和數據修改性能之間提供一個平衡。應用的環境通常決定著索引的選擇。例如，如果應用主要是OLTP類型，創建太多的索引可能會影響系統的性能。另一方面，應用可能是一個DSS類型的，在這種情況下，可以創建多一些的索引。
上述的相關內容就是對SQL Server選擇索引之查詢VS 修改性能的描述，希望會給你帶來一些幫助在此方面。
【編輯推薦】
