�、� 非聚族索引(Nonclustered Index)：與聚族索引相比，占用空間大，而且效率低。選擇策略是，被用于Where子句的列：包括范圍查詢、模糊查詢(在沒有聚族索引時)、主鍵或外鍵列、點(指針類)或小范圍(返回的結果域小于整表數據的20%)查詢;被用于連接Join*作的列、主鍵列(范圍查詢);被用于Order by和Group by子句的列;需要被覆蓋的列。對只讀表建多個非聚族索引有利。索引也有其弊端，一是創建索引要耗費時間，二是索引要占有大量磁盤空間，三是增加了維護代價(在修改帶索引的數據列時索引會減緩修改速度)。那么，在哪種情況下不建索引呢?對于小表(數據小于5頁)、小到中表(不直接訪問單行數據或結果集不用排序)、單值域(返回值密集)、索引列值太長(大于20bitys)、容易變化的列、高度重復的列、Null值列，對沒有被用于Where子語句和Join查詢的列都不能建索引。另外，對主要用于數據錄入的，盡可能少建索引。當然，也要防止建立無效索引，當Where語句中多于5個條件時，維護索引的開銷大于索引的效益，這時，建立臨時表存儲有關數據更有效。
批量導入數據時的注意事項：在實際應用中，大批量的計算(如電信話單計費)用C語言程序做，這種基于主外鍵關系數據計算而得的批量數據(文本文件)，可利用系統的自身功能函數(如Sybase的BCP命令)快速批量導入，在導入數據庫表時，可先刪除相應庫表的索引，這有利于加快導入速度，減少導入時間。在導入后再重建索引以便優化查詢。
(4)鎖：鎖是并行處理的重要機制，能保持數據并發的一致性，即按事務進行處理;系統利用鎖，保證數據完整性。因此，我們避免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務的長短;要避免批量數據同時執行，尤其是耗時并用到相同的數據表。鎖的征用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在等待。若用戶數增加，則Server的性能下降，出現“假死”現象。如何避免死鎖呢?從頁級鎖到行級鎖，減少了鎖征用;給小表增加無效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響，可選擇合適的聚族索引把數據分配到不同的頁面;創建冗余表;保持事務簡短;同一批處理應該沒有網絡交互。
(5)查詢優化規則：在訪問數據庫表的數據(Access Data)時，要盡可能避免排序(Sort)、連接(Join)和相關子查詢*作。經驗告訴我們，在優化查詢時，必須做到：
�、� 盡可能少的行;
�、� 避免排序或為盡可能少的行排序，若要做大量數據排序，最好將相關數據放在臨時表中*作;用簡單的鍵(列)排序，如整型或短字符串排序;
�、� 避免表內的相關子查詢;
�、� 避免在Where子句中使用復雜的表達式或非起始的子字符串、用長字符串連接;
�、� 在Where子句中多使用“與”(And)連接，少使用“或”(Or)連接;
�、� 利用臨時數據庫。在查詢多表、有多個連接、查詢復雜、數據要過濾時，可以建臨時表(索引)以減少I/O。但缺點是增加了空間開銷。
除非每個列都有索引支持，否則在有連接的查詢時分別找出兩個動態索引，放在工作表中重新排序。
3 基本表擴展設計
基于第三范式設計的庫表雖然有其優越性(見本文第一部分)，然而在實際應用中有時不利于系統運行性能的優化：如需要部分數據時而要掃描整表，許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程從多表獲取數據時引發大量的連接*作，當數據來源于多表時的連接*作;這都消耗了磁盤I/O和CPU時間。
尤其在遇到下列情形時，我們要對基本表進行擴展設計：許多過程要頻繁訪問一個表、子集數據訪問、重復計算和冗余數據，有時用戶要求一些過程優先或低的響應時間。
如何避免這些不利因素呢?根據訪問的頻繁程度對相關表進行分割處理、存儲冗余數據、存儲衍生列、合并相關表處理，這些都是克服這些不利因素和優化系統運行的有效途徑。
3.1 分割表或儲存冗余數據
文章來源于領測軟件測試網 http://www.kjueaiud.com/
