“
今天跟大家分享一篇剛哥寫的關(guān)于數(shù)據(jù)庫優(yōu)化的文章，這篇文章會教會你面對問題解決的方法，真是很實用勉耀，這可是剛哥的經(jīng)驗之談盼铁，感覺不錯就分享給你的小伙伴吧粗蔚！
摘要
從事前端開發(fā)的都知道,頁面顯示的數(shù)據(jù)一定要及時的呈現(xiàn),否則會影響用戶體現(xiàn).那么導致頁面加載數(shù)據(jù)慢或者顯示滯后的原因又是什么呢?
拿自己之前做項目經(jīng)歷給大家講講吧,之前做后臺,當時的項目實時性都非常高,前端頁面實時顯示要求非常高 ,慢1秒顯示都會導致用戶的投訴,最后沒辦法,通過本地(磁盤)緩存跟數(shù)據(jù)表分割來解決這一問題.
原因分析
主要原因1:后臺數(shù)據(jù)庫中的數(shù)據(jù)過多,沒做數(shù)據(jù)優(yōu)化導致后臺查詢數(shù)據(jù)很慢
次要原因2:前端數(shù)據(jù)請求-解析-展示過程處理不當
次要原因3:網(wǎng)絡(luò)問題所致
那么我們應(yīng)該怎么做后臺數(shù)據(jù)優(yōu)化呢?
解決問題
這里總結(jié)了幾種方案,如何提高數(shù)據(jù)庫查詢的速度,大家參考.
1、緩存饶火，在持久層或持久層之上做緩存
使用ehcache緩存,這個一般用于持久層的緩存鹏控，提供持久層、業(yè)務(wù)層的快速緩存肤寝，hibenate默認使用的二級緩存就是ehcache;
2当辐、數(shù)據(jù)庫表的大字段剝離
假如一個表的字段數(shù)有100多個,學會拆分字段,保證單條記錄的數(shù)據(jù)量很小;
3、恰當?shù)厥褂盟饕?/p>
必要時建立多級索引,分析MySQL的執(zhí)行計劃鲤看，通過表數(shù)據(jù)統(tǒng)計等方式協(xié)助數(shù)據(jù)庫走正確的查詢方式缘揪，該走索引就走索引，該走全表掃描就走全表掃描;
4义桂、表的拆分
表分區(qū)和拆分找筝，無論是業(yè)務(wù)邏輯上的拆分（如一個月一張報表、分庫）還是無業(yè)務(wù)含義的分區(qū)（如根據(jù)ID取模分區(qū)）;
5慷吊、字段冗余
減少跨庫查詢和大表連接操作;,數(shù)據(jù)通過單個或多個JOB生成出來袖裕，減少實時查詢;
6、從磁盤上做文章
數(shù)據(jù)存放的在磁盤的內(nèi)溉瓶、外磁道上急鳄，數(shù)據(jù)獲取的效率都是不一樣的;
7、放棄關(guān)系數(shù)據(jù)庫的某些特性
引入NoSQL數(shù)據(jù)庫;
換種思路存放數(shù)據(jù)堰酿，例如搜索中的倒排表;
“
在上面談到數(shù)據(jù)庫查詢速度優(yōu)化方案我們講到了,數(shù)據(jù)優(yōu)化的幾種方案疾宏。接下來,一起看如何實際到具體的操作上.也就是我們在寫數(shù)據(jù)時我們應(yīng)該注意些什么？
1胞锰、對查詢進行優(yōu)化,應(yīng)盡可能避免全表掃描
首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引灾锯。
下面我們來以一個表中177條數(shù)據(jù)比較一下,全表掃描與建立索引之后性能的一個比較.
1.1 全表查詢
1.2 建立索引查詢
1.3 結(jié)論
從這兩種方式查詢數(shù)據(jù)庫結(jié)果看,建立索引之后查詢速度提高了些,現(xiàn)在數(shù)據(jù)量還不明顯,如果表中有10萬條速度,差異就會很明顯了.
2、寫數(shù)據(jù)語句時盡可能減少表的全局掃描
2.1 減少where 字段值null判斷
如何這樣做,就會導致引擎放棄使用索引而進行全表掃描
應(yīng)該這樣去設(shè)置(也就是在沒有值時,我們在存數(shù)據(jù)庫時自動默認給個o值,而不是什么都不寫):
2.2 應(yīng)盡量避免在 where 子句中使用!=或<>操作符
這樣寫將導致引擎放棄使用索引而進行全表掃描嗅榕。
2.3 應(yīng)盡量避免在 where 子句中使用 or 來連接條件
這樣將導致引擎放棄使用索引而進行全表掃描
可以這樣操作:
2.4 in 和 not in 也要慎用
這樣操作,也會導致全表掃描
以通配符*去查詢所有數(shù)據(jù),這樣做也是非常耗時的,我們應(yīng)該需要什么字段就查詢什么字段.
應(yīng)該這樣做:
3顺饮、不要在條件判斷時進行 算數(shù)運算
所以不要在 where 子句中的“=”左邊進行函數(shù)、算術(shù)運算或其他表達式運算,這樣系統(tǒng)將可能無法正確使用索引
應(yīng)該這樣做:
4凌那、很多時候用 exists 代替 in 是一個好的選擇
5 論索引技巧
5.1 并不是所有索引對查詢都有效
SQL是根據(jù)表中數(shù)據(jù)來進行查詢優(yōu)化的兼雄，當索引列有大量數(shù)據(jù)重復時，SQL查詢可能不會去利用索引帽蝶，如一表中有字段sex赦肋，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用佃乘。
5.2 索引并不是越多越好
索引固然可以提高相應(yīng)的 select 的效率囱井，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引趣避，所以怎樣建索引需要慎重考慮庞呕，視具體情況而定。一個表的索引數(shù)最好不要超過6個程帕，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要住练。
5.3 應(yīng)盡可能的避免更新 clustered 索引數(shù)據(jù)列
因為 clustered 索引數(shù)據(jù)列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調(diào)整愁拭，會耗費相當大的資源讲逛。若應(yīng)用系統(tǒng)需要頻繁更新 clustered 索引數(shù)據(jù)列，那么需要考慮是否應(yīng)將該索引建為 clustered 索引岭埠。
5.4 盡量使用數(shù)字型字段
若只含數(shù)值信息的字段盡量不要設(shè)計為字符型盏混，這會降低查詢和連接的性能，并會增加存儲開銷枫攀。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符括饶，而對于數(shù)字型而言只需要比較一次就夠了。
5 創(chuàng)建數(shù)據(jù)庫時應(yīng)該注意地方
5.1. 盡可能的使用 varchar/nvarchar 代替 char/nchar
因為首先變長字段存儲空間小来涨，可以節(jié)省存儲空間，其次對于查詢來說启盛，在一個相對較小的字段內(nèi)搜索效率顯然要高些蹦掐。
5.2 用表變量來代替臨時表。
1. 如果表變量包含大量數(shù)據(jù)僵闯，請注意索引非常有限（只有主鍵索引）卧抗。
2. 在新建臨時表時，如果一次性插入數(shù)據(jù)量很大鳖粟，那么可以使用 select into 代替 create table社裆，避免造成大量 log ，以提高速度向图；如果數(shù)據(jù)量不大泳秀，為了緩和系統(tǒng)表的資源，應(yīng)先create table榄攀，然后insert嗜傅。
3. 如果使用到了臨時表，在存儲過程的最后務(wù)必將所有的臨時表顯式刪除檩赢，先 truncate table 吕嘀，然后 drop table ，這樣可以避免系統(tǒng)表的較長時間鎖定。
4. 避免頻繁創(chuàng)建和刪除臨時表偶房，以減少系統(tǒng)表資源的消耗趁曼。
5. 盡量避免使用游標
1. 因為游標的效率較差，如果游標操作的數(shù)據(jù)超過1萬行棕洋，那么就應(yīng)該考慮改寫挡闰。
2. 使用基于游標的方法或臨時表方法之前，應(yīng)先尋找基于集的解決方案來解決問題拍冠，基于集的方法通常更有效尿这。
3. 與臨時表一樣，游標并不是不可使用庆杜。對小型數(shù)據(jù)集使用 FAST_FORWARD 游標通常要優(yōu)于其他逐行處理方法射众，尤其是在必須引用幾個表才能獲得所需的數(shù)據(jù)時。在結(jié)果集中包括“合計”的例程通常要比使用游標執(zhí)行的速度快。如果開發(fā)時間允許，基于游標的方法和基于集的方法都可以嘗試一下合住，看哪一種方法的效果更好逼泣。
6 數(shù)據(jù)放回時注意什么
6.1 盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力碌宴。
這樣可以有效提高系統(tǒng)的并發(fā)能力
6.2 盡量避免向客戶端返回大數(shù)據(jù)量
若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理。
7.總結(jié)
我們做項目時 在做項目優(yōu)化時我們要注意這些性能問題,上面我是結(jié)合了之前做項目遇到的問題以及綜合了別人的看法.
THE END.
發(fā)布/藍鷗仔仔
藍鷗仔仔伙菜，一個每天拿著5毛錢工資到處嗨的人。
長期尋找好的文命迈，結(jié)交好的人贩绕，幻想著成為一個伯樂，把好的文給大家一起看壶愤，一起成長淑倾。
很高興認識你，喜歡請關(guān)注一個征椒。這樣娇哆，在找文的時候就更有動力了。
PS：你有文勃救，不介意的話給我投稿吧碍讨，最最喜歡好文了，期待你的投稿剪芥。
