image.png

面試官如果問你：你會(huì)從哪些維度進(jìn)行MySQL性能優(yōu)化？你會(huì)怎么回答捂贿？

所謂的性能優(yōu)化纠修，一般針對(duì)的是MySQL查詢的優(yōu)化。既然是優(yōu)化查詢厂僧，我們自然要先知道查詢操作要經(jīng)過哪些環(huán)節(jié)扣草，然后思考可以在哪些環(huán)節(jié)進(jìn)行優(yōu)化。

我之前寫過一條SQL查詢語句是如何執(zhí)行的颜屠？辰妙，感興趣的朋友可以閱讀一下，我用其中的一張圖展示查詢操作需要經(jīng)歷的基本環(huán)節(jié)甫窟。

image.png

下面從5個(gè)角度介紹一下MySQL優(yōu)化的一些策略密浑。

image.png

1. 連接配置優(yōu)化

處理連接是MySQL客戶端和MySQL服務(wù)端親熱的第一步，第一步都邁不好粗井，也就別談后來的故事了尔破。

既然連接是雙方的事情，我們自然從服務(wù)端和客戶端兩個(gè)方面來進(jìn)行優(yōu)化嘍浇衬。

1.1 服務(wù)端配置

服務(wù)端需要做的就是盡可能地多接受客戶端的連接懒构，或許你遇到過error 1040: Too many connections的錯(cuò)誤？就是服務(wù)端的胸懷不夠?qū)拸V導(dǎo)致的耘擂，格局太械ň纭！

我們可以從兩個(gè)方面解決連接數(shù)不夠的問題：

1. 增加可用連接數(shù)醉冤，修改環(huán)境變量max_connections赞赖，默認(rèn)情況下服務(wù)端的最大連接數(shù)為151個(gè)

mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.01 sec)
復(fù)制代碼

2. 及時(shí)釋放不活動(dòng)的連接滚朵，系統(tǒng)默認(rèn)的客戶端超時(shí)時(shí)間是28800秒（8小時(shí)），我們可以把這個(gè)值調(diào)小一點(diǎn)

mysql> show variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.01 sec)
復(fù)制代碼

MySQL有非常多的配置參數(shù)前域，并且大部分參數(shù)都提供了默認(rèn)值辕近，默認(rèn)值是MySQL作者經(jīng)過精心設(shè)計(jì)的，完全可以滿足大部分情況的需求匿垄，不建議在不清楚參數(shù)含義的情況下貿(mào)然修改移宅。

1.2 客戶端優(yōu)化

客戶端能做的就是盡量減少和服務(wù)端建立連接的次數(shù)，已經(jīng)建立的連接能湊合用就湊合用椿疗，別每次執(zhí)行個(gè)SQL語句都創(chuàng)建個(gè)新連接漏峰，服務(wù)端和客戶端的資源都吃不消啊。

解決的方案就是使用連接池來復(fù)用連接届榄。

常見的數(shù)據(jù)庫連接池有DBCP浅乔、C3P0、阿里的Druid铝条、Hikari靖苇，前兩者用得很少了，后兩者目前如日中天班缰。

但是需要注意的是連接池并不是越大越好贤壁，比如Druid的默認(rèn)最大連接池大小是8，Hikari默認(rèn)最大連接池大小是10埠忘，盲目地加大連接池的大小脾拆，系統(tǒng)執(zhí)行效率反而有可能降低。為什么莹妒？

對(duì)于每一個(gè)連接名船，服務(wù)端會(huì)創(chuàng)建一個(gè)單獨(dú)的線程去處理，連接數(shù)越多旨怠，服務(wù)端創(chuàng)建的線程自然也就越多渠驼。而線程數(shù)超過CPU個(gè)數(shù)的情況下，CPU勢(shì)必要通過分配時(shí)間片的方式進(jìn)行線程的上下文切換运吓，頻繁的上下文切換會(huì)造成很大的性能開銷。

Hikari官方給出了一個(gè)PostgreSQL數(shù)據(jù)庫連接池大小的建議值公式疯趟，CPU核心數(shù)*2+1拘哨。假設(shè)服務(wù)器的CPU核心數(shù)是4，把連接池設(shè)置成9就可以了信峻。這種公式在一定程度上對(duì)其他數(shù)據(jù)庫也是適用的倦青，大家面試的時(shí)候可以吹一吹。

2. 架構(gòu)優(yōu)化

2.1 使用緩存

系統(tǒng)中難免會(huì)出現(xiàn)一些比較慢的查詢盹舞，這些查詢要么是數(shù)據(jù)量大产镐，要么是查詢復(fù)雜（關(guān)聯(lián)的表多或者是計(jì)算復(fù)雜）隘庄，使得查詢會(huì)長(zhǎng)時(shí)間占用連接。

如果這種數(shù)據(jù)的實(shí)效性不是特別強(qiáng)（不是每時(shí)每刻都會(huì)變化癣亚，例如每日?qǐng)?bào)表）丑掺，我們可以把此類數(shù)據(jù)放入緩存系統(tǒng)中，在數(shù)據(jù)的緩存有效期內(nèi)述雾，直接從緩存系統(tǒng)中獲取數(shù)據(jù)街州，這樣就可以減輕數(shù)據(jù)庫的壓力并提升查詢效率。

image.png

2.2 讀寫分離（集群玻孟、主從復(fù)制）

項(xiàng)目的初期唆缴，數(shù)據(jù)庫通常都是運(yùn)行在一臺(tái)服務(wù)器上的，用戶的所有讀寫請(qǐng)求會(huì)直接作用到這臺(tái)數(shù)據(jù)庫服務(wù)器黍翎，單臺(tái)服務(wù)器承擔(dān)的并發(fā)量畢竟是有限的面徽。

針對(duì)這個(gè)問題，我們可以同時(shí)使用多臺(tái)數(shù)據(jù)庫服務(wù)器匣掸，將其中一臺(tái)設(shè)置為為小組長(zhǎng)趟紊，稱之為master節(jié)點(diǎn)，其余節(jié)點(diǎn)作為組員旺聚，叫做slave织阳。用戶寫數(shù)據(jù)只往master節(jié)點(diǎn)寫，而讀的請(qǐng)求分?jǐn)偟礁鱾€(gè)slave節(jié)點(diǎn)上砰粹。這個(gè)方案叫做讀寫分離唧躲。給組長(zhǎng)加上組員組成的小團(tuán)體起個(gè)名字，叫集群碱璃。

image.png

注：很多開發(fā)者不滿master-slave這種具有侵犯性的詞匯（因?yàn)樗麄冋J(rèn)為會(huì)聯(lián)想到種族歧視弄痹、黑人奴隸等），所以發(fā)起了一項(xiàng)更名運(yùn)動(dòng)嵌器。

受此影響MySQL也會(huì)逐漸停用master肛真、slave等術(shù)語，轉(zhuǎn)而用source和replica替代爽航，大家碰到的時(shí)候明白即可蚓让。

使用集群必然面臨一個(gè)問題，就是多個(gè)節(jié)點(diǎn)之間怎么保持?jǐn)?shù)據(jù)的一致性讥珍。畢竟寫請(qǐng)求只往master節(jié)點(diǎn)上發(fā)送了历极，只有master節(jié)點(diǎn)的數(shù)據(jù)是最新數(shù)據(jù)，怎么把對(duì)master節(jié)點(diǎn)的寫操作也同步到各個(gè)slave節(jié)點(diǎn)上呢衷佃？

主從復(fù)制技術(shù)來了趟卸！我在一條SQL更新語句是如何執(zhí)行的？中粗淺地介紹了一下binlog日志，我直接搬過來了锄列。

binlog是實(shí)現(xiàn)MySQL主從復(fù)制功能的核心組件图云。master節(jié)點(diǎn)會(huì)將所有的寫操作記錄到binlog中，slave節(jié)點(diǎn)會(huì)有專門的I/O線程讀取master節(jié)點(diǎn)的binlog邻邮，將寫操作同步到當(dāng)前所在的slave節(jié)點(diǎn)竣况。

image.png

這種集群的架構(gòu)對(duì)減輕主數(shù)據(jù)庫服務(wù)器的壓力有非常好的效果，但是隨著業(yè)務(wù)數(shù)據(jù)越來越多饶囚，如果某張表的數(shù)據(jù)量急劇增加帕翻，單表的查詢性能就會(huì)大幅下降，而這個(gè)問題是讀寫分離也無法解決的萝风，畢竟所有節(jié)點(diǎn)存放的是一模一樣的數(shù)據(jù)啊嘀掸，單表查詢性能差，說的自然也是所有節(jié)點(diǎn)性能都差规惰。

這時(shí)我們可以把單個(gè)節(jié)點(diǎn)的數(shù)據(jù)分散到多個(gè)節(jié)點(diǎn)上進(jìn)行存儲(chǔ)睬塌，這就是分庫分表。

2.3 分庫分表

分庫分表中的節(jié)點(diǎn)的含義比較寬泛歇万，要是把數(shù)據(jù)庫作為節(jié)點(diǎn)揩晴，那就是分庫；如果把單張表作為節(jié)點(diǎn)贪磺，那就是分表硫兰。

大家都知道分庫分表分成垂直分庫、垂直分表寒锚、水平分庫和水平分表劫映，但是每次都記不住這些概念，我就給大家詳細(xì)說一說刹前，幫助大家理解泳赋。

2.3.1 垂直分庫

image.png

在單體數(shù)據(jù)庫的基礎(chǔ)上垂直切幾刀，按照業(yè)務(wù)邏輯拆分成不同的數(shù)據(jù)庫喇喉，這就是垂直分庫啦祖今。

image.png

2.3.2 垂直分表

image.png

垂直分表就是在單表的基礎(chǔ)上垂直切一刀（或幾刀），將一個(gè)表的多個(gè)字短拆成若干個(gè)小表拣技，這種操作需要根據(jù)具體業(yè)務(wù)來進(jìn)行判斷千诬，通常會(huì)把經(jīng)常使用的字段（熱字段）分成一個(gè)表，不經(jīng)常使用或者不立即使用的字段（冷字段）分成一個(gè)表膏斤，提升查詢速度徐绑。

image.png

拿上圖舉例：通常情況下商品的詳情信息都比較<typo id="typo-2825" data-origin="長(zhǎng)" ignoretag="true">長(zhǎng)</typo>，而且查看商品列表時(shí)往往不需要立即展示商品詳情（一般都是點(diǎn)擊詳情按鈕才會(huì)進(jìn)行顯示）掸绞，而是會(huì)將商品更重要的信息（價(jià)格等）展示出來泵三，按照這個(gè)業(yè)務(wù)邏輯，我們將原來的商品表做了垂直分表衔掸。

2.3.3 水平分表

把單張表的數(shù)據(jù)按照一定的規(guī)則（行話叫分片規(guī)則）保存到多個(gè)數(shù)據(jù)表上烫幕，橫著給數(shù)據(jù)表來一刀（或幾刀），就是水平分表了敞映。

image.png

image.png

2.3.4 水平分庫

水平分庫就是對(duì)單個(gè)數(shù)據(jù)庫水平切一刀较曼，往往伴隨著水平分表。

image.png

image.png

2.3.5 總結(jié)

水平分振愿，主要是為了解決存儲(chǔ)的瓶頸捷犹；垂直分，主要是為了減輕并發(fā)壓力冕末。

2.4 消息隊(duì)列削峰

通常情況下萍歉，用戶的請(qǐng)求會(huì)直接訪問數(shù)據(jù)庫，如果同一時(shí)刻在線用戶數(shù)量非常龐大档桃，極有可能壓垮數(shù)據(jù)庫（參考明星出軌或公布戀情時(shí)微博的狀態(tài)）枪孩。

這種情況下可以通過使用消息隊(duì)列降低數(shù)據(jù)庫的壓力，不管同時(shí)有多少個(gè)用戶請(qǐng)求藻肄，先存入消息隊(duì)列蔑舞，然后系統(tǒng)有條不紊地從消息隊(duì)列中消費(fèi)請(qǐng)求。

image.png

3. 優(yōu)化器——SQL分析與優(yōu)化

處理完連接嘹屯、優(yōu)化完緩存等架構(gòu)的事情攻询，SQL查詢語句來到了解析器和優(yōu)化器的地盤了。在這一步如果出了任何問題州弟，那就只能是SQL語句的問題了钧栖。

只要你的語法不出問題，解析器就不會(huì)有問題呆馁。此外桐经，為了防止你寫的SQL運(yùn)行效率低，優(yōu)化器會(huì)自動(dòng)做一些優(yōu)化浙滤，但如果實(shí)在是太爛阴挣，優(yōu)化器也救不了你了，只能眼睜睜地看著你的SQL查詢淪為慢查詢纺腊。

3.1 慢查詢

慢查詢就是執(zhí)行地很慢<typo id="typo-3427" data-origin="的" ignoretag="true">的</typo>查詢（這句話說得跟廢話似的畔咧。。揖膜。）誓沸，只有知道MySQL中有哪些慢查詢我們才能針對(duì)性地進(jìn)行優(yōu)化。

因?yàn)殚_啟慢查詢?nèi)罩臼怯行阅艽鷥r(jià)的壹粟，因此MySQL默認(rèn)是關(guān)閉慢查詢?nèi)罩竟δ馨菟恚褂靡韵旅畈榭串?dāng)前慢查詢狀態(tài)

mysql> show variables like 'slow_query%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/9e74f9251f6c-slow.log |
+---------------------+--------------------------------------+
2 rows in set (0.00 sec)
復(fù)制代碼

slow_query_log表示當(dāng)前慢查詢?nèi)罩臼欠耖_啟宿百，slow_query_log_file表示慢查詢?nèi)罩镜谋４嫖恢谩?/p>

除了上面兩個(gè)變量，我們還需要確定“慢”的指標(biāo)是什么洪添，即執(zhí)行超過多長(zhǎng)時(shí)間才算是慢查詢垦页，默認(rèn)是10S，如果改成0的話就是記錄所有的SQL干奢。

mysql> show variables like '%long_query%';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
復(fù)制代碼

3.1.1 打開慢日志

有兩種打開慢日志的方式

1. 修改配置文件my.cnf

此種修改方式系統(tǒng)重啟后依然有效

# 是否開啟慢查詢?nèi)罩?slow_query_log=ON
# 
long_query_time=2
slow_query_log_file=/var/lib/mysql/slow.log
復(fù)制代碼

2. 動(dòng)態(tài)修改參數(shù)（重啟后失效）

mysql> set @@global.slow_query_log=1;
Query OK, 0 rows affected (0.06 sec)

mysql> set @@global.long_query_time=2;
Query OK, 0 rows affected (0.00 sec)
復(fù)制代碼

3.1.2 慢日志分析

MySQL不僅為我們保存了慢日志文件痊焊，還為我們提供了慢日志查詢的工具mysqldumpslow，為了演示這個(gè)工具忿峻，我們先構(gòu)造一條慢查詢：

mysql> SELECT sleep(5);
復(fù)制代碼

然后我們查詢用時(shí)最多的1條慢查詢：

[root@iZ2zejfuakcnnq2pgqyzowZ ~]# mysqldumpslow -s t -t 1 -g 'select' /var/lib/mysql/9e74f9251f6c-slow.log

Reading mysql slow query log from /var/lib/mysql/9e74f9251f6c-slow.log
Count: 1  Time=10.00s (10s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
  SELECT sleep(N)
復(fù)制代碼

其中薄啥，

• Count：表示這個(gè)SQL執(zhí)行的次數(shù)
• Time：表示執(zhí)行的時(shí)間，括號(hào)中的是累積時(shí)間
• Locks：表示鎖定的時(shí)間逛尚，括號(hào)中的是累積時(shí)間
• Rows：表示返回的記錄數(shù)垄惧，括號(hào)中的是累積數(shù)

更多關(guān)于mysqldumpslow的使用方式，可以查閱官方文檔绰寞，或者執(zhí)行mysqldumpslow --help尋求幫助赘艳。

3.2 查看運(yùn)行中的線程

我們可以運(yùn)行show full processlist查看MySQL中運(yùn)行的所有線程，查看其狀態(tài)和運(yùn)行時(shí)間克握，找到不順眼的蕾管，直接kill。

image.png

其中菩暗，

• Id：線程的唯一標(biāo)志掰曾，可以使用Id殺死指定線程
• User：?jiǎn)?dòng)這個(gè)線程的用戶，普通賬戶只能查看自己的線程
• Host：哪個(gè)ip和端口發(fā)起的連接
• db：線程操作的數(shù)據(jù)庫
• Command：線程的命令
• Time：操作持續(xù)時(shí)間停团，單位秒
• State：線程的狀態(tài)
• Info：SQL語句的前100個(gè)字符

3.3 查看服務(wù)器運(yùn)行狀態(tài)

使用SHOW STATUS查看MySQL服務(wù)器的運(yùn)行狀態(tài)旷坦，有session和global兩種作用域，一般使用like+通配符進(jìn)行過濾佑稠。

-- 查看select的次數(shù)
mysql> SHOW GLOBAL STATUS LIKE 'com_select';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Com_select    | 168241 |
+---------------+--------+
1 row in set (0.05 sec)
復(fù)制代碼

3.4 查看存儲(chǔ)引擎運(yùn)行信息

SHOW ENGINE用來展示存儲(chǔ)引擎的當(dāng)前運(yùn)行信息秒梅，包括事務(wù)持有的表鎖、行鎖信息舌胶；事務(wù)的鎖等待情況捆蜀；線程信號(hào)量等待；文件IO請(qǐng)求幔嫂；Buffer pool統(tǒng)計(jì)信息等等數(shù)據(jù)辆它。

例如：

SHOW ENGINE INNODB STATUS;
復(fù)制代碼

上面這條語句可以展示innodb存儲(chǔ)引擎的當(dāng)前運(yùn)行的各種信息，大家可以據(jù)此找到MySQL當(dāng)前的問題履恩，限于篇幅不在此意義說明其中信息的含義锰茉，大家只要知道MySQL提供了這樣一個(gè)監(jiān)控工具就行了，等到需要的時(shí)候再來用就好切心。

3.5 EXPLAIN執(zhí)行計(jì)劃

通過慢查詢?nèi)罩疚覀兛梢灾滥男㏒QL語句執(zhí)行慢了飒筑，可是為什么慢片吊？慢在哪里呢？

MySQL提供了一個(gè)執(zhí)行計(jì)劃的查詢命令EXPLAIN协屡，通過此命令我們可以查看SQL執(zhí)行的計(jì)劃定鸟，所謂執(zhí)行計(jì)劃就是：優(yōu)化器會(huì)不會(huì)優(yōu)化我們自己書寫的SQL語句（比如外連接改內(nèi)連接查詢，子查詢優(yōu)化為連接查詢...）著瓶、優(yōu)化器針對(duì)此條SQL的執(zhí)行對(duì)哪些索引進(jìn)行了成本估算也祠，并最終決定采用哪個(gè)索引（或者最終選擇不用索引睦擂，而是全表掃描）灾搏、優(yōu)化器對(duì)單表執(zhí)行的策略是什么敢订，等等等等痰催。

EXPLAIN在MySQL5.6.3之后也可以針對(duì)UPDATE秋茫、DELETE和INSERT語句進(jìn)行分析胡诗，但是通常情況下我們還是用在SELECT查詢上燕锥。

這篇文章主要是從宏觀上多個(gè)角度介紹MySQL的優(yōu)化策略子刮，因此這里不詳細(xì)說明EXPLAIN的細(xì)節(jié)威酒，之后單獨(dú)成篇。

3.6 SQL與索引優(yōu)化

3.6.1 SQL優(yōu)化

SQL優(yōu)化指的是SQL本身語法沒有問題挺峡，但是有實(shí)現(xiàn)相同目的的更好的寫法葵孤。比如：

• 使用小表驅(qū)動(dòng)大表；用join改寫子查詢橱赠；or改成union
• 連接查詢中尤仍，盡量減少驅(qū)動(dòng)表的扇出（記錄數(shù)），訪問被驅(qū)動(dòng)表的成本要盡量低狭姨，盡量在被驅(qū)動(dòng)表的連接列上建立索引宰啦，降低訪問成本；被驅(qū)動(dòng)表的連接列最好是該表的主鍵或者是唯一二級(jí)索引列饼拍，這樣被驅(qū)動(dòng)表的成本會(huì)降到更低
• 大偏移量的limit赡模，先過濾再排序

針對(duì)最后一條舉個(gè)簡(jiǎn)單的例子，下面兩條語句能實(shí)現(xiàn)同樣的目的师抄，但是第二條的執(zhí)行效率比第一條執(zhí)行效率要高得多（存儲(chǔ)引擎使用的是InnoDB）漓柑，大家感受一下：

-- 1\. 大偏移量的查詢
mysql> SELECT * FROM user_innodb LIMIT 9000000,10;
Empty set (8.18 sec)

-- 2.先過濾ID（因?yàn)镮D使用的是索引），再limit
mysql> SELECT * FROM user_innodb WHERE id > 9000000 LIMIT 10;
Empty set (0.02 sec)
復(fù)制代碼

3.6.2 索引優(yōu)化

為慢查詢創(chuàng)建適當(dāng)?shù)乃饕莻€(gè)非常常見并且非常有效的方法叨吮，但是索引是否會(huì)被高效使用又是另一門學(xué)問了欺缘。

我之前寫過一篇用好MySQL索引，你必須知道的一些事情 挤安，感興趣的讀者可以看一下谚殊。

4. 存儲(chǔ)引擎與表結(jié)構(gòu)

4.1 選擇存儲(chǔ)引擎

一般情況下，我們會(huì)選擇MySQL默認(rèn)的存儲(chǔ)引擎存儲(chǔ)引擎InnoDB蛤铜，但是當(dāng)對(duì)數(shù)據(jù)庫性能要求精益求精的時(shí)候嫩絮，存儲(chǔ)引擎的選擇也成為一個(gè)關(guān)鍵的影響因素丛肢。

建議根據(jù)不同的業(yè)務(wù)選擇不同的存儲(chǔ)引擎，例如：

• 查詢操作剿干、插入操作多的業(yè)務(wù)表蜂怎，推薦使用MyISAM；
• 臨時(shí)表使用Memory置尔；
• 并發(fā)數(shù)量大杠步、更新多的業(yè)務(wù)選擇使用InnoDB；
• 不知道選啥直接默認(rèn)榜轿。

4.2 優(yōu)化字段

字段優(yōu)化的最終原則是：使用可以正確存儲(chǔ)數(shù)據(jù)的最小的數(shù)據(jù)類型幽歼。

4.2.1 整數(shù)類型

MySQL提供了6種整數(shù)類型，分別是

• tinyint
• smallint
• mediumint
• int
• integer
• bigint

不同的存儲(chǔ)類型的最大存儲(chǔ)范圍不同谬盐，占用的存儲(chǔ)的空間自然也不同甸私。

例如，是否被刪除的標(biāo)識(shí)飞傀，建議選用tinyint皇型，而不是bigint。

4.2.2 字符類型

你是不是直接把所有字符串的字段都設(shè)置為varchar格式了砸烦？甚至怕不夠弃鸦，還會(huì)直接設(shè)置成varchar(1024)的長(zhǎng)度？

如果不確定字段的長(zhǎng)度幢痘，肯定是要選擇varchar寡键，但是varchar需要額外的空間來記錄該字段目前占用的長(zhǎng)度；因此如果字段的長(zhǎng)度是固定的雪隧，盡量選用char西轩，這會(huì)給你節(jié)約不少的內(nèi)存空間。

4.2.3 非空

非空字段盡量設(shè)置成NOT NULL脑沿，并提供默認(rèn)值藕畔，或者使用特殊值代替NULL。

因?yàn)镹ULL類型的存儲(chǔ)和優(yōu)化都會(huì)存在性能不佳的問題庄拇，具體原因在這里就不展開了注服。

4.2.4 不要用外鍵、觸發(fā)器和視圖功能

這也是「阿里巴巴開發(fā)手冊(cè)」中提到的原則措近。原因有三個(gè)：

1. 降低了可讀性溶弟，檢查代碼的同時(shí)還得查看數(shù)據(jù)庫的代碼；
2. 把計(jì)算的工作交給程序瞭郑，數(shù)據(jù)庫只做好存儲(chǔ)的工作辜御，并把這件事情做好；
3. 數(shù)據(jù)的完整性校驗(yàn)的工作應(yīng)該由開發(fā)者完成屈张，而不是依賴于外鍵擒权，一旦用了外鍵袱巨，你會(huì)發(fā)現(xiàn)測(cè)試的時(shí)候隨便刪點(diǎn)垃圾數(shù)據(jù)都變得異常艱難。

4.2.5 圖片碳抄、音頻愉老、視頻存儲(chǔ)

不要直接存儲(chǔ)大文件，而是要存儲(chǔ)大文件的訪問地址剖效。

4.2.6 大字段拆分和數(shù)據(jù)冗余

大字段拆分其實(shí)就是前面說過的垂直分表嫉入，把不常用的字段或者數(shù)據(jù)量較大的字段拆分出去，避免列數(shù)過多和數(shù)據(jù)量過大璧尸，尤其是習(xí)慣編寫SELECT * 的情況下咒林，列數(shù)多和數(shù)據(jù)量大導(dǎo)致的問題會(huì)被嚴(yán)重放大！

字段冗余原則上不符合數(shù)據(jù)庫設(shè)計(jì)范式逗宁，但是卻非常有利于快速檢索。比如梦湘，合同表中存儲(chǔ)客戶id的同時(shí)可以冗余存儲(chǔ)客戶姓名瞎颗，這樣查詢時(shí)就不需要再根據(jù)客戶id獲取用戶姓名了。因此針對(duì)業(yè)務(wù)邏輯適當(dāng)做一定程度的冗余也是一種比較好的優(yōu)化技巧捌议。

5. 業(yè)務(wù)優(yōu)化

嚴(yán)格來說哼拔，業(yè)務(wù)方面的優(yōu)化已經(jīng)不算是MySQL調(diào)優(yōu)的手段了，但是業(yè)務(wù)的優(yōu)化卻能非常有效地減輕數(shù)據(jù)庫訪問壓力瓣颅，這方面一個(gè)典型例子就是淘寶倦逐，下面舉幾個(gè)簡(jiǎn)單例子給大家提供一下思路：

1. 以往都是雙11當(dāng)晚開始買買買的模式，最近幾年雙11的預(yù)售戰(zhàn)線越拉越長(zhǎng)宫补，提前半個(gè)多月就開始了檬姥，而且各種定金紅包模式叢出不窮，這種方式叫做預(yù)售分流粉怕。這樣做可以分流客戶的服務(wù)請(qǐng)求健民，不必等到雙十一的凌晨一股腦地集體下單；
2. 雙十一的凌晨你或許想查詢當(dāng)天之外的訂單贫贝，但是卻查詢失敱獭；甚至支付寶里的小雞的口糧都被延遲發(fā)放了稚晚，這是一種降級(jí)策略崇堵，集結(jié)不重要的服務(wù)的計(jì)算資源，用來保證當(dāng)前最核心的業(yè)務(wù)客燕；
3. 雙十一的時(shí)候支付寶極力推薦使用花唄支付鸳劳，而不是銀行卡支付，雖然一部分考量是提高軟件粘性也搓，但是另一方面棍辕，使用余額寶實(shí)際使用的阿里內(nèi)部服務(wù)器暮现，訪問速度快，而使用銀行卡楚昭，需要調(diào)用銀行接口栖袋，相比之下操作要慢了許多。

MySQL優(yōu)化的總結(jié)寫到此就結(jié)束了抚太，其中有不少細(xì)節(jié)沒有提及塘幅，多少讓我感覺這篇文章不完美。但是有些知識(shí)點(diǎn)掰開講又太多了尿贫，不可能一下子全部寫下电媳，之后再好好寫吧。

我是蟬沐風(fēng)庆亡，公眾號(hào)「蟬沐風(fēng)」匾乓，一個(gè)認(rèn)真寫文章的技術(shù)人，下期見

原文：https://juejin.cn/post/7083269706232102925