索引可以幫助查詢更快地找到所需的記錄，從而避免整個表的掃描。如果索引引用的列可以完全包含查詢所需的字段，則此類型的索引稱為覆蓋索引，它可以滿足查詢要求而無需回讀（對于非聚集索引表）。一些通用要求（例如排序，分組和區分）可以有效地使用索引。那么設計數據庫時如何選擇鍵和索引？最詳細的數據庫索引選擇在這里。

　　設計數據庫時如何選擇鍵和索引?

　　數據采掘要預先計劃

我所在的某一客戶部門一度要處理 8 萬多份聯系方式，同時填寫每個客戶的必要數據（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數據庫的運行速度。然后我意識到特定的組查詢和信息采掘既不準確速度也不快。結果只好在主索引中重建而且合并了數據字段。我發現有一個指示計劃相當關鍵--當我想創建系統類型查找時為什么要采用號碼作為主索引字段呢?我可以用傳真號碼進行檢索，但是它幾乎就象系統類型一樣對我來說并不重要。采用后者作為主字段，數據庫更新后重新索引和檢索就快多了。

可操作數據倉庫（ODS）和數據倉庫（DW）這兩種環境下的數據索引是有差別的。在 DW 環境下，你要考慮銷售部門是如何組織銷售活動的。他們并不是數據庫管理員，但是他們確定表內的鍵信息。這里設計人員或者數據庫工作人員應該分析數據庫結構從而確定出性能和正確輸出之間的最佳條件。

　　使用系統生成的主鍵

這類同技巧 1，但我覺得有必要在這里重復提醒大家。假如你總是在設計數據庫的時候采用系統生成的鍵作為主鍵，那么你實際控制了數據庫的索引完整性。這樣，數據庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。

采用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。

分解字段用于索引

為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進行索引。索引將加快 SQL 和報表生成器腳本的執行速度。比方說，我通常在必須使用 SQL LIKE 表達式的情況下創建報表，因為 case number 字段無法分解為 year、serial number、case type 和 defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。

　　鍵設計 4 原則

· 為關聯字段創建外鍵。

· 所有的鍵都必須唯一。

· 避免使用復合鍵。

· 外鍵總是關聯唯一的鍵字段。

　　別忘了索引

索引是從數據庫中獲取數據的最高效方式之一。95% 的數據庫性能問題都可以采用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列[字段]采用非成組索引。不過，索引就象是鹽，太多了菜就咸了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。

大多數數據庫都索引自動創建的主鍵字段，但是可別忘了索引外鍵，它們也是經常使用的鍵，比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。

　　不要索引常用的小型表

不要為小型數據表設置任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。

　　不要把社會保障號碼（SN）或身份證號碼（ID）選作鍵

永遠都不要使用 SSN 或 ID 作為數據庫的鍵。除了隱私原因以外，須知政府越來越趨向于不準許把 SSN 或 ID 用作除收入相關以外的其他目的，SSN 或 ID 需要手工輸入。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然后從頭開始。

我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當然盡管這么做是非法的。而且人們也都知道這是非法的，但他們已經習慣了。后來，隨著盜取身份犯罪案件的增加，我現在的同行正痛苦地從一大攤子數據中把 SSN 或 ID 刪除。

　　不要用用戶的鍵

在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。這樣做會迫使你采取以下兩個措施：

· 在創建記錄之后對用戶編輯字段的行為施加限制。假如你這么做了，你可能會發現你的應用程序在商務需求突然發生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當用戶在輸入數據之后直到保存記錄才發現系統出了問題他們該怎么想?刪除重建?假如記錄不可重建是否讓用戶走開?

· 提出一些檢測和糾正鍵沖突的方法。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的數據和商業/用戶界面層之間的隔離。

所以還是重提一句老話：你的設計要適應用戶而不是讓用戶來適應你的設計。

不讓主鍵具有可更新性的原因是在關系模式下，主鍵實現了不同表之間的關聯。比如，Customer 表有一個主鍵 CustomerID，而客戶的定單則存放在另一個表里。Order 表的主鍵可能是 OrderNo 或者 OrderNo、CustomerID 和日期的組合。不管你選擇哪種鍵設置，你都需要在 Order 表中存放 CustomerID 來保證你可以給下定單的用戶找到其定單記錄。

假如你在 Customer 表里修改了 CustomerID，那么你必須找出 Order 表中的所有相關記錄對其進行修改。否則，有些定單就會不屬于任何客戶--數據庫的完整性就算完蛋了。

如果索引完整性規則施加到表一級，那么在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數據庫內所有關聯的記錄。而這一過程往往錯誤叢生所以應該盡量避免。

　　可選鍵（候選鍵）有時可做主鍵

記住，查詢數據的不是機器而是人。

假如你有可選鍵，你可能進一步把它用做主鍵。那樣的話，你就擁有了建立強大索引的能力。這樣可以阻止使用數據庫的人不得不連接數據庫從而恰當的過濾數據。在嚴格控制域表的數據庫上，這種負載是比較醒目的。如果可選鍵真正有用，那就是達到了主鍵的水準。

我的看法是，假如你有可選鍵，比如國家表內的 state_code，你不要在現有不能變動的唯一鍵上創建后續的鍵。你要做的無非是創建毫無價值的數據。如你因為過度使用表的后續鍵[別名]建立這種表的關聯，操作負載真得需要考慮一下了。

　　別忘了外鍵

大多數數據庫索引自動創建的主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中的記錄及其關聯記錄時每次都會用到。還有，不要索引 memo/notes 字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引占據大量的數據庫空間。

上述就是關于設計數據庫時如何選擇鍵和索引的全部內容介紹，想了解更多關于數據庫的信息，請繼續關注中培偉業。