一、系統(tǒng)性能問題五大特性

如果大家了解一些方法論的話，應(yīng)該聽過兩個(gè)原則：一個(gè)是海恩法則，強(qiáng)調(diào)量變引發(fā)質(zhì)變；另一個(gè)是老生常談的墨菲定律，強(qiáng)調(diào)會(huì)出錯(cuò)的事總會(huì)出錯(cuò)。針對(duì)這兩個(gè)原則，我總結(jié)了系統(tǒng)性能問題的五大特性。

1）系統(tǒng)響應(yīng)慢

不論負(fù)載情況如何，系統(tǒng)應(yīng)用程序一直特別慢，響應(yīng)時(shí)間長(zhǎng)。

2）時(shí)間序列日益緩慢

負(fù)載穩(wěn)定，但系統(tǒng)隨著時(shí)間推進(jìn)越來(lái)越慢，到達(dá)某個(gè)閾值后，系統(tǒng)可能會(huì)被鎖定或因大量錯(cuò)誤出現(xiàn)而崩潰。

3）突發(fā)混亂

系統(tǒng)穩(wěn)定運(yùn)行，在某一時(shí)刻突然出現(xiàn)大量錯(cuò)誤。

4）局部功能異常

用戶訪問部分頁(yè)面異常，上圖右下角圖片是用F12對(duì)訪問谷歌頁(yè)面進(jìn)行的截圖，從中可以看出，我們?cè)L問谷歌時(shí)一直超時(shí)，無(wú)法訪問。

5）隨負(fù)載變化越來(lái)越慢

用戶量增加時(shí)，系統(tǒng)明顯變慢，用戶離開系統(tǒng)后，系統(tǒng)恢復(fù)原狀。上圖左下角的圖片展示了CPU的使用情況，其從100%負(fù)載恢復(fù)到常態(tài)化，后續(xù)隨著用戶增加又逐漸漲至100%負(fù)載。

二、系統(tǒng)性能排查方略

1、系統(tǒng)性能排查方略方法論

系統(tǒng)性能排查方略可總結(jié)為以下兩點(diǎn)：

1）積極溝通，減小影響

利用5W1H原則了解問題現(xiàn)象，即什么問題、在什么時(shí)間、什么地點(diǎn)、如何發(fā)生、何人處理。同時(shí)還要收集現(xiàn)場(chǎng)信息，包括常見的日志信息、流量信息等，盡量做到全面排查。

• 安撫客戶，減小客戶影響。一件小事可能會(huì)由于客戶恐慌性的增長(zhǎng)釀成大事故。
• 基于歷史經(jīng)驗(yàn)緊急應(yīng)急。

2）大膽推敲，合理論證

• 根據(jù)異常信息要大膽推斷、合理論證，切忌“我推斷就是這樣，但我就不證明”；
• 進(jìn)行全鏈路考量，切忌單點(diǎn)揣測(cè)，比如直接認(rèn)定數(shù)據(jù)庫(kù)有問題，但是經(jīng)分析來(lái)看，數(shù)據(jù)庫(kù)負(fù)載實(shí)際上沒問題，而是網(wǎng)絡(luò)問題或中間件問題；
• 問題解決必須包含臨時(shí)方案和最終方案。用臨時(shí)方案以最快的方式消除影響，然后針對(duì)問題做最終方案，避免后續(xù)類似問題帶來(lái)的隱患。

為此，我通過魚骨圖進(jìn)一步描述問題的排查方式：

1）消除影響

首先需要消除對(duì)客戶的影響，其次要消除對(duì)系統(tǒng)的影響，可以通過歷史經(jīng)驗(yàn)緊急應(yīng)急或其他方式幫助客戶或系統(tǒng)避開問題。

2）收集現(xiàn)場(chǎng)

這一步強(qiáng)調(diào)日志的完備，同時(shí)我們需要知道發(fā)生問題時(shí)的問題數(shù)據(jù)和系統(tǒng)數(shù)據(jù)，才可通過數(shù)據(jù)進(jìn)行重演。

3）明確問題范圍

判斷發(fā)生的是個(gè)別交易問題還是普遍性問題。如果是個(gè)別交易問題，我們可以很快定位交易當(dāng)時(shí)做過哪些改變；如果是普遍性問題，我們要判斷哪些客戶、客流受到影響，以及這一問題是否會(huì)對(duì)其他方面造成影響。

4）問題分析

問題分析包括兩個(gè)方面，一方面是系統(tǒng)級(jí)鏈路分析，從最早的端到端的鏈路進(jìn)行統(tǒng)一排查；另一方面是交易級(jí)鏈路分析，從交易進(jìn)來(lái)后經(jīng)過中間件到數(shù)據(jù)庫(kù)返回，對(duì)整個(gè)交易級(jí)鏈路進(jìn)行分析。

5）問題解決方案

經(jīng)過之前的一系列步驟，最終我們就可以制定問題的解決方案。在制定解決方案時(shí)，一般會(huì)進(jìn)行數(shù)據(jù)修復(fù)和程序修復(fù)，在環(huán)境中同步驗(yàn)證，并將修改后的部分歸并至后續(xù)版本中，避免導(dǎo)致類似問題重復(fù)發(fā)生。

6） 問題總結(jié)

這一步主要是針對(duì)問題進(jìn)行復(fù)盤，從中發(fā)現(xiàn)優(yōu)化點(diǎn)，并從問題的處理方式中總結(jié)經(jīng)驗(yàn)教訓(xùn)，然后進(jìn)行一些橫向排查，沉淀為相關(guān)經(jīng)驗(yàn)。

下面向大家講述性能問題排查，其中包括兩大方面：系統(tǒng)環(huán)境和運(yùn)行環(huán)境。

1）系統(tǒng)環(huán)境

我們?cè)瓌t上通過APM工具監(jiān)控系統(tǒng)環(huán)境。業(yè)界已經(jīng)有些很好的開源監(jiān)控工具，比如Prometheus、Zabbix等，可以利用這些工具監(jiān)測(cè)CPU負(fù)荷、lO負(fù)荷、內(nèi)存負(fù)荷以及網(wǎng)絡(luò)負(fù)荷。

2）運(yùn)行環(huán)境

可以將運(yùn)行環(huán)境的問題大致分為以下三類：

① 數(shù)據(jù)庫(kù)

• 日志信息

對(duì)于MySQL，首先查看其錯(cuò)誤日志，通過mysql.err直接查看當(dāng)時(shí)到底有什么問題；如果交易比較緩慢，可以從慢SQL日志（一般是slow-queries.log）中查看，原則上大于10秒的交易都會(huì)在這里體現(xiàn)；接下來(lái)看事務(wù)日志，通過binlog查看當(dāng)時(shí)交易的情況，如果是備庫(kù)重演的一些問題，可以看主備中繼日志，通過relaylog查看備庫(kù)重演的狀態(tài)。

對(duì)于Oracle也大體相似，可以通過監(jiān)聽日志listener.log、lsnrctl status查看監(jiān)聽器的狀態(tài)，Oracle中有一個(gè)報(bào)警日志，通過alert.log可以查看當(dāng)時(shí)發(fā)生的事件。我們還可以進(jìn)一步打AWR報(bào)告和ASH報(bào)告，對(duì)數(shù)據(jù)庫(kù)進(jìn)行監(jiān)控，這一點(diǎn)MySQL不如Oracle。除此之外，Oracle也提供了一些歷史快照信息表，比如dba_hist_sqlstat和 dba_hist_snapshot，可以通過這兩張快照表獲取需要的任意快照時(shí)間的處理信息。最后，可以通過會(huì)話信息，查看當(dāng)前會(huì)話有哪些中間件正在訪問，以及整個(gè)會(huì)話的狀態(tài)。

• 性能分析

進(jìn)行性能分析時(shí)，我們可以查看執(zhí)行計(jì)劃。對(duì)于MySQL，我們可以通過explain語(yǔ)句看當(dāng)時(shí)的執(zhí)行計(jì)劃，到底有沒有走索引，索引走得好不好。對(duì)于Oracle，我們可以通過v$sql_plan和dba_hist _sql_plan查看執(zhí)行計(jì)劃變更的原因，針對(duì)執(zhí)行計(jì)劃對(duì)索引進(jìn)行重建。除此之外，我們還要對(duì)死鎖進(jìn)行分析，并處理等待事件。

② 中間件

對(duì)于中間件，例如業(yè)界使用較多的WAS、Liberty、Tomcat以及國(guó)產(chǎn)的東方通等，我們可以查看它的一些線程信息。這里建議大家打出3~5個(gè)javacore，一般是1分鐘打一個(gè)，這樣可以通過IBM的jca4611.jar工具對(duì)比分析問題出于哪個(gè)線程，或者線程卡在何種情況之下。

如果涉及到OOM（內(nèi)存溢出），可以打出heapdump的信息，再通過IBM的ha457.jar工具進(jìn)行分析。

我們可以通過GC信息看是否因?yàn)榉?wù)器full gc導(dǎo)致系統(tǒng)持續(xù)夯住，如果是，可以對(duì)vm信息進(jìn)行調(diào)優(yōu)。除此之外，中間件還會(huì)打一些日志信息，可以從中發(fā)現(xiàn)當(dāng)時(shí)發(fā)生的問題。最后可以監(jiān)控一些中間件的資源信息，包括數(shù)據(jù)庫(kù)連接池、線程池和一些web容器。

③ 應(yīng)用程序

若發(fā)現(xiàn)數(shù)據(jù)庫(kù)和中間件都沒有問題，我們?cè)倏磻?yīng)用程序。

對(duì)于前臺(tái)來(lái)說，我們看是不是因?yàn)樗谇芭_(tái)做了緩存，沒有實(shí)時(shí)刷新，因此導(dǎo)致新請(qǐng)求獲得老交易，最終出現(xiàn)問題。除此之外可以看請(qǐng)求連接數(shù)，瀏覽器的請(qǐng)求連接數(shù)實(shí)際上是有限的，請(qǐng)求連接數(shù)過大也會(huì)導(dǎo)致應(yīng)用程序出問題。最后可以看一下是否因?yàn)橘Y源過大導(dǎo)致網(wǎng)絡(luò)傳輸量較大，這種問題可以通過兩種方式解決，一種是資源壓縮，另一種是將資源部署在CDN上。

對(duì)于邏輯層來(lái)說，我們可以看它有沒有資源釋放，包括數(shù)據(jù)庫(kù)連接、文件讀寫、socket、緩存等。然后可以看事務(wù)問題，比如事務(wù)長(zhǎng)時(shí)間沒有結(jié)束，這樣會(huì)卡死很多線程信息，循環(huán)處理數(shù)據(jù)庫(kù)也會(huì)導(dǎo)致事務(wù)的持續(xù)時(shí)間較長(zhǎng)。最后可以看多線程信息中是否包含鎖等待，是否存在數(shù)據(jù)污染。

綜上所述，系統(tǒng)性能排查有四個(gè)關(guān)鍵點(diǎn)：查看完備的日志、利用良好的工具、執(zhí)行計(jì)劃和關(guān)注邏輯問題。

接下來(lái)會(huì)對(duì)java中間件和數(shù)據(jù)庫(kù)性能兩部分進(jìn)行詳細(xì)分析：

2、java中間件分析

1）通過jca分析javacore

我對(duì)比了4個(gè)javacore文件，發(fā)現(xiàn)大部分問題集中在無(wú)法獲取連接池，即連接池都已經(jīng)被占滿且長(zhǎng)時(shí)間沒有釋放，這時(shí)可以結(jié)合連接池情況快速定位問題。

2）分析oom對(duì)象

對(duì)于oom對(duì)象，上圖可以看出有一個(gè)情況是BankFunctionTypePool中，oom大約存了1G空間，換言之，已直接將jvm內(nèi)存耗盡。這種情況下，一般建議heapdump加上javacore共同做分析，這樣可以快速定位問題。

3、數(shù)據(jù)庫(kù)相關(guān)問題分析

針對(duì)數(shù)據(jù)庫(kù)方面的問題，有如下分析流程。

一般出現(xiàn)問題場(chǎng)景后，首先通過日志分析判斷是不是數(shù)據(jù)庫(kù)無(wú)法連接。

如果數(shù)據(jù)庫(kù)無(wú)法連接，就檢查監(jiān)聽狀態(tài)。如果是Oracle，listener.log并沒有狀態(tài)的日志記錄，可以檢查lsnrctl status，然后配置TNS，啟動(dòng)監(jiān)聽器，確保數(shù)據(jù)庫(kù)正常訪問。如果是MySQL，可以檢查mysql.err文件，發(fā)現(xiàn)其中有一個(gè)access denied報(bào)錯(cuò)，這種情況下我們做好訪問授權(quán)并確認(rèn)防火墻，之后數(shù)據(jù)庫(kù)就可以正常訪問。

如果數(shù)據(jù)庫(kù)可以連接，但是數(shù)據(jù)庫(kù)執(zhí)行時(shí)間過長(zhǎng)，這種情況下應(yīng)該按照以下方法解決。

如果是Oracle，可以打印問題時(shí)刻的AWR報(bào)告，定位問題語(yǔ)句（一般關(guān)注Logons、Top 5 events、SQL order by Elapsed time等），然后處理問題。如需進(jìn)一步查勘，可以打印ASH報(bào)告，查看歷史同期問題引進(jìn)的變化情況，從而快速定位一些問題。如果是MySQL，一般檢查mysql.err的錯(cuò)誤日志，然后檢查slow-queries.log，如需進(jìn)一步查勘，可以把performance_schema.events _statements_summary_by_digest表中的數(shù)據(jù)提取出來(lái)進(jìn)行進(jìn)一步查勘。

一般來(lái)說，數(shù)據(jù)庫(kù)相關(guān)問題可分為以下4種：

1）如果有死鎖，需要調(diào)整業(yè)務(wù)邏輯順序，進(jìn)行壓測(cè)，然后驗(yàn)證結(jié)束。

2）如果沒有死鎖，只是執(zhí)行計(jì)劃有問題，例如出現(xiàn)一個(gè)全表掃，則在上面增加合適的索引處理。

3）如果有索引，需要判斷它的區(qū)分度：如果區(qū)分度高并且數(shù)據(jù)變動(dòng)頻繁，需要更新統(tǒng)計(jì)信息；如果區(qū)分度低，就決定索引是否合適，如果不合適就重建索引，選擇合適的索引進(jìn)行處理。

4）最后需要看數(shù)據(jù)量的大小，如果超過了規(guī)范的閾值，就要進(jìn)行分庫(kù)分表以及分區(qū)策略。

我們將邏輯調(diào)整后，再進(jìn)行相關(guān)壓測(cè)，當(dāng)壓測(cè)滿意時(shí)驗(yàn)證結(jié)束，真正上生產(chǎn)去做處理。

三、MySQL調(diào)優(yōu)策略

1、索引

1）一般建議大家查看執(zhí)行計(jì)劃，從我目前的分析來(lái)看，語(yǔ)句問題占90%以上；

2）命中索引并不等于ok；

3）執(zhí)行計(jì)劃最少應(yīng)該達(dá)到范圍掃，一般建議達(dá)到ref程度。

對(duì)于MySQL的執(zhí)行計(jì)劃，有 id、select_type、table等列，其中我一般會(huì)關(guān)注表中的type，它表示訪問類型，決定了MySQL在表中找到所需要行的方式。

我在上圖右方列出了效率情況：

system (無(wú)需磁盤IO)> const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

接下來(lái)查看key還有key_len的值，使用索引的字節(jié)長(zhǎng)度越短越好，可以根據(jù)表定義大概計(jì)算出索引的最大可能長(zhǎng)度，可用于復(fù)合索引的實(shí)際使用字段情況。

之后查看rows，一般情況下建議rows值越小越好。其他例如filtered和Extra等也是比較關(guān)鍵的信息，這里不再贅述，大家可以參考上圖中的表格。

2、分庫(kù)分表

針對(duì)分庫(kù)分表，首先要關(guān)注一個(gè)問題，單表數(shù)據(jù)量達(dá)到多少才需要進(jìn)行分庫(kù)？

阿里手冊(cè)中寫到數(shù)據(jù)量達(dá)到500萬(wàn)進(jìn)行分庫(kù)分表。業(yè)界的說法是數(shù)據(jù)量達(dá)到2,000萬(wàn)進(jìn)行分庫(kù)分表。其源頭是百度的一個(gè)DBA進(jìn)行壓測(cè)后，覺得壓到2,000萬(wàn)沒問題，但是超過2,000萬(wàn)后性能會(huì)出現(xiàn)問題，所以業(yè)界流傳的數(shù)據(jù)量界限是2,000萬(wàn)。

對(duì)于我行來(lái)說，MySQL規(guī)范建議數(shù)據(jù)量達(dá)3,000萬(wàn)進(jìn)行分庫(kù)分表。

MySQL索引分為兩種，一種是聚簇索引，即主鍵索引，索引和數(shù)據(jù)保持在一起。另一種是secondary Index，即輔助索引。

下面簡(jiǎn)單介紹一些基礎(chǔ)知識(shí)：

• MySQL的表數(shù)據(jù)是以頁(yè)形式存放，默認(rèn)16k，innodb_page_size值是16384，除以1024正好是16k。
• 一般索引為B+樹，葉子存儲(chǔ)數(shù)據(jù)，非葉子存儲(chǔ)主鍵和指向頁(yè)號(hào)，一般是12byte，因?yàn)槭褂胋igint會(huì)占8字節(jié)，同時(shí)lot0types.h中源代碼有一個(gè)指針FIL_PAGE_OFFSET，占了4字節(jié)，所以非葉子存儲(chǔ)大約存儲(chǔ)12字節(jié)。
• 數(shù)據(jù)頁(yè)數(shù)據(jù)僅有15k左右可以存儲(chǔ)數(shù)據(jù)，因?yàn)轫?yè)頭、頁(yè)目錄和頁(yè)尾也會(huì)占1k的空間。
• B+樹扇出率較高，15k除以12byte，它每一個(gè)節(jié)點(diǎn)可以指向1280個(gè)葉子。B+樹一般的建議層級(jí)是2~4層，保證查找某一鍵值，最多2~4次IO即可。主鍵索引一般也都在3層左右。
• 這里還涉及到一個(gè)iops知識(shí)，因?yàn)榇蠹抑坝脵C(jī)械硬盤，一般進(jìn)行一次io操作需要0.01秒，而現(xiàn)在大家普遍常見的SSD都是上萬(wàn)的ops，MySQL的訪問效率比以前高很多。

針對(duì)以上基礎(chǔ)知識(shí)，作以下具體說明：

數(shù)據(jù)量=扇出值^(B+樹層數(shù)-1)*葉子節(jié)點(diǎn)存儲(chǔ)行數(shù)

例如我們行的行占用大小約為850Byte字節(jié)，每個(gè)葉子節(jié)點(diǎn)可以存儲(chǔ)18行，數(shù)據(jù)量為2,900萬(wàn)左右，這也是3,000萬(wàn)的分庫(kù)分表界限的來(lái)源。百度行占用大小是1K，每個(gè)葉子節(jié)點(diǎn)存儲(chǔ)15行數(shù)據(jù)，數(shù)據(jù)量為2400萬(wàn)左右，所以業(yè)界才有2,000萬(wàn)這一說法。阿里同理，經(jīng)過計(jì)算強(qiáng)調(diào)數(shù)據(jù)量超過500萬(wàn)進(jìn)行分庫(kù)分表。

我們要了解規(guī)范數(shù)字背后的含義，這樣很多問題就會(huì)迎刃而解。除此之外，服務(wù)器配置、數(shù)據(jù)庫(kù)版本等因素也會(huì)影響查詢速度。

3、鎖問題

MySQL官方對(duì)鎖有較詳細(xì)的介紹，一般常見類型是讀鎖和寫鎖。讀鎖包含兩種鎖：記錄鎖和間隙鎖。我行用READ-COMMITTED規(guī)避間隙鎖。

大家通過mysql.err看日志表現(xiàn)，可以看到有l(wèi)ock_mode X和locks rec but not gap，這是記錄鎖的含義。

這里需要關(guān)注以下兩點(diǎn)：

1）鎖競(jìng)爭(zhēng)

5.7版本中我們從locks、locks_waits表查看鎖，但是8.0版本從infomation_spchema遷至performance_schema。下面舉一個(gè)例子進(jìn)行說明。

事務(wù)1是start transaction，更新同一個(gè)id=1的值，事務(wù)也對(duì)它進(jìn)行更新，50秒后，它會(huì)拋一個(gè)1205錯(cuò)誤，直接顯示鎖等待超時(shí)。我們建議一個(gè)鎖等待超時(shí)的時(shí)間是5~10秒，從而避免對(duì)事務(wù)造成較大影響。

2）死鎖檢測(cè)

死鎖檢測(cè)本質(zhì)是哲學(xué)家的問題：2個(gè)及以上事務(wù)，雙方都在等待對(duì)方釋放已經(jīng)持有的資源，最后造成等待循環(huán)，形成死鎖。

針對(duì)MySQL實(shí)現(xiàn)機(jī)制，大家看lock0lock.cc，它本質(zhì)是進(jìn)行深度優(yōu)先機(jī)制，如果發(fā)現(xiàn)環(huán)，則認(rèn)為是一個(gè)死鎖，同時(shí)回滾undo log量小的事務(wù)。

如果大家查看mysql.err，可以發(fā)現(xiàn)它第一步有一個(gè)deadlock detected，然后事務(wù)1會(huì)等待另外一個(gè)記錄鎖去釋放，事務(wù)2也會(huì)等待事務(wù)1的記錄鎖去釋放，最后因?yàn)槭聞?wù)2回滾量較小，所以回滾了事務(wù)2。

4、Google Trends & DB-Engines

MySQL和PostgreSQL這兩個(gè)數(shù)據(jù)庫(kù)都很好，但是對(duì)于我們國(guó)家來(lái)說，在Google Trends上MySQL的熱度更高一點(diǎn)，占比大概是89%，PostgreSQL占比是11%左右。我們搜索關(guān)鍵字時(shí)，最多的是怎么編譯MySQL，這說明我國(guó)對(duì)源碼的掌握和編譯有較為熱切的需求。從DB-Engines Rank中可以看到MySQL和Oracle一直不相上下，PostgreSQL的熱度也在逐步上升。

四、MySQL性能管控體系

接下來(lái)分享我們行的性能管控體系。

“免費(fèi)的午餐并不好吃”，隨著MySQL的廣泛應(yīng)用，大家并不注意開發(fā)規(guī)范，這會(huì)導(dǎo)致慢SQL數(shù)量呈爆發(fā)式增長(zhǎng)。一條慢SQL就可以導(dǎo)致服務(wù)不可用，降低用戶幸福指數(shù)。我們?yōu)榇藰?gòu)建管控體系確保開發(fā)合規(guī)和性能管控。

1、性能管控體系

1）研發(fā)流水線 （DevOps） +  QA定期檢查 （線下）

首先我們通過研發(fā)流水線（DevOos）和QA定期檢查對(duì)整個(gè)研發(fā)環(huán)節(jié)進(jìn)行處理。具體可分為以下環(huán)節(jié)：

• 設(shè)計(jì)環(huán)節(jié)

在設(shè)計(jì)環(huán)節(jié)，我們建立了設(shè)計(jì)指引，做了一些元數(shù)據(jù)管理，并設(shè)置了能力提升課程提升大家的數(shù)據(jù)庫(kù)使用能力。我們也會(huì)推動(dòng)一些表結(jié)構(gòu)設(shè)計(jì)工具和元數(shù)據(jù)管理系統(tǒng)，限定大家局面處理問題，同時(shí)我們?cè)谶@一環(huán)節(jié)設(shè)置了門禁。

• 開發(fā)環(huán)節(jié)

這一環(huán)節(jié)我們將一些規(guī)范做到自動(dòng)化，包括SQL注入檢查和SQL寫法的規(guī)則。SonarQube有SonarLint插件可以做服務(wù)器端的同步，這也有利于在開發(fā)環(huán)節(jié)做性能管控。

• 測(cè)試環(huán)節(jié)

這一環(huán)節(jié)我們通過安全測(cè)試、性能測(cè)試和混沌測(cè)試進(jìn)行性能管控。

• 發(fā)布環(huán)節(jié)

發(fā)布環(huán)節(jié)會(huì)由我們的SRE發(fā)布一些態(tài)勢(shì)感知報(bào)告，從技術(shù)以及安全等層面對(duì)業(yè)務(wù)提出針對(duì)性建議及后續(xù)整改措施。

• 運(yùn)營(yíng)環(huán)節(jié)

在這一環(huán)節(jié)我們首先會(huì)進(jìn)行慢SQL的監(jiān)控治理，逐步減少大事務(wù)數(shù)據(jù)；大家可以看到上圖某部門有2個(gè)應(yīng)用，慢SQL數(shù)量12個(gè)，最大耗時(shí)246秒，平均耗時(shí)11.414秒。

其次，我們會(huì)進(jìn)行生產(chǎn)案例分析，將相關(guān)規(guī)則沉淀到知識(shí)庫(kù)，并將技術(shù)組件放入技術(shù)模型。除此之外，我們還會(huì)做一些AIOps根因分析。

最后我們會(huì)進(jìn)行一些慢SQL的監(jiān)控和查殺，將大事務(wù)提前扼殺，避免其對(duì)系統(tǒng)產(chǎn)生影響。

2）性能運(yùn)維事件響應(yīng)及溯源

我們會(huì)針對(duì)每一個(gè)問題反省并溯源，看到底是哪一環(huán)節(jié)出現(xiàn)問題，哪些環(huán)節(jié)可以進(jìn)行優(yōu)化。例如判斷：語(yǔ)句是否因?yàn)闆]有限定時(shí)間范圍的存在需求缺失情況？設(shè)計(jì)功能是否考慮到大表關(guān)聯(lián)這種設(shè)計(jì)缺陷？開發(fā)環(huán)節(jié)是否存在代碼缺陷？

檢查開發(fā)環(huán)節(jié)后我們會(huì)檢查測(cè)試環(huán)節(jié)是否有測(cè)試用例缺失、測(cè)試工具漏報(bào)等缺陷，最后檢查發(fā)布環(huán)節(jié)是否有發(fā)布標(biāo)準(zhǔn)等缺陷。

3）能力沉淀

最后我們會(huì)進(jìn)行能力沉淀，例如問題閉環(huán)追蹤、根因橫向排查，最后沉淀為知識(shí)庫(kù)、技術(shù)組件、度量模型。

2、MySQL開發(fā)規(guī)范

1）設(shè)計(jì)原則

在設(shè)計(jì)方面，我們有以下三大原則：

① 復(fù)用原則

在系統(tǒng)架構(gòu)時(shí)，應(yīng)考慮將相同或類似作用的信息使用同一套數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)。例如：通用參數(shù)表、通用字典表。

② 前瞻性原則

• 設(shè)計(jì)應(yīng)基于完整的產(chǎn)品定義和業(yè)務(wù)要素，而非當(dāng)前具體功能需求設(shè)計(jì)表結(jié)構(gòu)；
• 設(shè)計(jì)應(yīng)基于完整的生命周期和業(yè)務(wù)流程設(shè)計(jì)表結(jié)構(gòu)。如：事件類表，可以適當(dāng)增加種類、狀態(tài)字段以便后續(xù)擴(kuò)展。

③ 元數(shù)據(jù)原則

• 列名應(yīng)遵循統(tǒng)一的數(shù)據(jù)標(biāo)準(zhǔn)，即同一類型字段應(yīng)對(duì)應(yīng)同一個(gè)元數(shù)據(jù)；字段類型和長(zhǎng)度應(yīng)相同，如同一產(chǎn)品線下所有表的機(jī)構(gòu)編號(hào)應(yīng)該對(duì)應(yīng)同一個(gè)元數(shù)據(jù)；
• 常用的字段應(yīng)建立應(yīng)用級(jí)的標(biāo)準(zhǔn)定義，指明元數(shù)據(jù)，確定字段命名。如所有表 的“最新維護(hù)時(shí)間”字段都統(tǒng)一命名為last_modify_time，這樣能夠確保我們后續(xù)在數(shù)據(jù)庫(kù)挖掘以及做知識(shí)圖譜時(shí)，可以將整個(gè)鏈路串起來(lái)。

2）典型規(guī)范示例

① 操作：方法論

方法論是萬(wàn)物之基石，例如每個(gè)表我們必須要建立一個(gè)主鍵，如果不顯示設(shè)置主鍵，會(huì)自動(dòng)生成一個(gè)rowid(6 byte)作為隱藏主鍵，且所有表共用此空間，造成性能下降。

② 量化：精細(xì)化的理性思維

我們建議掃描命中比原則上應(yīng)該是100:1，事物大小方面我們行的要求是10萬(wàn)，業(yè)界一般一萬(wàn)即可。

③ 避坑：規(guī)避 MySQL Bug

大表truncate改為drop + create table，這在5.7中效果非常明顯，但是在8.0中公司已經(jīng)對(duì)其進(jìn)行了修改優(yōu)化。

針對(duì)以上規(guī)范，我們要讓開發(fā)人員潛移默化地知其然也知其所以然，避免出現(xiàn)一些問題。

3、質(zhì)量門禁自動(dòng)化

我們基于druid，擴(kuò)展了Sonarqube插件，實(shí)現(xiàn)本地檢查規(guī)則和云端云同步。

我們之前大概定了27條規(guī)則，其中包含了常見的一些錯(cuò)誤，例如有人在update語(yǔ)句的set關(guān)鍵字后面，誤將分隔符逗號(hào)（“,”）寫成“and”，導(dǎo)致出現(xiàn)預(yù)期之外的結(jié)果。

4、大事務(wù)查殺

大事務(wù)的相關(guān)問題主要有以下幾點(diǎn)：

• binlog的寫入、傳輸、回放緩慢問題。之前我曾看到一個(gè)應(yīng)用，備庫(kù)24小時(shí)都未完成回放，萬(wàn)一主庫(kù)出問題，都沒辦法回切，只能等備庫(kù)處理完后再回切；
• 交易寫入堵塞；
• 在主庫(kù)故障博弈的情況下，到底切還是不切？

我們行以及業(yè)界都采用了自動(dòng)查殺方式。

• 在show engine innodb status中，我們可以進(jìn)行監(jiān)控，如果一個(gè)事物沒有結(jié)束，會(huì)提示這個(gè)事務(wù)更新的記錄數(shù)；
• 超過什么樣的閾值時(shí)，我們可以進(jìn)行自動(dòng)kill。對(duì)于聯(lián)機(jī)以及批量來(lái)說，閾值是不一樣的，所以我們自動(dòng)執(zhí)行kill時(shí)，必須規(guī)避一刀切的問題。

我們當(dāng)時(shí)做過兩步操作，第一步是將交易的聯(lián)機(jī)庫(kù)跟批量庫(kù)進(jìn)行區(qū)分。對(duì)于聯(lián)機(jī)庫(kù)，超過三秒以上的交易可以進(jìn)行自動(dòng)查殺；對(duì)于批量庫(kù)，通過小范圍試點(diǎn)，然后做到全面推廣。

后續(xù)我們應(yīng)該會(huì)將MySQL的主動(dòng)同步做到不降級(jí)，去掉降級(jí)時(shí)間，但這一點(diǎn)依賴于我們治理完善、大事務(wù)不存在的情況。

五、未來(lái)展望

1、全鏈路監(jiān)控

希望可以做到全套端到端的全鏈路監(jiān)控，這樣可以快速定位哪個(gè)節(jié)點(diǎn)出了什么問題。

2、進(jìn)一步發(fā)展AIOps

希望進(jìn)一步發(fā)展AIOps，實(shí)現(xiàn)業(yè)界所說的1-5-10目標(biāo)，1分鐘發(fā)現(xiàn)，5分鐘處置，10分鐘恢復(fù)。

3、掌握源碼

最后希望各位可以掌握一些開源組件的源碼，做到“他山之石，可以攻玉”，了解其中隱藏的bug風(fēng)險(xiǎn)，有利于我們后續(xù)對(duì)開源組件進(jìn)行維護(hù)。

Q&A

Q1：貴司在MySQL調(diào)優(yōu)過程中，會(huì)用到相關(guān)輔助工具嗎？老師能簡(jiǎn)單分享一下嗎？

A1：沒有用到輔助工具，我們更多還是通過explain直接查看執(zhí)行計(jì)劃，然后進(jìn)行一些分析。

Q2：MySQL規(guī)范已經(jīng)在貴司普及了嗎？落地一整套規(guī)范需要多長(zhǎng)時(shí)間？

A2：我們大概從17年開始建立MySQL規(guī)范，因?yàn)槲覀儺?dāng)時(shí)引入MySQL5.7時(shí)，必須建立方法論這套基石。我們建立規(guī)范后，在SonarQube上建立檢查組件，進(jìn)而做到門禁，實(shí)現(xiàn)規(guī)范的落地。在只有規(guī)范，沒有落地的情況下，我們很難把控，所以必須要通過硬性方式進(jìn)行把控。

Q3：貴司是采用什么方式對(duì)MySQL進(jìn)行監(jiān)控的？

A3：包括兩種層面，第一層面，我們?cè)贛yBatis上做了擴(kuò)展，會(huì)對(duì)語(yǔ)句進(jìn)行審核，判斷語(yǔ)句是否有問題。第二層面，對(duì)MySQL的performance schema 和Information schema相關(guān)表進(jìn)行監(jiān)控，查找并處理其中的慢SQL。

Q4：老師，自動(dòng)查殺的準(zhǔn)確率能達(dá)到多高？

A4：自動(dòng)查殺的準(zhǔn)確率其實(shí)可以達(dá)到100%。大事務(wù)很容易就可以監(jiān)控出來(lái)，但很多時(shí)候不敢查殺，我們把聯(lián)機(jī)跟批量分離完以后，對(duì)聯(lián)機(jī)大事務(wù)查殺的準(zhǔn)確率就相當(dāng)于是100%了。

Q5：老師能推薦個(gè)好用的開發(fā)工具嗎？比如Workbench？這塊總行有要求嗎？

A5：業(yè)界其實(shí)有很多工具，例如收費(fèi)的Navicat、免費(fèi)的MySQL Workbench等，我一般會(huì)用Workbench多一點(diǎn)，因?yàn)槲覀冃幸胲浖艿焦芸?，必須要進(jìn)行登記處理。

作者介紹

魏亞東大型銀行軟件開發(fā)中心三級(jí)經(jīng)理，資深架構(gòu)師，杭州研發(fā)部數(shù)據(jù)庫(kù)專家團(tuán)隊(duì)牽頭人和開發(fā)中心安全團(tuán)隊(duì)成員，負(fù)責(zé)技術(shù)管理、數(shù)據(jù)庫(kù)、安全相關(guān)工作；

2009年加入大型銀行軟件開發(fā)中心，致力于推動(dòng)管理創(chuàng)新、效能提升，提供全面技術(shù)管控，推動(dòng)自動(dòng)化實(shí)施，實(shí)現(xiàn)業(yè)務(wù)價(jià)值的高質(zhì)量快速交付；同時(shí)作為技術(shù)專家，為生產(chǎn)安全提供技術(shù)支持；負(fù)責(zé)過教培、預(yù)付費(fèi)等SaaS產(chǎn)品和數(shù)字生態(tài)基座（組裝式應(yīng)用程序Composable Applications）等。