[[238028]]

思考

如何設(shè)計或優(yōu)化千萬級別的大表？此外無其他信息，個人覺得這個話題有點(diǎn)范，就只好簡單說下該如何做，對于一個存儲設(shè)計，必須考慮業(yè)務(wù)特點(diǎn)，收集的信息如下：

1.數(shù)據(jù)的容量：1-3年內(nèi)會大概多少條數(shù)據(jù)，每條數(shù)據(jù)大概多少字節(jié)；

2.數(shù)據(jù)項(xiàng)：是否有大字段，那些字段的值是否經(jīng)常被更新；

3.數(shù)據(jù)查詢SQL條件：哪些數(shù)據(jù)項(xiàng)的列名稱經(jīng)常出現(xiàn)在WHERE、GROUP BY、ORDER BY子句中等；

4.數(shù)據(jù)更新類SQL條件：有多少列經(jīng)常出現(xiàn)UPDATE或DELETE 的WHERE子句中；

5.SQL量的統(tǒng)計比，如：SELECT：UPDATE+DELETE：INSERT=多少？

6.預(yù)計大表及相關(guān)聯(lián)的SQL，每天總的執(zhí)行量在何數(shù)量級？

7.表中的數(shù)據(jù)：更新為主的業(yè)務(wù) 還是 查詢?yōu)橹鞯臉I(yè)務(wù) ？

8.打算采用什么數(shù)據(jù)庫物理服務(wù)器，以及數(shù)據(jù)庫服務(wù)器架構(gòu)？

9.并發(fā)如何？

10.存儲引擎選擇InnoDB還是MyISAM？

大致明白以上10個問題，至于如何設(shè)計此類的大表，應(yīng)該什么都清楚了！

至于優(yōu)化若是指創(chuàng)建好的表，不能變動表結(jié)構(gòu)的話，那建議InnoDB引擎，多利用點(diǎn)內(nèi)存，減輕磁盤IO負(fù)載，因?yàn)镮O往往是數(shù)據(jù)庫服務(wù)器的瓶頸

另外對優(yōu)化索引結(jié)構(gòu)去解決性能問題的話，建議優(yōu)先考慮修改類SQL語句，使他們更快些，不得已只靠索引組織結(jié)構(gòu)的方式，當(dāng)然此話前提是， 索引已經(jīng)創(chuàng)建的非常好，若是讀為主，可以考慮打開query_cache，以及調(diào)整一些參數(shù)值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size

以及調(diào)整一些參數(shù)值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size

案例一

我現(xiàn)在的公司有三張表，是5億的數(shù)據(jù)，每天張表每天的增量是100w

每張表大概在10個columns左右

下面是我做的測試和對比

1.首先看engine,在大數(shù)據(jù)量情況下，在沒有做分區(qū)的情況下

mysiam比innodb在只讀的情況下，效率要高13％左右

2.在做了partition之后，你可以去讀一下mysql的官方文檔，其實(shí)對于partition，專門是對myisam做的優(yōu)化，對于innodb，所有的數(shù)據(jù)是存在ibdata里面的，所以即使你可以看到schema變了，其實(shí)沒有本質(zhì)的變化

在分區(qū)出于同一個physical disk下面的情況下，提升大概只有1％

在分區(qū)在不同的physical disk下，我分到了三個不同的disks下，提升大概在3％，其實(shí)所謂的吞吐量，由很多因素決定的，比如你的explain parition時候可以看到，record在那一個分區(qū)，如果每個分區(qū)都有，其實(shí)本質(zhì)上沒有解決讀的問題，這樣只會提升寫的效率。

另外一個問題在于，分區(qū)，你怎么分，如果一張表，有三個column都是經(jīng)常被用于做查詢條件的，其實(shí)是一件很悲慘的事情，因?yàn)槟銢]有辦法對所有的sql做針對性的分區(qū)，如果你只是如mysql官方文檔上說的，只對時間做一個分區(qū)，而且你也只用時間查詢的話，恭喜你

3.表主要用來讀還是寫，其實(shí)這個問題是不充分的，應(yīng)該這樣問，你在寫入的時候，同時并發(fā)的查詢多么？我的問題還比較簡單，因?yàn)閙ongodb的shredding支持不能，在crush之后，還是回到mysql，所以在通常情況下，9am－9pm，寫入的情況很多，這個時候我會做一個view，view是基于最近被插入或者經(jīng)常被查詢的，通過做view來分離讀取，就是說寫是在table上的，讀在進(jìn)行邏輯判斷前是在view上操作的

4.做一些archive table，比如先對這些大表做很多已有的統(tǒng)計分析，然后通過已有的分析＋增量來解決

5.如果你用mysiam，還有一個問題你要注意，如果你的.configure的時候，加了一個max index length參數(shù)的時候，當(dāng)你的record數(shù)大于制定長度的時候，這個index會被disable

案例二

任何偏離業(yè)務(wù)場景的優(yōu)化都是耍流氓，如果是訂單表，主要通過訂單id來查詢訂單信息，則可以對這樣的表 進(jìn)行垂直分庫，每個庫表容量500萬條，按訂單號維度 給拆分到多個庫，而在查詢的時候，使用訂單號查詢，通過某個業(yè)務(wù)規(guī)則，直接定位到要查詢的目標(biāo)庫?；蛘咄ㄟ^用戶ID 、日期維度 進(jìn)行分庫，但是千萬要注意，查詢時攜帶 分庫的條件。 如果是CRM系統(tǒng) ，不直接使用訂單號直接查詢，而是一個范圍查詢，返回一個列表集合，而你還繼續(xù)執(zhí)著于分庫分表就能解決你的性能問題，這樣你要對各個庫的查詢結(jié)果集進(jìn)行union，數(shù)據(jù)庫的性能非但不能提高反而會適得其反！

解決方案

• 首先，任何優(yōu)化，都需要你了解你的業(yè)務(wù)，了解你的數(shù)據(jù)。
• QPS要到多少？- 帶寬及存儲夠的情況下，單機(jī)幾千QPS妥妥的。
• 讀寫比例如何？- 讀多寫少和寫多讀少，優(yōu)化方法是有很大差別的。設(shè)置于只讀場景，果斷壓縮。
• 數(shù)據(jù)是否快速增長？- 基本就是QPS的要求。
• 數(shù)據(jù)及服務(wù)的SLA要到多少？- 數(shù)據(jù)需不需要強(qiáng)一致？HA做到什么程度？
• 諸如此類。

不同的場景有不同的側(cè)重，解決方案是不同的。而對于一些典型的場景可能會有成熟的解決方案。

題主已注明“千萬級”，因此以下假設(shè)題主為最常見的場景：大量數(shù)據(jù)，QPS要求高，讀多寫少，數(shù)據(jù)快速增長，SLA要求高。

• 其次，說優(yōu)化的方法。

主要從三個維度說：Why, How, When。

0. sql vs nosql

有些跑題，但也是很重要的一方面。

Why：nosql天生分布，而且大多針對某種類型的數(shù)據(jù)、某種使用場景做過優(yōu)化。

比如大批量的監(jiān)控數(shù)據(jù)，用mysql存費(fèi)時費(fèi)力，可以選擇mongo，甚至?xí)r間序列數(shù)據(jù)庫，存取會有量級提升。

How：找對應(yīng)解決方案。

When：有足夠誘惑 - 針對使用場景，有成熟解決方案，效率獲得大量提升。

1. 優(yōu)化shema、sql語句+索引

Why：再好的MySQL架構(gòu)也扛不住一個頻繁的垃圾查詢。不合理的schema設(shè)計也會導(dǎo)致數(shù)據(jù)存取慢。索引的作用不必多說，但如innodb下，錯的索引帶來的可能不只是查詢變慢而已。

How：設(shè)計階段就需要預(yù)計QPS及數(shù)據(jù)規(guī)模，參考業(yè)務(wù)場景對數(shù)據(jù)的要求，合理設(shè)計表結(jié)構(gòu)（參考mysql在線DDL問題），甚至違反設(shè)計范式做到適當(dāng)冗余。生產(chǎn)環(huán)境分析慢日志，優(yōu)化語句。索引的設(shè)計需要知道索引是怎么用的，比如innodb的加鎖機(jī)制。

When：這個不僅僅是第一個要考慮的，而應(yīng)該是需要持續(xù)去優(yōu)化的。特別是要參考業(yè)務(wù)。但實(shí)際環(huán)境中如果是這個的問題，那一般比較幸運(yùn)了，因?yàn)橐话阋呀?jīng)優(yōu)化過很多了。實(shí)際中遇到的一般是更深的問題。

2. 緩存

緩存沒有那么簡單。

緩存對于應(yīng)用不是完全透明的，除非你用Django這種成熟框架，而且緩存粒度很大，但實(shí)際。。。像python，最少也得加幾個裝飾器。

如何保證緩存里面的數(shù)據(jù)是始終正確的？寫數(shù)據(jù)前失效緩存還是寫數(shù)據(jù)后？

緩存掛了或者過冷，流量壓到后端mysql了怎么辦？

緩存也不是萬能的。寫多讀少，命中率會很低。

How：memcache用做緩存，redis用于需要持久化的場景。（redis能不能完全取代memcache？呵呵。。）

還可以使用mysql自帶的query cache，對應(yīng)用基本完全透明。但會受限于本機(jī)。而且只緩存查詢結(jié)果，mc和redis可以緩存一些加工后的數(shù)據(jù)。

而且數(shù)據(jù)量大、QPS大的情況下，也需要考慮分片及HA的問題。如果有一個數(shù)據(jù)過熱，把一個節(jié)點(diǎn)壓垮了怎么辦？

When：基本上大多數(shù)讀多寫少的場景都能用，寫多的情況下可能需要考慮考慮。

3. 復(fù)制及讀寫分離（做主從復(fù)制或主主復(fù)制，讀寫分離，可以在應(yīng)用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要么效率不高，要么沒人維護(hù)）

Why：這個其實(shí)是大多數(shù)場景下都必須的。因?yàn)閺?fù)制可以實(shí)現(xiàn)備份、高可用、負(fù)載均衡。就算嫌麻煩不做負(fù)載均衡，那備份下總是要的吧？既然已經(jīng)備份了，何不加個LVS+HAProxy做下HA？順便稍微修改下應(yīng)用，讀寫分離也就成了。

How：節(jié)點(diǎn)少的情況下，主備。前面加Keepalived+HAProxy等組件，失效自動切換。讀寫分離可能需要修改下應(yīng)用。

節(jié)點(diǎn)多的情況下，一是考慮多級備份，減輕主的壓力。其次可以引入第三方組件，接管主節(jié)點(diǎn)的備份工作。

主主不是很推薦。一是需要考慮數(shù)據(jù)沖突的情況，比如錯開id，同時操作數(shù)據(jù)后沖突解決。其次如果強(qiáng)一致會導(dǎo)致延遲增加，如果有節(jié)點(diǎn)掛了，需要等到超時才返回。

When：主備幾乎大多數(shù)場景。甚至不論數(shù)據(jù)大小。高可用對應(yīng)用透明，為啥不用?主主麻煩，建議先用切分。

4. 切分

包括垂直切分和水平切分，實(shí)現(xiàn)方式上又包括分庫、分表。

雖然有些難度，但還是推薦常用的。

Why：垂直切分保證業(yè)務(wù)的獨(dú)立性，防止不同業(yè)務(wù)爭搶資源，畢竟業(yè)務(wù)是有優(yōu)先級的。

水平切分主要用于突破單機(jī)瓶頸。除了主主外，只有切分能真正做到將負(fù)載分配下去。

切分后也可對不同片數(shù)據(jù)進(jìn)行不同優(yōu)化。如按時間切分，超過一定時間數(shù)據(jù)不允許修改，就可以引入壓縮了，數(shù)據(jù)傳輸及讀取減少很多。

How：根據(jù)業(yè)務(wù)垂直切分。業(yè)務(wù)內(nèi)部分庫、分表。一般都需要修改應(yīng)用。除分表外，其余實(shí)現(xiàn)不是很復(fù)雜。有第三方組件可用，但通用高效又靈活的方式，還是自己寫client。

When：垂直切分一般都要做，只不過業(yè)務(wù)粒度大小而已。

分庫有是經(jīng)常用的，就算當(dāng)前壓力小，也盡量分出幾個邏輯庫出來。等規(guī)模上去了，很方便就遷移擴(kuò)展。

水平拆分有一定難度，但如果將來一定會到這個規(guī)模，又可能用到，建議越早做越好。因?yàn)閷?yīng)用的改動較大，而且遷移成本高。

綜上，數(shù)據(jù)庫設(shè)計要面向現(xiàn)代化，面向世界，面向未來。。。

在一般運(yùn)維的角度來看，我們什么情況下需要考慮分庫分表？

首先說明，這里所說的分庫分表是指把數(shù)據(jù)庫數(shù)據(jù)的物理拆分到多個實(shí)例或者多臺機(jī)器上去，而不是類似分區(qū)表的原地切分。

原則零：能不分就不分。

是的，MySQL 是關(guān)系數(shù)據(jù)庫，數(shù)據(jù)庫表之間的關(guān)系從一定的角度上映射了業(yè)務(wù)邏輯。任何分庫分表的行為都會在某種程度上提升業(yè)務(wù)邏輯的復(fù)雜度，數(shù)據(jù)庫除了承載數(shù)據(jù)的存儲和訪問外，協(xié)助業(yè)務(wù)更好的實(shí)現(xiàn)需求和邏輯也是其重要工作之一。分庫分表會帶來數(shù)據(jù)的合并，查詢或者更新條件的分離，事務(wù)的分離等等多種后果，業(yè)務(wù)實(shí)現(xiàn)的復(fù)雜程度往往會翻倍或者指數(shù)級上升。所以，在分庫分表之前，不要為分而分，去做其他力所能及的事情吧，例如升級硬件，升級，升級網(wǎng)絡(luò)，升級數(shù)據(jù)庫版本，讀寫分離，負(fù)載均衡等等。所有分庫分表的前提是，這些你已經(jīng)盡力了。

原則一：數(shù)據(jù)量太大，正常的運(yùn)維影響正常業(yè)務(wù)訪問。

這里說的運(yùn)維，例如：

（1）對數(shù)據(jù)庫的備份。如果單表或者單個實(shí)例太大，在做備份的時候需要大量的磁盤IO或者網(wǎng)絡(luò)IO資源。例如1T的數(shù)據(jù)，網(wǎng)絡(luò)傳輸占用50MB的時候，需要20000秒才能傳輸完畢，在此整個過程中的維護(hù)風(fēng)險都是高于平時的。我們在Qunar的做法是給所有的數(shù)據(jù)庫機(jī)器添加第二塊網(wǎng)卡，用來做備份，或者SST，Group Communication等等各種內(nèi)部的數(shù)據(jù)傳輸。1T的數(shù)據(jù)的備份，也會占用大量的磁盤IO，如果是SSD還好，當(dāng)然這里忽略某些廠商的產(chǎn)品在集中IO的時候會出一些BUG的問題。如果是普通的物理磁盤，則在不限流的情況下去執(zhí)行xtrabackup，該實(shí)例基本不可用。

（2）對數(shù)據(jù)表的修改。如果某個表過大，對此表做DDL的時候，MySQL會鎖住全表，這個時間可能很長，在這段時間業(yè)務(wù)不能訪問此表，影響甚大。解決的辦法有類似騰訊游戲DBA自己改造的可以在線秒改表，不過他們目前也只是能添加字段而已，對別的DDL還是無效；或者使用pt-online-schema-change，當(dāng)然在使用過程中，它需要建立觸發(fā)器和影子表，同時也需要很長很長的時間，在此操作過程中的所有時間，都可以看做是風(fēng)險時間。把數(shù)據(jù)表切分，總量減小，有助于改善這種風(fēng)險。

（3）整個表熱點(diǎn)，數(shù)據(jù)訪問和更新頻繁，經(jīng)常有鎖等待，你又沒有能力去修改源碼，降低鎖的粒度，那么只會把其中的數(shù)據(jù)物理拆開，用空間換時間，變相降低訪問壓力。

原則二：表設(shè)計不合理，需要對某些字段垂直拆分

這里舉一個例子，如果你有一個用戶表，在最初設(shè)計的時候可能是這樣：

table：users

id bigint：用戶的ID

name varchar：用戶的名字

last_login_time datetime：最近登錄時間

personal_info text：私人信息

xxxxx：其他信息字段。

一般的users表會有很多字段，我就不列舉了。如上所示，在一個簡單的應(yīng)用中，這種設(shè)計是很常見的。但是：

設(shè)想情況一：你的業(yè)務(wù)中彩了，用戶數(shù)從100w飆升到10個億。你為了統(tǒng)計活躍用戶，在每個人登錄的時候都會記錄一下他的最近登錄時間。并且的用戶活躍得很，不斷的去更新這個login_time，搞的你的這個表不斷的被update，壓力非常大。那么，在這個時候，只要考慮對它進(jìn)行拆分，站在業(yè)務(wù)的角度，最好的辦法是先把last_login_time拆分出去，我們叫它 user_time。這樣做，業(yè)務(wù)的代碼只有在用到這個字段的時候修改一下就行了。如果你不這么做，直接把users表水平切分了，那么，所有訪問users表的地方，都要修改?；蛟S你會說，我有proxy，能夠動態(tài)merge數(shù)據(jù)。到目前為止我還從沒看到誰家的proxy不影響性能的。

設(shè)想情況二：personal_info這個字段本來沒啥用，你就是讓用戶注冊的時候填一些個人愛好而已，基本不查詢。一開始的時候有它沒它無所謂。但是到后來發(fā)現(xiàn)兩個問題，一，這個字段占用了大量的空間，因?yàn)槭莟ext嘛，有很多人喜歡長篇大論地介紹自己。更糟糕的是二，不知道哪天哪個產(chǎn)品經(jīng)理心血來潮，說允許個人信息公開吧，以方便讓大家更好的相互了解。那么在所有人獵奇窺私心理的影響下，對此字段的訪問大幅度增加。數(shù)據(jù)庫壓力瞬間抗不住了，這個時候，只好考慮對這個表的垂直拆分了。

原則三：某些數(shù)據(jù)表出現(xiàn)了無窮增長

例子很好舉，各種的評論，消息，日志記錄。這個增長不是跟人口成比例的，而是不可控的，例如微博的feed的廣播，我發(fā)一條消息，會擴(kuò)散給很多很多人。雖然主體可能只存一份，但不排除一些索引或者路由有這種存儲需求。這個時候，增加存儲，提升機(jī)器配置已經(jīng)蒼白無力了，水平切分是最佳實(shí)踐。拆分的標(biāo)準(zhǔn)很多，按用戶的，按時間的，按用途的，不在一一舉例。

原則四：安全性和可用性的考慮

這個很容易理解，雞蛋不要放在一個籃子里，我不希望我的數(shù)據(jù)庫出問題，但我希望在出問題的時候不要影響到100%的用戶，這個影響的比例越少越好，那么，水平切分可以解決這個問題，把用戶，庫存，訂單等等本來同統(tǒng)一的資源切分掉，每個小的數(shù)據(jù)庫實(shí)例承擔(dān)一小部分業(yè)務(wù)，這樣整體的可用性就會提升。這對Qunar這樣的業(yè)務(wù)還是比較合適的，人與人之間，某些庫存與庫存之間，關(guān)聯(lián)不太大，可以做一些這樣的切分。

原則五：業(yè)務(wù)耦合性考慮

這個跟上面有點(diǎn)類似，主要是站在業(yè)務(wù)的層面上，我們的火車票業(yè)務(wù)和烤羊腿業(yè)務(wù)是完全無關(guān)的業(yè)務(wù)，雖然每個業(yè)務(wù)的數(shù)據(jù)量可能不太大，放在一個MySQL實(shí)例中完全沒問題，但是很可能烤羊腿業(yè)務(wù)的DBA 或者開發(fā)人員水平很差，動不動給你出一些幺蛾子，直接把數(shù)據(jù)庫搞掛。這個時候，火車票業(yè)務(wù)的人員雖然技術(shù)很優(yōu)秀，工作也很努力，照樣被老板打屁股。解決的辦法很簡單:惹不起，躲得起。

20條規(guī)則摘要如下：

規(guī)則1：一般情況可以選擇MyISAM存儲引擎，如果需要事務(wù)支持必須使用InnoDB存儲引擎。

規(guī)則2：命名規(guī)則。

規(guī)則3：數(shù)據(jù)庫字段類型定義

1. 經(jīng)常需要計算和排序等消耗CPU的字段,應(yīng)該盡量選擇更為迅速的字段，如用TIMESTAMP(4個字節(jié)，最小值1970-01-01 00:00:00)代替Datetime（8個字節(jié)，最小值1001-01-01 00:00:00）,通過整型替代浮點(diǎn)型和字符型
2. 變長字段使用varchar，不要使用char
3. 對于二進(jìn)制多媒體數(shù)據(jù)，流水隊(duì)列數(shù)據(jù)(如日志)，超大文本數(shù)據(jù)不要放在數(shù)據(jù)庫字段中

規(guī)則4：業(yè)務(wù)邏輯執(zhí)行過程必須讀到的表中必須要有初始的值。避免業(yè)務(wù)讀出為負(fù)或無窮大的值導(dǎo)致程序失敗

規(guī)則5：并不需要一定遵守范式理論，適度的冗余，讓Query盡量減少Join

規(guī)則6：訪問頻率較低的大字段拆分出數(shù)據(jù)表。有些大字段占用空間多，訪問頻率較其他字段明顯要少很多，這種情況進(jìn)行拆分，頻繁的查詢中就不需要讀取大字段，造成IO資源的浪費(fèi)。

規(guī)則7： 水平分表，這個我還是建議 三思，搞不好非但不能提升性能反而多了很多的join和磁盤IO，開發(fā)起來也麻煩，有很多的業(yè)務(wù)就是要求一次查詢大部分的字段 看你業(yè)務(wù)場景了。大表可以考慮水平拆分。大表影響查詢效率，根據(jù)業(yè)務(wù)特性有很多拆分方式，像根據(jù)時間遞增的數(shù)據(jù)，可以根據(jù)時間來分。以id劃分的數(shù)據(jù)，可根據(jù)id%數(shù)據(jù)庫個數(shù)的方式來拆分。

規(guī)則8：業(yè)務(wù)需要的相關(guān)索引是根據(jù)實(shí)際的設(shè)計所構(gòu)造sql語句的where條件來確定的，業(yè)務(wù)不需要的不要建索引，不允許在聯(lián)合索引（或主鍵）中存在多于的字段。特別是該字段根本不會在條件語句中出現(xiàn)。

規(guī)則9：唯一確定一條記錄的一個字段或多個字段要建立主鍵或者唯一索引，不能唯一確定一條記錄，為了提高查詢效率建普通索引。

規(guī)則10：業(yè)務(wù)使用的表，有些記錄數(shù)很少，甚至只有一條記錄，為了約束的需要，也要建立索引或者設(shè)置主鍵。

規(guī)則11：對于取值不能重復(fù)，經(jīng)常作為查詢條件的字段，應(yīng)該建唯一索引(主鍵默認(rèn)唯一索引)，并且將查詢條件中該字段的條件置于第一個位置。沒有必要再建立與該字段有關(guān)的聯(lián)合索引。

規(guī)則12：對于經(jīng)常查詢的字段，其值不唯一，也應(yīng)該考慮建立普通索引，查詢語句中該字段條件置于第一個位置，對聯(lián)合索引處理的方法同樣。

規(guī)則13：業(yè)務(wù)通過不唯一索引訪問數(shù)據(jù)時，需要考慮通過該索引值返回的記錄稠密度，原則上可能的稠密度最大不能高于0.2，如果稠密度太大，則不合適建立索引了。

規(guī)則14：需要聯(lián)合索引(或聯(lián)合主鍵)的數(shù)據(jù)庫要注意索引的順序。SQL語句中的匹配條件也要跟索引的順序保持一致。

注意：索引的順勢不正確也可能導(dǎo)致嚴(yán)重的后果。

規(guī)則15：表中的多個字段查詢作為查詢條件，不含有其他索引，并且字段聯(lián)合值不重復(fù)，可以在這多個字段上建唯一的聯(lián)合索引，假設(shè)索引字段為 (a1,a2,...an),則查詢條件(a1 op val1,a2 op val2,...am op valm)m<=n,可以用到索引，查詢條件中字段的位置與索引中的字段位置是一致的。

規(guī)則16：聯(lián)合索引的建立原則(以下均假設(shè)在數(shù)據(jù)庫表的字段a,b,c上建立聯(lián)合索引(a,b,c))。

規(guī)則17：重要業(yè)務(wù)訪問數(shù)據(jù)表時。但不能通過索引訪問數(shù)據(jù)時，應(yīng)該確保順序訪問的記錄數(shù)目是有限的，原則上不得多于10。

規(guī)則18：合理構(gòu)造Query語句，慢SQL監(jiān)控，檢查是否有大量的的子查詢和關(guān)聯(lián)查詢 嵌套查詢等，盡量避免使用這些查詢，使用連接（JOIN）來代替子查詢(Sub-Queries)，使用聯(lián)合(UNION)來代替手動創(chuàng)建的臨時表。

規(guī)則19：應(yīng)用系統(tǒng)的優(yōu)化。

規(guī)則20：可以結(jié)合redis，memcache等緩存服務(wù)，把這些復(fù)雜的sql進(jìn)行拆分，充分利用二級緩存，減少數(shù)據(jù)庫IO操作。對數(shù)據(jù)庫連接池，mybatis，hiberante二級緩存充分利用上。盡量使用順序IO代替隨機(jī)IO。合理使用索引，盡量避免全表掃描。