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