胡勁

關(guān)鍵詞：信息管理系統(tǒng)；數(shù)據(jù)庫；邏輯架構(gòu)；功能設(shè)計(jì)；調(diào)優(yōu)

0 引言

通過對信息管理系統(tǒng)數(shù)據(jù)庫產(chǎn)生瓶頸的原因進(jìn)行反復(fù)研究分析，主要存在不同量級的數(shù)據(jù)優(yōu)化的思路不同，數(shù)據(jù)的量級隨著時(shí)間的推移而提高。大部分系統(tǒng)分析師一般只對遇到的當(dāng)前量級數(shù)據(jù)逐步提出優(yōu)化方案，例如：1萬級無須優(yōu)化、10萬級排查數(shù)據(jù)結(jié)構(gòu)的合理性、100 萬級建立合理的索引[1]。這種優(yōu)化思路形成了反復(fù)對性能修復(fù)補(bǔ)丁，并沒有一次性解決問題，每個(gè)量級的數(shù)據(jù)性能修復(fù)補(bǔ)丁變得更加艱難。

1 基于不同量級數(shù)據(jù)優(yōu)化的改進(jìn)

為了確保數(shù)據(jù)庫結(jié)構(gòu)的統(tǒng)一原則，在邏輯設(shè)計(jì)階段表與表之間經(jīng)常會(huì)設(shè)計(jì)過多的關(guān)聯(lián)，盡可能地減少數(shù)據(jù)冗余。但在實(shí)際應(yīng)用中，雖然數(shù)據(jù)冗余低會(huì)使數(shù)據(jù)的完整性得到保證，提高了數(shù)據(jù)吞吐率，能夠清晰地表述出數(shù)據(jù)屬性之間的關(guān)系，但當(dāng)數(shù)據(jù)庫足夠龐大的時(shí)候，多表之間關(guān)聯(lián)頻繁會(huì)降低查詢性能，加大了客戶端程序編程的難度[2]；因此，在物理設(shè)計(jì)階段，需要根據(jù)實(shí)際業(yè)務(wù)需求確定相互存在關(guān)聯(lián)數(shù)據(jù)表的最大數(shù)據(jù)容量和字段屬性的訪問頻次，對此類數(shù)據(jù)表做頻繁關(guān)聯(lián)查詢，適當(dāng)并合理地提高數(shù)據(jù)冗余，為了提高查詢性能、系統(tǒng)響應(yīng)速度，合理提高數(shù)據(jù)冗余是必須的[3]。真實(shí)系統(tǒng)的數(shù)據(jù)庫設(shè)計(jì)階段應(yīng)該根據(jù)字段類型、查詢語句、算法、索引等多方面進(jìn)行權(quán)衡考慮。

2 實(shí)驗(yàn)對比

2.1 數(shù)據(jù)表設(shè)計(jì)的優(yōu)化

1） 數(shù)據(jù)庫表命名將業(yè)務(wù)表與基礎(chǔ)表區(qū)分，采用集成基礎(chǔ)庫分布式數(shù)據(jù)庫設(shè)計(jì)思路；

2） 字段的類型選擇優(yōu)先級數(shù)字、浮點(diǎn)、字符、文本、二進(jìn)制，能夠使用基本類型的盡量選擇基本類型，如果強(qiáng)行選擇其他優(yōu)先級低的數(shù)據(jù)類型會(huì)增加存儲開銷，降低查詢和連接的性能；

3） 謹(jǐn)慎區(qū)分char 和nvarchar 兩種字符類型，不可變長字符類型char 查詢速度快，增加硬盤的存儲空間，可變長字符類型nvarchar查詢慢一點(diǎn)，節(jié)省硬盤存儲空間；在設(shè)計(jì)字段的時(shí)候可以靈活選擇，針對內(nèi)容固定長度的數(shù)據(jù)選擇char，內(nèi)容長度變化差距很大數(shù)據(jù)選擇nvarchar；

4） 字段長度設(shè)計(jì)時(shí)，應(yīng)該根據(jù)實(shí)際業(yè)務(wù)需求的最大限度前提下盡可能地簡短，滿足需求即可，這種做法可以大大提高查詢性能，在建立字段索引時(shí)也能減少資源的消耗。

2.2 查詢的優(yōu)化

1） 程序在確保功能實(shí)現(xiàn)的基礎(chǔ)上，對數(shù)據(jù)庫訪問建立的連接次數(shù)盡可能地少，并且每次數(shù)據(jù)庫連接使用結(jié)束之后必須關(guān)閉連接，做到建立連接和關(guān)閉連接一一對應(yīng)；

2） 盡量避免向用戶端返回過多的數(shù)據(jù)量，如果數(shù)據(jù)量較大，應(yīng)該考慮業(yè)務(wù)需求分析是否合理，通過查詢條件，盡可能縮小對數(shù)據(jù)表的訪問行數(shù)和結(jié)果集，從而降低網(wǎng)絡(luò)傳輸過程的壓力；

3） 盡量避免使用select*from Table，一定要用具體的字段名的列表來代替“*”，無須返回業(yè)務(wù)邏輯中用不上的任何字段；

4） 構(gòu)建SQL 查詢語句時(shí)，盡可能把要求使用的索引放在where條件的首列；

5） where條件語句中的等于（=） 運(yùn)算不要在左邊進(jìn)行函數(shù)、算術(shù)或表達(dá)式運(yùn)算，否則數(shù)據(jù)庫索引可能會(huì)失效；

6） 避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，當(dāng)游標(biāo)操作的數(shù)據(jù)大于1萬條時(shí)，應(yīng)該考慮改寫。

2.3 算法的優(yōu)化

SQL 語句中經(jīng)常需要融合復(fù)雜的算法來解決業(yè)務(wù)邏輯問題，數(shù)據(jù)庫越大，算法的瓶頸越容易暴露出來。在此，針對不同的分頁語句在不同的數(shù)據(jù)量級別進(jìn)行測試分析，優(yōu)化實(shí)驗(yàn)結(jié)果如下。

2.4 合理建立高效的索引進(jìn)行優(yōu)化

SQL Server 數(shù)據(jù)庫建立索引有兩個(gè)目的：確保索引字段的唯一性、實(shí)現(xiàn)快速查詢數(shù)據(jù)的目的。企業(yè)級數(shù)據(jù)庫系統(tǒng)都包括聚集索引和非聚集索引兩種索引，非聚集索引的表的數(shù)據(jù)是根據(jù)Heap 結(jié)構(gòu)存儲的數(shù)據(jù)，將全部數(shù)據(jù)添加在表的尾部，聚集索引的表的數(shù)據(jù)是根據(jù)索引字段的順序存儲，并且數(shù)據(jù)表的聚集索引有唯一性。

聚集索引：數(shù)據(jù)庫表的數(shù)據(jù)是根據(jù)索引字段的順序存儲，索引項(xiàng)的順序與表中記錄的物理存儲順序必須保持一致；對于聚集索引不需要再有另外單獨(dú)的數(shù)據(jù)頁，因此，每張數(shù)據(jù)表中最多只能創(chuàng)建唯一的一個(gè)聚集索引[4]。

非聚集索引：數(shù)據(jù)庫表的數(shù)據(jù)記錄存儲順序與索引字段順序無關(guān)，非聚集索引采用葉結(jié)點(diǎn)的數(shù)據(jù)頁和數(shù)據(jù)行中邏輯指針指向索引字段值。因此，邏輯行數(shù)量與數(shù)據(jù)表行數(shù)據(jù)量完成保持一致[5]。

1） 建立高效索引的思路；

2） 結(jié)合實(shí)際情況淺談索引使用過程中的誤區(qū)。

理論的目的是應(yīng)用，應(yīng)用次數(shù)越多，經(jīng)驗(yàn)越豐富。

誤區(qū)一：主鍵就是聚集索引

通常習(xí)慣在每個(gè)數(shù)據(jù)表中建立一個(gè)自動(dòng)增長的TableKey 列或以Gid 為值的列為主鍵，像SQL Server 數(shù)據(jù)庫系統(tǒng)就會(huì)將它默認(rèn)為聚集索引，類似于這樣的聚集索引并不能完全發(fā)揮最大的性能優(yōu)勢；要想使用聚集索引達(dá)到最大性能優(yōu)勢，應(yīng)該根據(jù)查詢中的條件縮小范圍和避免全表掃描，某種情況下使用TableKey 主鍵作為聚集索引是一種資源浪費(fèi)[6] 。

在無紙化網(wǎng)絡(luò)辦公系統(tǒng)的公文、會(huì)議、督辦等模塊中，無論是首頁提示用戶待簽收的公文、會(huì)議提醒、督辦提醒，還是用戶進(jìn)行已辦公文、會(huì)議、督辦等查詢操作，只要是按需進(jìn)行數(shù)據(jù)查詢都將離不開字段的是“時(shí)間”和用戶的“人員ID”。

誤區(qū)二：建立索引就一定能夠提高數(shù)據(jù)查詢的性能與速度

兩條完全相同的SQL 語句：select TableKey from 0T1ab-l2e1 w，h并ere且 時(shí)針間對＞同一20個(gè)22-da0t1e- 字20段a建nd立 時(shí)索間引＜；索20引22區(qū)-別一種是對“時(shí)間”字段建立非聚集索引，兩種方案是對“時(shí)間”字段建立聚集索引，兩種查詢速度有著很大的差距。所以，并不是所有字段上只要建立索引就一定能夠提高查詢性能與速度[7]。

要想建立合適的索引，應(yīng)該根據(jù)數(shù)據(jù)的分布情況加以分析，例如：無紙化網(wǎng)絡(luò)辦公系統(tǒng)公文表中有著百萬級數(shù)據(jù)量的“時(shí)間”字段，有著上千條不同日期的記錄，同一個(gè)日期又存在若干條公文記錄，根據(jù)建立高效索引的思路得出在此字段上建立聚集索引是最佳的選擇。

誤區(qū)三：只要提高數(shù)據(jù)查詢性能與速度的字段就全部加聚集索引

SQL Server 雖然只能建立一個(gè)唯一的聚集索引，但經(jīng)常會(huì)出現(xiàn)同時(shí)多個(gè)字段都需要建立聚集索引的情況，這時(shí)通常可以把他們合并一起建立一個(gè)復(fù)合索引，也并非所有的字段都適合加入聚集索引，需要根據(jù)實(shí)際情況權(quán)衡選擇。

復(fù)合索引查詢性能的主要體現(xiàn)是查詢條件中是否用到索引中的全部列。比如：根據(jù)無紙化網(wǎng)絡(luò)辦公系統(tǒng)公文中的“人員ID”和“時(shí)間”字段，通過分析這兩個(gè)字段非常重要，并且基本上都會(huì)同時(shí)出現(xiàn)在查詢條件當(dāng)中，那么就可以將它們合并建立一個(gè)復(fù)合的聚集索引，并且“時(shí)間”為起始列、“人員ID”排在后列[8]。

3） 其他事項(xiàng)

只有建立合理的索引才有利于提高數(shù)據(jù)查詢的性能，如果過多或者不當(dāng)?shù)慕⑺饕龝?huì)導(dǎo)致系統(tǒng)產(chǎn)生更嚴(yán)重的瓶頸，因?yàn)槊恳粋€(gè)索引都會(huì)導(dǎo)致存儲空間的增加和數(shù)據(jù)庫會(huì)做更多復(fù)雜的工作，并且產(chǎn)生大量的索引碎片。所以，要想建立一個(gè)合理的索引體系，需要融合更多的實(shí)戰(zhàn)應(yīng)用分析，結(jié)合調(diào)優(yōu)結(jié)果精益求精建立索引，才能使數(shù)據(jù)庫的性能達(dá)到最佳的狀態(tài)。

3 結(jié)論

綜上所述，通過大型信息管理系統(tǒng)中的數(shù)據(jù)庫設(shè)計(jì)和優(yōu)化進(jìn)行反復(fù)論證，本文針對數(shù)據(jù)庫設(shè)計(jì)和優(yōu)化提出以下幾點(diǎn)思路：1） 數(shù)據(jù)表中每一個(gè)字段的設(shè)計(jì)都必須非常嚴(yán)謹(jǐn)，比如數(shù)據(jù)類型選擇、長度設(shè)計(jì)等；2） 查詢語句的優(yōu)化是SQL效率優(yōu)化的一個(gè)方式，可以通過優(yōu)化SQL語句來盡量使用已有的索引，避免全表掃描， 從而提高查詢效率；3） 不斷優(yōu)化復(fù)雜的算法來解決數(shù)據(jù)量大的業(yè)務(wù)邏輯問題；4） 建立最合理的索引體系可以大大提高系統(tǒng)的性能。