數(shù)據(jù)庫(kù)的架構(gòu)設(shè)計(jì)與性能優(yōu)化

1、 數(shù)據(jù)庫(kù)的架構(gòu)設(shè)計(jì)與性能優(yōu)化摘要構(gòu)建高性能的SaaS應(yīng)用，僅憑云服務(wù)基礎(chǔ)設(shè)施是不夠的。如何基于云服務(wù)平臺(tái)設(shè)計(jì)并實(shí)施符合自身業(yè)務(wù)特點(diǎn)的系統(tǒng)架構(gòu)，也是決定產(chǎn)品性能的關(guān)鍵。本文將講述我們?nèi)绾卫迷品?wù)，使用相對(duì)經(jīng)濟(jì)的方案，解決海量用戶的數(shù)據(jù)庫(kù)使用問(wèn)題。本文首發(fā)于阿里云&程序員雜志聯(lián)合出品的凌云?？?。作者：杭州湖畔網(wǎng)絡(luò)技術(shù)經(jīng)理王鑫鵬杭州湖畔網(wǎng)絡(luò)技術(shù)有限公司是一家專業(yè)提供SaaS化電商ERP服務(wù)的創(chuàng)業(yè)公司，主要用戶群體為經(jīng)營(yíng)淘寶、天貓、京東等主流電商平臺(tái)、自建商城、線下渠道的商家及中小企業(yè)。作為SaaS服務(wù)提供商，服務(wù)數(shù)萬(wàn)乃至數(shù)十萬(wàn)級(jí)用戶是業(yè)務(wù)架構(gòu)初期就必須考慮的問(wèn)題。龐大的用戶群以及海量的用戶數(shù)據(jù)意

2、味著基礎(chǔ)設(shè)施的構(gòu)建必須兼顧高效與穩(wěn)定，而按照通用的基礎(chǔ)設(shè)施建設(shè)方案的話，需要面對(duì)成本過(guò)高、實(shí)現(xiàn)復(fù)雜、需要投入太多精力等問(wèn)題，這對(duì)當(dāng)時(shí)的湖畔網(wǎng)絡(luò)這樣的初創(chuàng)公司來(lái)說(shuō)，完全不能承受。因此，更經(jīng)濟(jì)、更方便擴(kuò)展的云服務(wù)平臺(tái)成為首選。在對(duì)比現(xiàn)有各家云服務(wù)后，我們選擇了穩(wěn)定性與成熟度都經(jīng)過(guò)大量用戶檢驗(yàn)的阿里云。但要構(gòu)建高性能的SaaS應(yīng)用，僅憑云服務(wù)基礎(chǔ)設(shè)施是不夠的。如何基于云服務(wù)平臺(tái)設(shè)計(jì)并實(shí)施符合自身業(yè)務(wù)特點(diǎn)的系統(tǒng)架構(gòu)，也是決定產(chǎn)品性能的關(guān)鍵。本文將講述我們?nèi)绾卫迷品?wù)，使用相對(duì)經(jīng)濟(jì)的方案，解決海量用戶的數(shù)據(jù)庫(kù)使用問(wèn)題。架構(gòu)我們的SaaS化電商ERP服務(wù)的整體架構(gòu)是基于阿里云服務(wù)平臺(tái)實(shí)施的，如圖1所示。

3、 采用SLB（Server Load Balance，負(fù)載均衡）作為Web集群訪問(wèn)入口，負(fù)責(zé)為Web端的多臺(tái)服務(wù)器進(jìn)行流量分發(fā)。SLB是基于集群建設(shè)的，并且可以隨時(shí)變配，按量付費(fèi)。它不僅為我們實(shí)現(xiàn)了成熟的負(fù)載均衡方案，其穩(wěn)定性與靈活性也為Web集群提供了更多可能。 后端配置多臺(tái)ECS（Elastic Compute Service，云服務(wù)器）實(shí)例，將主要應(yīng)用服務(wù)都部署在ECS上。除了可彈性擴(kuò)容這一特性，ECS提供的安全防護(hù)和快照備份為服務(wù)器安全和容災(zāi)提供了非常成熟的解決方案，這恰恰是我們這種業(yè)務(wù)型創(chuàng)業(yè)團(tuán)隊(duì)積累相對(duì)最薄弱的方面。另外，ECS多線接入骨干網(wǎng)絡(luò)能保證網(wǎng)絡(luò)的穩(wěn)定和性能，使得任何網(wǎng)絡(luò)的用

4、戶訪問(wèn)應(yīng)用服務(wù)都非常順暢。 DB集群由多臺(tái)RDS（Relational Database Service，關(guān)系型數(shù)據(jù)庫(kù)服務(wù)）實(shí)例組成。RDS是云數(shù)據(jù)庫(kù)，簡(jiǎn)單易用，使用方法與自行部署的數(shù)據(jù)庫(kù)完全一樣。其成熟的雙機(jī)熱備與底層資源隔離，保證了我們這兩年來(lái)數(shù)據(jù)庫(kù)的平穩(wěn)運(yùn)行。另外，強(qiáng)大的iDB Cloud控制臺(tái)、專業(yè)的DBA團(tuán)隊(duì)支持，為我們監(jiān)控?cái)?shù)據(jù)庫(kù)運(yùn)行狀況、定位和解決數(shù)據(jù)庫(kù)問(wèn)題，提供了非常多的建議和幫助。 集群之間的共享資源統(tǒng)一存放在OCS（Open Cache Service，開放緩存服務(wù)）中。我們用OCS來(lái)存放數(shù)據(jù)路由和實(shí)時(shí)性不高的業(yè)務(wù)數(shù)據(jù)。緩存作為我們架構(gòu)性能中非常重要的一個(gè)環(huán)節(jié)，在承受了來(lái)自整

5、個(gè)集群各方面壓力的同時(shí)，還要保證響應(yīng)穩(wěn)定高速。通過(guò)該方案，不僅發(fā)揮了阿里云的優(yōu)勢(shì)（不涉及物理機(jī)器的維護(hù)和折損，靈活地配置升級(jí)，成熟的備份與快照方案），而且通過(guò)集群，避免了系統(tǒng)可能會(huì)遇到的單點(diǎn)故障，提高了系統(tǒng)彈性擴(kuò)容的靈活性和可用性。作為一個(gè)SaaS化、數(shù)據(jù)更集中、數(shù)據(jù)體量龐大的企業(yè)應(yīng)用，數(shù)據(jù)庫(kù)是我們整體架構(gòu)中的關(guān)鍵節(jié)點(diǎn)，如何保證其穩(wěn)定與性能，是本文講述的重點(diǎn)。當(dāng)用戶進(jìn)入快速增長(zhǎng)期后，隨著業(yè)務(wù)量迅速增加，核心業(yè)務(wù)表的存量數(shù)據(jù)和增長(zhǎng)速度絕對(duì)不是單個(gè)DB所能承受的（幾乎所有單DB配置都存在性能物理上限瓶頸，即使選擇升級(jí)配置也會(huì)受到成本和資源上限的約束）。因此，我們一開始就將數(shù)據(jù)庫(kù)分庫(kù)分片（Shard

6、ing）作為一個(gè)可行方案優(yōu)先考慮，主要分析如下。 場(chǎng)景：業(yè)務(wù)熱點(diǎn)數(shù)據(jù)持續(xù)增加，團(tuán)隊(duì)有一定的數(shù)據(jù)庫(kù)架構(gòu)積累能支撐獨(dú)立研發(fā)或熟悉成熟的中間件（如Cobar）。 優(yōu)點(diǎn)：成本低（可以利用開源免費(fèi)的數(shù)據(jù)庫(kù)集群替代大型商業(yè)DB）；可靈活擴(kuò)容（不斷增加新的數(shù)據(jù)庫(kù)切片即可）；相對(duì)均勻分布的數(shù)據(jù)讀寫，避免單點(diǎn)障礙。 缺點(diǎn)：需要研發(fā)團(tuán)隊(duì)在數(shù)據(jù)庫(kù)架構(gòu)上投入大量精力；數(shù)據(jù)庫(kù)集群維護(hù)需要成本投入。考慮到業(yè)務(wù)特性，我們最終采用了行業(yè)比較通用的水平拆分+垂直拆分策略，并自主完成DAO與JDBC之間的數(shù)據(jù)訪問(wèn)封裝層開發(fā)工作。水平拆分：按用戶將數(shù)據(jù)拆分到多個(gè)庫(kù)的相同表中水平拆分的思路，就是將原本存放在單個(gè)RDS數(shù)據(jù)庫(kù)中的數(shù)據(jù)，

7、根據(jù)業(yè)務(wù)ID不同，拆分到多個(gè)數(shù)據(jù)庫(kù)中（參見圖2）。拆分后，各庫(kù)的表數(shù)量及表結(jié)構(gòu)都保持一致。水平拆分首先需要確立唯一的業(yè)務(wù)主表，即其他所有表的數(shù)據(jù)都與主表ID（前文所說(shuō)的業(yè)務(wù)ID）存在直接或間接的主從關(guān)系，可以通過(guò)主表ID對(duì)全部數(shù)據(jù)做很好的切分。我們選擇的業(yè)務(wù)主表為用戶表，其他業(yè)務(wù)表或表的父表都包含一個(gè)用戶ID。因此，我們切分的目標(biāo)就是將不同用戶數(shù)據(jù)存放到不同的數(shù)據(jù)庫(kù)中。確定了拆分規(guī)則后，下一步是著手封裝Sping數(shù)據(jù)訪問(wèn)封裝層（DBWrapper）。DBWrapper介于DAO與JDBC之間，每個(gè)業(yè)務(wù)DAO進(jìn)行數(shù)據(jù)庫(kù)基本操作，都會(huì)經(jīng)過(guò)DBWrapper。它的主要作用是將數(shù)據(jù)庫(kù)架構(gòu)的變化對(duì)業(yè)務(wù)層

8、透明，業(yè)務(wù)層可以如同操作單個(gè)DB一樣，調(diào)用DBWrapper提供的數(shù)據(jù)庫(kù)操作接口，而判斷操作哪個(gè)數(shù)據(jù)庫(kù)的邏輯，則全部交由DBWrapper封裝完成（參見圖3）。DBWrapper主要提供新用戶初始化和數(shù)據(jù)庫(kù)操作接口。在新增用戶初始化到系統(tǒng)時(shí)，需先動(dòng)態(tài)判斷系統(tǒng)各庫(kù)的負(fù)載分布情況。粗略一點(diǎn)的算法就是判斷各庫(kù)的用戶數(shù)，如共有4個(gè)庫(kù)，可以根據(jù)user_id%4的情況決定目標(biāo)庫(kù)；再精細(xì)一點(diǎn)可以挖掘下核心業(yè)務(wù)數(shù)據(jù)的分布情況，具體分配算法需要基于業(yè)務(wù)設(shè)定（如考慮不同用戶的平均訂單量）。通過(guò)各庫(kù)壓力綜合計(jì)算后，分析出壓力最小的目標(biāo)數(shù)據(jù)庫(kù)，并將該新增用戶數(shù)據(jù)存放到指定的目標(biāo)庫(kù)，同時(shí)更新路由信息（Router）。

9、當(dāng)用戶完成初始化進(jìn)行業(yè)務(wù)操作時(shí)，則需由業(yè)務(wù)層調(diào)用DBWrapper的操作接口。DBWrapper接收到請(qǐng)求后，會(huì)根據(jù)業(yè)務(wù)層傳入的User_id匹配Router，判斷最終需要操作的RDS實(shí)例和數(shù)據(jù)庫(kù)。判斷完成后，只需要按部就班地開連接執(zhí)行就可以了。具體的代碼實(shí)現(xiàn)，需要結(jié)合自身的持久層框架，找一名研究過(guò)持久層框架實(shí)現(xiàn)的開發(fā)人員即可完成。這樣就將系統(tǒng)用戶整體數(shù)據(jù)壓力，相對(duì)均勻地分布到多個(gè)RDS實(shí)例與數(shù)據(jù)庫(kù)上。事實(shí)證明，這確實(shí)是一個(gè)非常有效的方案，尤其是對(duì)于數(shù)據(jù)量大、增長(zhǎng)迅猛的表。只是在后續(xù)實(shí)施過(guò)程中，我們發(fā)現(xiàn)有時(shí)會(huì)有單個(gè)用戶的業(yè)務(wù)壓力比較突出，針對(duì)這種情況，我們可以通過(guò)一些人工干預(yù)（如遷移數(shù)據(jù)到單獨(dú)

10、的庫(kù)）進(jìn)行微調(diào)，當(dāng)然最終的解決方案還是要不斷調(diào)優(yōu)路由算法。切分后，不可避免地需要考慮數(shù)據(jù)字典（DD）和數(shù)據(jù)路由（Router）的處理。暫時(shí)我們采用的方法是將所有數(shù)據(jù)字典與路由放入獨(dú)立的庫(kù)，這也是后文中垂直拆分的一種應(yīng)用。需要說(shuō)明的是，數(shù)據(jù)庫(kù)僅是這兩個(gè)業(yè)務(wù)的一種實(shí)現(xiàn)方式，一般還可以通過(guò)或結(jié)合分布式緩存來(lái)處理這些業(yè)務(wù)（我們選用了OCS）。而對(duì)于可能出現(xiàn)的單點(diǎn)障礙，預(yù)留的擴(kuò)展方案為水平拆分或創(chuàng)建只讀節(jié)點(diǎn)（只讀節(jié)點(diǎn)可以使用RDS最新提供的只讀實(shí)例，目前還在內(nèi)測(cè)階段）。垂直拆分：按業(yè)務(wù)將表分組拆分到多個(gè)庫(kù)中與水平拆分相比，垂直拆分要更簡(jiǎn)單一些。其基本思路就是將存放在單個(gè)數(shù)據(jù)庫(kù)的表分組，把其中業(yè)務(wù)耦合度較

11、高、聯(lián)系緊密的表分為一組，拆分到其他DB中（參見圖4）。拆分后，各庫(kù)的表結(jié)構(gòu)及其業(yè)務(wù)意義將完全不同。雖然規(guī)則簡(jiǎn)單、實(shí)施方便，但垂直拆分總是需打斷些關(guān)聯(lián)，因?yàn)閷?shí)際操作中，基礎(chǔ)資源常常出現(xiàn)在各個(gè)業(yè)務(wù)場(chǎng)景，在切分時(shí)又不得不切分到兩個(gè)庫(kù)中，此時(shí)就需要業(yè)務(wù)層多次查詢后，在內(nèi)存處理數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)Join的效果。垂直拆分同樣需要DBWrapper，但封裝規(guī)則與水平拆分略有不同，需要針對(duì)不同的業(yè)務(wù)，建立不同的DBWrapper。此時(shí)不再是完全業(yè)務(wù)層無(wú)感知，需要業(yè)務(wù)層根據(jù)業(yè)務(wù)場(chǎng)景有針對(duì)性使用。單個(gè)DBWrapper的實(shí)現(xiàn)與水平拆分一致。垂直拆分的好處在于，將整體業(yè)務(wù)數(shù)據(jù)切分成相對(duì)獨(dú)立的幾塊，隔離了不同業(yè)務(wù)之間

12、的性能影響。而由于拆分后的數(shù)據(jù)庫(kù)業(yè)務(wù)比較集中，也更容易找到業(yè)務(wù)主表，更有利于水平拆分。對(duì)于垂直拆分，目前我們主要用于解決數(shù)據(jù)路由（包含了用戶的基本信息）、數(shù)據(jù)字典模塊，以及常見的冷數(shù)據(jù)問(wèn)題。冷數(shù)據(jù)的處理一直是行業(yè)的常見問(wèn)題（其實(shí)對(duì)于冷數(shù)據(jù)的劃分，也是水平拆分），目前我們采用的方案是集中存儲(chǔ)，即按自己的冷數(shù)據(jù)切分方式，通過(guò)自行開發(fā)的遷移程序?qū)⑴卸ǖ睦鋽?shù)據(jù)增量遷移到一個(gè)庫(kù)中。這個(gè)方案既能夠分離冷數(shù)據(jù)對(duì)熱點(diǎn)數(shù)據(jù)的操作影響，也可以為大數(shù)據(jù)的挖掘提供比較便利的條件。使用相對(duì)獨(dú)立的冷數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，能方便以后采用更高效、成本更低廉的存儲(chǔ)介質(zhì)。當(dāng)然該方案存在一些潛在問(wèn)題，如果冷數(shù)據(jù)庫(kù)滿了該怎么辦？目前我們預(yù)留

13、的設(shè)計(jì)方案是，歷史庫(kù)的水平拆分，也可以考慮其他存儲(chǔ)形式。水平拆分與垂直拆分組合使用拆分一直是數(shù)據(jù)庫(kù)優(yōu)化的關(guān)鍵詞（無(wú)論是庫(kù)表結(jié)構(gòu)還是SQL寫法），它是每個(gè)高并發(fā)產(chǎn)品最終都要經(jīng)歷的一步。拆分方案的核心主要在于可以通過(guò)添加更多RDS實(shí)例和數(shù)據(jù)庫(kù)（常常為了節(jié)約成本，多個(gè)數(shù)據(jù)庫(kù)可以部署在一個(gè)RDS實(shí)例上），靈活擴(kuò)容系統(tǒng)的負(fù)載能力。在數(shù)據(jù)庫(kù)架構(gòu)中，水平拆分和垂直拆分一般都是搭配使用的，兩者的先后順序視具體情況而定。一般而言，垂直拆分更容易，也可以為水平拆分做鋪墊，一是業(yè)務(wù)集中，便于提取主表，二是垂直拆分后，可以只水平拆分壓力高的表，而業(yè)務(wù)增長(zhǎng)緩慢的表則可以保留單DB，從而提高拆分效率以及降低實(shí)施成本（參見

14、圖5）。我們之所以優(yōu)先水平拆分，主要原因還是成本和效率及當(dāng)時(shí)的一些局限性。只按業(yè)務(wù)ID（用戶）做好路由配置，這樣各個(gè)庫(kù)中的結(jié)構(gòu)完全一致，保留了原本的業(yè)務(wù)邏輯與實(shí)現(xiàn)，避免了跨庫(kù)關(guān)聯(lián)，能大大節(jié)省實(shí)現(xiàn)成本。盡管拆分有種種好處，但由于分布式事務(wù)及跨庫(kù)Join的實(shí)現(xiàn)復(fù)雜度較高及可用性較差，所以分布式事務(wù)一般都通過(guò)業(yè)務(wù)層使用樂(lè)觀鎖控制。而跨庫(kù)的表間關(guān)聯(lián)一定要打斷，否則性能和實(shí)現(xiàn)復(fù)雜度都會(huì)超出可接受范圍。對(duì)于跨庫(kù)的Join、Group by等問(wèn)題，都需要在業(yè)務(wù)層處理。目前我們采用的是分批查詢，在業(yè)務(wù)層組裝結(jié)果的方式。有些遺憾的是，由于我們?cè)缙谑褂肦DS時(shí)，阿里云尚未推出DRDS（分布式數(shù)據(jù)庫(kù)）產(chǎn)品，所以上述

15、拆分的數(shù)據(jù)庫(kù)底層架構(gòu)均是由我們自行研發(fā)的，投入了大量的精力。而現(xiàn)在有了DRDS，正準(zhǔn)備做拆分的團(tuán)隊(duì)，則無(wú)需再自己造輪子，直接拿來(lái)用即可，這樣團(tuán)隊(duì)可以將更多的精力放在業(yè)務(wù)上。小處大有可為雖然我們?cè)诩軜?gòu)上做了優(yōu)化，但在產(chǎn)品發(fā)展過(guò)程中還是會(huì)出現(xiàn)性能不太理想的情況。在阿里云支持中心和論壇上，也可以看到其他業(yè)務(wù)型團(tuán)隊(duì)反饋使用RDS時(shí)遇到類似的情況。最初大家都懷疑是不是RDS的底層資源隔離有問(wèn)題，多個(gè)用戶共享資源時(shí)發(fā)生爭(zhēng)搶，導(dǎo)致RDS的性能問(wèn)題。但在阿里云DBA的指導(dǎo)和協(xié)助下，發(fā)現(xiàn)是由于產(chǎn)品設(shè)計(jì)時(shí)對(duì)數(shù)據(jù)庫(kù)的使用太“不拘小節(jié)”，而隨著并發(fā)壓力與數(shù)據(jù)量增加，大量細(xì)小的性能問(wèn)題被放大，集中暴露出來(lái)。解決燈下黑：

16、修正業(yè)務(wù)層的數(shù)據(jù)庫(kù)操作陋習(xí) 場(chǎng)景：數(shù)據(jù)庫(kù)性能有問(wèn)題，應(yīng)優(yōu)先從業(yè)務(wù)層分析。 優(yōu)點(diǎn)：減輕數(shù)據(jù)庫(kù)的直接壓力，比執(zhí)行數(shù)據(jù)庫(kù)優(yōu)化方案更加迅速有效。 缺點(diǎn)：業(yè)務(wù)研發(fā)需要關(guān)注一些數(shù)據(jù)庫(kù)操作內(nèi)容；有時(shí)會(huì)犧牲一些業(yè)務(wù)；產(chǎn)品規(guī)模越大實(shí)施越困難。在數(shù)據(jù)庫(kù)的優(yōu)化過(guò)程中，研發(fā)團(tuán)隊(duì)最容易忽視的往往是業(yè)務(wù)層中的數(shù)據(jù)庫(kù)使用。一些優(yōu)化方案可以作為開發(fā)的常態(tài)化準(zhǔn)則。下面僅列舉幾個(gè)常用的優(yōu)化方案。 延遲加載。很多頁(yè)面展現(xiàn)時(shí)，單個(gè)實(shí)體實(shí)際只展現(xiàn)部分內(nèi)容，因此可按需加載，減輕數(shù)據(jù)庫(kù)壓力，又節(jié)省網(wǎng)絡(luò)流量。延遲加載也可體現(xiàn)在數(shù)據(jù)庫(kù)表的拆分設(shè)計(jì)上。 適當(dāng)緩存，以空間換時(shí)間。對(duì)于很多實(shí)時(shí)性較低或干脆就是數(shù)據(jù)字典的內(nèi)容，無(wú)需實(shí)時(shí)到數(shù)據(jù)庫(kù)中加載，

17、只需在使用前加載到內(nèi)存中，實(shí)際使用時(shí)到內(nèi)存中獲取即可。 減少不必要的開連接（連接池、批量查詢及提交）。對(duì)于大部分的Web應(yīng)用，連接池大大減少了系統(tǒng)因開數(shù)據(jù)庫(kù)連接產(chǎn)生的開銷。而在查詢和提交中，將多個(gè)任務(wù)合并到一次數(shù)據(jù)庫(kù)操作中，也可以大大提高數(shù)據(jù)庫(kù)使用效率。 樂(lè)觀鎖是高并發(fā)下不錯(cuò)的解決方式。相比于數(shù)據(jù)庫(kù)的悲觀鎖，業(yè)務(wù)層實(shí)現(xiàn)的樂(lè)觀鎖，不僅能減少鎖爭(zhēng)搶，還可以減少數(shù)據(jù)庫(kù)的鎖開銷，進(jìn)而提高數(shù)據(jù)庫(kù)使用效率。 分解大事務(wù)。數(shù)據(jù)庫(kù)對(duì)于大事務(wù)的原子性保證，也是不容忽視的開銷。業(yè)務(wù)使用時(shí)，盡量將大事務(wù)切分為小事務(wù)，或者適當(dāng)利用異步提交，精簡(jiǎn)事務(wù)體積。 合理使用Join。數(shù)據(jù)庫(kù)執(zhí)行計(jì)劃中，有一條準(zhǔn)則是越簡(jiǎn)單越快速。

18、所以通過(guò)適當(dāng)冗余數(shù)據(jù)設(shè)計(jì)或業(yè)務(wù)層分批查詢后內(nèi)存組裝數(shù)據(jù)，減少數(shù)據(jù)庫(kù)Join語(yǔ)句及SQL復(fù)雜度，對(duì)于數(shù)據(jù)庫(kù)執(zhí)行效率和執(zhí)行計(jì)劃的優(yōu)化都有不可忽視的好處。擠掉海綿里的水：優(yōu)化數(shù)據(jù)庫(kù)執(zhí)行計(jì)劃 場(chǎng)景：并發(fā)不多、數(shù)據(jù)量并不很大，或系統(tǒng)整體壓力較低，只有某幾個(gè)業(yè)務(wù)點(diǎn)性能較差。 優(yōu)點(diǎn)：在不改變基本條件的情況下，挖掘數(shù)據(jù)庫(kù)更大潛力。 缺點(diǎn)：需要DBA協(xié)助或研發(fā)團(tuán)隊(duì)對(duì)數(shù)據(jù)庫(kù)執(zhí)行計(jì)劃做研究。由于執(zhí)行計(jì)劃的優(yōu)化往往涉及到數(shù)據(jù)庫(kù)的運(yùn)行機(jī)制與底層設(shè)計(jì)，此處實(shí)難三言兩語(yǔ)說(shuō)清。所以下面僅列舉幾個(gè)我們受益頗深的優(yōu)化方案。建議大家優(yōu)化執(zhí)行計(jì)劃時(shí)，多關(guān)注、分析iDB Cloud控制臺(tái)中的性能報(bào)告和建議，也盡量多向阿里云DBA們請(qǐng)教

19、，一般可以通過(guò)提工單的方式。有條件或興趣的話，DBA可以通過(guò)預(yù)約到阿里云現(xiàn)場(chǎng)學(xué)習(xí)。另外，執(zhí)行計(jì)劃的優(yōu)化需要大量的調(diào)試工作，通過(guò)在阿里云控制臺(tái)創(chuàng)建生產(chǎn)數(shù)據(jù)庫(kù)的臨時(shí)實(shí)例，可以準(zhǔn)確模擬當(dāng)前系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)、分布與壓力。字段類型選擇選擇合理的字段，往往可以大大減少數(shù)據(jù)庫(kù)行數(shù)據(jù)的大小，并提高索引匹配的效率，進(jìn)而大大提升數(shù)據(jù)庫(kù)性能。使用更小的數(shù)據(jù)類型，如日期采用date代替datetime、類型或標(biāo)記使用tinyint代替smallint和int、使用定長(zhǎng)字段代替非定長(zhǎng)字段（如char代替varchar），都能或多或少減少數(shù)據(jù)行大小，提高數(shù)據(jù)庫(kù)緩沖池的命中率。而作為表字段中特殊的一員主鍵，其選型更會(huì)對(duì)表索引

20、的穩(wěn)定和效率帶來(lái)很大的影響，一般建議考慮數(shù)據(jù)庫(kù)自增或自主維護(hù)的唯一數(shù)值。高分離度字段建立索引對(duì)于查詢來(lái)講，高分離度字段往往意味著精準(zhǔn)或部分精準(zhǔn)的條件。相對(duì)來(lái)講是最好優(yōu)化的一種場(chǎng)景，只需要對(duì)分離度較高的字段單獨(dú)建立索引即可。當(dāng)然實(shí)際使用中會(huì)有更多細(xì)節(jié)需要摸索。精確條件在各業(yè)務(wù)中基本都會(huì)用到，在越復(fù)雜的業(yè)務(wù)場(chǎng)景中，精確條件優(yōu)先的原則，將是最有效的優(yōu)化方案。需要注意的是，盡管高分離度字段單獨(dú)建立索引效率很高，但過(guò)多的索引會(huì)影響表寫入的效率，所以需要謹(jǐn)慎添加。這一點(diǎn)iDB Cloud中有大表索引的建議可以參考。覆蓋索引（Covering Index）通俗一點(diǎn)理解，就是執(zhí)行計(jì)劃可以通過(guò)索引完成數(shù)據(jù)查找和

21、結(jié)果集獲取，而無(wú)需回表（去緩沖池或磁盤查找數(shù)據(jù)）。而由于MySQL的索引機(jī)制限制，一次查詢時(shí)，將只用到一個(gè)索引或?qū)蓚€(gè)索引聚合（index_merge）起來(lái)使用，所以意味著復(fù)雜的業(yè)務(wù)場(chǎng)景中，單獨(dú)對(duì)每個(gè)字段建立索引可能沒有什么用處。所以對(duì)于一些特定的查詢場(chǎng)景，建立合適的組合索引，應(yīng)用覆蓋索引方法可以避免大量隨機(jī)I/O，是更為推薦的優(yōu)化方案（如果執(zhí)行計(jì)劃Explain的Extra中有Using Index，就說(shuō)明使用了覆蓋索引）。但實(shí)際業(yè)務(wù)總是會(huì)比索引本身更復(fù)雜，業(yè)務(wù)中需要查找或者獲取的字段信息往往是很多的，而組合索引并不能涵蓋所有的字段（否則我們將擁有一個(gè)比數(shù)據(jù)還要龐大的索引）。此時(shí)，為了應(yīng)用覆

22、蓋索引，就需要使用主鍵延遲關(guān)聯(lián)（Deferred Join），即先通過(guò)組合索引中包含的字段條件，初步查詢出相對(duì)較小的結(jié)果集（面向結(jié)果集原則），該結(jié)果集只包含主鍵字段；然后通過(guò)獲取到的這個(gè)主鍵隊(duì)列，再對(duì)數(shù)據(jù)表做關(guān)聯(lián)。適當(dāng)妥協(xié)見招拆招：升配置 場(chǎng)景：性能問(wèn)題緊迫，團(tuán)隊(duì)時(shí)間資源有限。 優(yōu)點(diǎn)：簡(jiǎn)單粗暴見效快，基本適用于任何優(yōu)化階段。 缺點(diǎn)：增加成本；治標(biāo)不治本，只是延遲問(wèn)題再次爆發(fā)時(shí)間；資源總有上限，遲早升無(wú)可升。一般業(yè)務(wù)型的研發(fā)團(tuán)隊(duì)，很難有額外的精力投入到數(shù)據(jù)庫(kù)方面，也沒有專業(yè)的DBA來(lái)不斷調(diào)優(yōu)數(shù)據(jù)庫(kù)配置、優(yōu)化數(shù)據(jù)庫(kù)服務(wù)器性能。所以早期團(tuán)隊(duì)可以選擇的方案不多，也很難在技術(shù)上深挖下去，只能用成本換時(shí)間：性能配置不夠，那就升級(jí)服務(wù)器配置。那么問(wèn)題來(lái)了：自己部署的