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