前言：本站為你精心整理了探討電話銷售系統的特性范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

數據庫調優的常見策略數據庫的性能涉及硬件、網絡及應用程序等多個方面。主要包括：1）系統硬件。系統硬件的性能對數據庫的表現至關重要，配置合理的服務器及存儲設備能夠最有效的提高整個系統的性能。系統性能主要取決于磁盤、內存、CPU和網絡。磁盤是最容易被忽略的薄弱環節，快速的磁盤系統可能節省十倍甚至百倍的時間。內存越大，則表的部分或全部保存在內存中的機會也越大，可以大大的減少磁盤I/O的次數，從而極大的提升檢索速度。SqlServer2005可以支持多達32個CPU并行工作，選擇多個高性能的CPU能提高每個任務的處理速度。網絡連接的快慢則決定了數據庫服務器與應用服務器之間的數據交換能力。硬件系統的價格比較昂貴，如果單純采用升級硬件的方式來提升性能，能夠得到很好的效果，但付出的代價較高。2）數據庫的設計。數據庫設計同樣能夠極大的影響數據庫的性能。數據庫設計方面主要考慮如下方面：表的設計、索引的設計和存儲過程的使用。數據庫表的設計一般應滿足三范式，消除冗余，避免插入、刪除和修改異常。但適當的非規范化處理可以減少頻繁連表和重復計算，和應用程序結合在一起能夠很好的降低對數據庫查詢量的需求。表的設計另一方面需考慮盡可能減少可空列，而采用默認值的方法，減少行的大小。索引的設計在提升查詢性能上至關重要，一個有效利用索引的查詢可以迅速的定位記錄，而不需要全表搜索。有效的使用存儲過程，來批量的處理數據可以很好的減少連接數據庫的次數。數據庫的設計方面的調優一部分可以獨立進行，而不影響應用程序和現有系統，沒有額外的投資，但是有些部分則需要應用程序做出相應的調整，有些部分則會帶來負面影響，比如索引，表的索引越多，增加、刪除和修改時的速度越慢。要根據情況均衡考慮。3）應用程序的設計。主要涉及查詢語句的設計方式、鎖的類型和持續時間，能不能充分利用索引和存儲過程。除此以外還需要平衡業務的需求和整個系統的性能。應用程序的設計準則包括：消除過多的網絡流量，使用小結果集；使用存儲過程，避免死鎖等。

在線電銷系統數據庫問題的分析我們了解到該企業的電銷系統數據庫的應用程序采用多層架構，有豐富的現場日志，且能夠做到直接修改查詢語句而不需要重新編譯源代碼。首先分析了應用程序保留的卡死那段時間的現場日志。經過對日志的分析發現了如下問題：1）當時有很多條需要對十多張百萬級數據表的聯結查詢。其中數十條查詢時長超過1000ms。對這些查詢進一步的分析表明，sql語句中的查詢條件不能有效的利用索引，主要原因有如下幾點:a.有些字段沒有包含在索引之中。b.諸如like‘%xxx%’的模糊查詢。c.諸如in(x,x,x)的查詢。上述情況由于不能利用索引來查詢，導致全表搜索，而全表的數據量非常巨大，因此導致查詢時間很長，在并發數很大的情況下會導致系統響應很慢。2）某個檢查工作狀態的查詢語句每10s檢查一次。3）經常查詢的表數據量巨大，最多的通話相關的表達500萬條以上，更頻繁操作的客戶表和訂單表也達100萬條，還在持續增長之中，很多業務查詢都需要這些大表互相連接或聚合統計分析。其次為了了解當并發量很大,查詢集中時，整個系統的瓶頸在哪里，決定選擇一個正常的工作周期打開性能監視器，了解性能瓶頸所在。我們選擇了正常工作日的一整天24小時。經過檢查發現磁盤I/O存在較大異常，avg.disk.queue.length的平均值都高達60~80，最大值高達700，而合理值是1~3/每塊磁盤，當前系統包含2塊物理磁盤，那么平均值不應該超過6。因此可以判斷磁盤I/O存在異常。從上述分析可以得出該數據庫系統的問題主要有：（1）歷史數據過于龐大；（2）表的索引設計存在問題；（3）查詢語句設計存在問題；（4）硬件的性能已經無法應付日益龐大的數據量和并發數。

針對性調優策略的選取由于該企業的數據庫系統是始終運行之中，很多優化措施在應用程序和數據庫的設計和開發階段是比較容易解決的問題，現在卻變得不可實現，比如對應用程序的修改，雖然該應用程序可以方便的修改查詢語句，但是對于數據的處理方式將很難修改。而且一個表會涉及到多處使用，因此數據庫設計方面的缺陷所能做的優化也幾乎不可能。因此需要針對數據庫系統存在的4類問題進行分析處理。這4類問題中，其中最容易處理的是（2），因為僅需要對數據庫進行操作即可。其次為（3），需要對查詢語句進行修改，本來是比較復雜的工作，由于該企業的應用程序是多層架構，查詢語句可以方便的修改而不需要重新編譯源代碼。再然后是（1），歷史數據中有很多類型，有些是基本不會被查詢的可以移除，有些是核心數據如客戶數據和訂單數據，這些對公司的業務有著巨大的價值，不可能被轉移。對于（4）則更加麻煩，這不僅僅涉及到公司資金的投入，還涉及到如何擴展或更新硬件而不影響現有業務的進行，如何應對擴展或更新過程中所遇到的風險。因此我們的解決方案是：首先解決（2）、（3），然后是（1）。

經過觀察后，如有必要再考慮對硬件的升級。具體來說，采用了如下步驟：1）從日志中選出所有耗時巨大的查詢語句，逐一分析，分別處以如下操作：(1)對于經常需要進行的操作，盡可能去除模糊查詢(like和in)。如果業務需要，確實在某些情況下需要模糊查詢，則提供2個版本供選擇：可以模糊查詢和不可以模糊查詢的版本。并控制模糊查詢的使用(2)對于所有耗時巨大的且不是因為模糊查詢的語句，運用數據庫引擎優化顧問來優化，根據建議來重新建立表的索引，確保查詢能充分利用索引，減少查詢時間經過步驟（1）的處理后，系統的壓力得到了緩解，但是仍然反映很慢。2）鑒于數據量正在日新月異的增加。沉重的歷史數據始終是系統的包袱。因此需要向業務部門提出建議，每種數據確定需要保留的時間。并據此寫出清理數據的存儲過程，每周進行一次清理，將超過半年、一年以上的數據(根據業務的需求保留時長不等)轉移到其他備份數據庫中，并在原數據庫中清理掉。經過步驟（2）的處理之后，以及進一步的性能監視之后，發現，磁盤I/O的avg.disk.queue.length的最大值仍然在200以上。雖然對比最初已經有了很好的降低，仍然遠遠超出建議的值。3）仔細分析了系統硬件之后發現，當前的數據庫文件的大小已達20G，而內存大小僅為4G，顯然如果涉及大數據量的查詢時，數據庫的大部分都在磁盤而非內存中，需要多次磁盤I/O來應對，從而導致磁盤I/O成為瓶頸所在。鑒于這樣的原因，建議升級內存到32G。升級后發現，磁盤I/O迅速的下降為2~4之間。坐席終端也反映系統使用比較流暢。整個系統運行多日未出現卡死現象。至此本次優化取得了很好的效果。

經過本次數據庫系統系統終端的設計會優化，可以發現聯機數據庫調優涉及很多方面，絕不僅僅是數據庫本身的知識。還涉及業務需求、查詢語句和應用程序的架構以及硬件的性能。每個方面都對數據庫的性能有重大影響。從業務的角度，如何在有限的系統資源中，確保核心業務的進行；如何在業務的便利性和系統資源的消耗之間找到平衡。從應用程序結構的角度，不僅需要考慮實現用戶提出的功能，還要預見到在大數據量和高并發情況下，系統性能的影響。如果在設計時就考慮到這一點，就能有更多的優化策略可以采用，比如數據的劃分，將同一種數據分在不同表中，從而縮小每個人需要查詢的總范圍，且減少讀寫鎖的爭用。

作者：翁英萍單位：南京工業職業技術學院計算機與軟件學院