一、準(zhǔn)備表數(shù)據(jù)

咱們建一張用戶表，表中的字段有用戶ID、用戶名、地址、記錄創(chuàng)建時(shí)間，如圖所示

OK，接下來準(zhǔn)備寫一個(gè)存儲(chǔ)過程插入一百萬條數(shù)據(jù)

CREATE TABLE `t_user` （

`id` int NOT NULL，

`user_name` varchar（32） CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL，

`address` varchar（255） DEFAULT NULL，

`create_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP，

PRIMARY KEY （`id`）

） ENGINE=InnoDB DEFAULT CHARSET=utf8;

DELIMITER ;;

CREATE PROCEDURE user_insert（）

BEGIN

DECLARE i INT DEFAULT 0;

WHILE i《1000000

DO

INSERT INTO t_user（id， user_name， address， create_time） VALUES （i， CONCAT（‘mayun’，i）， ‘浙江杭州’， now（））;

SET i=i+1;

END WHILE ;

commit;

END;;

CALL user_insert（）;

插入完后咱們看看數(shù)據(jù)條數(shù)

二、優(yōu)化方式

1.分頁查詢優(yōu)化

OK，咱們看下分頁limit到一定值時(shí)的耗時(shí)是多少

limit 1000時(shí)

limit 10000時(shí)

limit 100000時(shí)

limit 1000000時(shí)

可以看到limit值越大，耗時(shí)越長(zhǎng)，這還只是一百萬數(shù)據(jù)，要是千萬級(jí)、億級(jí)呢？

OK不廢話，咱們馬上進(jìn)行分頁優(yōu)化

子查詢優(yōu)化

-

可以看到比起之前 limit 1000000時(shí)的0.218s 效率提高了很多

使用JOIN分頁

-

可以看到比起之前 limit 1000000時(shí)的0.218s 效率也同樣提高了很多

使用前一次查詢的最大ID

可以看到這種方法效率最高，但依賴于需要知道最大ID，這種適合點(diǎn)擊下一頁查詢（類似于滾動(dòng)加載數(shù)據(jù)）的場(chǎng)景

通過偽列對(duì)ID進(jìn)行分頁

然后可以開啟多個(gè)線程去進(jìn)行最高效率查詢語句的批量查詢操作 0~10000，10001-20000.。.. 這樣子的話可以快速把全量數(shù)據(jù)查詢出來同步至緩存中。

分頁優(yōu)化總結(jié)： 使用前一次查詢的最大ID進(jìn)行查詢優(yōu)化是效率最高的方法，但這種方法只適用于下一頁點(diǎn)擊的這種操作，對(duì)于同步全量數(shù)據(jù)來說建議的方式使用偽列對(duì)ID進(jìn)行分頁，然后開啟多個(gè)線程同時(shí)查詢，把全量數(shù)據(jù)加載到緩存，以后面試官問你如何 快速獲取海量數(shù)據(jù)并加載到緩存 你該知道怎么回答了吧。

2.普通索引優(yōu)化

先來看沒索引優(yōu)化的情況下的查詢效率

可以看到這時(shí)沒用索引的情況，用了0.305S接下來看看加了索引后的結(jié)果

普通索引優(yōu)化

只需要0.024S，我們可以EXPLAIN看下

可以看到使用了普通索引后查詢效率明顯增加

3.復(fù)合索引優(yōu)化

復(fù)合索引什么時(shí)候用？為什么要用？圍繞著這兩問題，咱們先來說說復(fù)合索引什么時(shí)候用

單表中查詢、條件語句中具有較多個(gè)字段

使用索引會(huì)影響寫的效率，需要研究建立最優(yōu)秀的索引

我們這里建議一個(gè)復(fù)合索引

MySQL建立復(fù)合索引時(shí)實(shí)際建立了（user_name）、（user_name，address）、（user_name，address，create_time）三個(gè)索引，我們都知道每多一個(gè)索引，都會(huì)增加寫操作的開銷和磁盤空間的開銷，對(duì)于海量數(shù)據(jù)的表，這可是不小的開銷，所以你會(huì)發(fā)現(xiàn)我們?cè)谶@里使用復(fù)合索引一個(gè)頂三個(gè)，又能減少寫操作的開銷和磁盤空間的開銷。

當(dāng)我們select user_name，address，create_time from t_user where user_name=xx and address = xxx時(shí)，MySQL可以直接通過遍歷索引取得數(shù)據(jù)，無需回表，這減少了很多的隨機(jī)IO操作。所以，在真正的實(shí)際應(yīng)用中，這就是覆蓋索引，是復(fù)合索引中主要的提升性能的優(yōu)化手段之一。

4.SQL查詢優(yōu)化

避免使用OR，看看例子

可以看到這條語句沒有使用到索引，是因?yàn)楫?dāng)or左右查詢字段只有一個(gè)是索引，該索引失效，只有當(dāng)or左右查詢字段均為索引時(shí)，才會(huì)生效。

不要使用like ‘%xx’ %在左邊時(shí)索引失效

3. 使用復(fù)合索引時(shí)沒有遵循最左匹配原則

ref：這個(gè)連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊前綴）時(shí)發(fā)生。沒有值說明沒有利用最左前綴原則

再來看個(gè)使用了最左前綴的例子

4. 不要讓數(shù)據(jù)類型出現(xiàn)隱式轉(zhuǎn)化

可以看以下兩個(gè)例子

5. 不要在索引字段上使用not，《》，！=，一樣會(huì)導(dǎo)致索引失效

6. 分解關(guān)聯(lián)查詢 例如這條語句

可以分解成

7.小表驅(qū)動(dòng)大表 即小的數(shù)據(jù)集驅(qū)動(dòng)大的數(shù)據(jù)集。如：以t_user，t_order兩表為例，兩表通過 t_user的id字段進(jìn)行關(guān)聯(lián)。

當(dāng) t_order表的數(shù)據(jù)集小于t_user表時(shí)，用 in 優(yōu)化 exist，使用 in，兩表執(zhí)行順序是先查 t_order 表，再查t_user表

select * from t_user where id in （select user_id from t_order）

當(dāng) t_user 表的數(shù)據(jù)集小于 t_order 表時(shí)，用 exist 優(yōu)化 in，使用 exists，兩表執(zhí)行順序是先查 t_user 表，再查 t_order 表

select * from t_user where exists （select 1 from B where t_order.user_id= t_user.id）

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

首先了解下事務(wù)的隔離級(jí)別，數(shù)據(jù)庫共定義了四種隔離級(jí)別：

Serializable：可避免臟讀、不可重復(fù)讀、虛讀情況的發(fā)生。（串行化）

Repeatable read：可避免臟讀、不可重復(fù)讀情況的發(fā)生。（可重復(fù)讀）

Read committed：可避免臟讀情況發(fā)生（讀已提交）。

Read uncommitted：最低級(jí)別，以上情況均無法保證。（讀未提交）

可以通過 set transaction isolation level 設(shè)置事務(wù)隔離級(jí)別來提高性能

6.數(shù)據(jù)庫性能優(yōu)化

開啟查詢緩存

在解析一個(gè)查詢語句前，如果查詢緩存是打開的，那么MySQL會(huì)檢查這個(gè)查詢語句是否命中查詢緩存中的數(shù)據(jù)。如果當(dāng)前查詢恰好命中查詢緩存，在檢查一次用戶權(quán)限后直接返回緩存中的結(jié)果。這種情況下，查詢不會(huì)被解析，也不會(huì)生成執(zhí)行計(jì)劃，更不會(huì)執(zhí)行。MySQL將緩存存放在一個(gè)引用表（不要理解成table，可以認(rèn)為是類似于HashMap的數(shù)據(jù)結(jié)構(gòu)），通過一個(gè)哈希值索引，這個(gè)哈希值通過查詢本身、當(dāng)前要查詢的數(shù)據(jù)庫、客戶端協(xié)議版本號(hào)等一些可能影響結(jié)果的信息計(jì)算得來。所以兩個(gè)查詢?cè)谌魏巫址系牟煌ɡ纾嚎崭瘛⒆⑨專?，都?huì)導(dǎo)致緩存不會(huì)命中。

如果查詢中包含任何用戶自定義函數(shù)、存儲(chǔ)函數(shù)、用戶變量、臨時(shí)表、mysql庫中的系統(tǒng)表，其查詢結(jié)果都不會(huì)被緩存。比如函數(shù)NOW（）或者CURRENT_DATE（）會(huì)因?yàn)椴煌牟樵儠r(shí)間，返回不同的查詢結(jié)果，再比如包含CURRENT_USER或者CONNECION_ID（）的查詢語句會(huì)因?yàn)椴煌挠脩舳祷夭煌慕Y(jié)果，將這樣的查詢結(jié)果緩存起來沒有任何的意義。

既然是緩存，就會(huì)失效，那查詢緩存何時(shí)失效呢？MySQL的查詢緩存系統(tǒng)會(huì)跟蹤查詢中涉及的每個(gè)表，如果這些表（數(shù)據(jù)或結(jié)構(gòu)）發(fā)生變化，那么和這張表相關(guān)的所有緩存數(shù)據(jù)都將失效。正因?yàn)槿绱?，在任何的寫操作時(shí)，MySQL必須將對(duì)應(yīng)表的所有緩存都設(shè)置為失效。如果查詢緩存非常大或者碎片很多，這個(gè)操作就可能帶來很大的系統(tǒng)消耗，甚至導(dǎo)致系統(tǒng)僵死一會(huì)兒。而且查詢緩存對(duì)系統(tǒng)的額外消耗也不僅僅在寫操作，讀操作也不例外：

任何的查詢語句在開始之前都必須經(jīng)過檢查，即使這條SQL語句永遠(yuǎn)不會(huì)命中緩存

如果查詢結(jié)果可以被緩存，那么執(zhí)行完成后，會(huì)將結(jié)果存入緩存，也會(huì)帶來額外的系統(tǒng)消耗

基于此，我們要知道并不是什么情況下查詢緩存都會(huì)提高系統(tǒng)性能，緩存和失效都會(huì)帶來額外消耗，只有當(dāng)緩存帶來的資源節(jié)約大于其本身消耗的資源時(shí)，才會(huì)給系統(tǒng)帶來性能提升。但要如何評(píng)估打開緩存是否能夠帶來性能提升是一件非常困難的事情，也不在本文討論的范疇內(nèi)。如果系統(tǒng)確實(shí)存在一些性能問題，可以嘗試打開查詢緩存，并在數(shù)據(jù)庫設(shè)計(jì)上做一些優(yōu)化，比如：

批量插入代替循環(huán)單條插入 。 合理控制緩存空間大小，一般來說其大小設(shè)置為幾十兆比較合適 。 可以通過SQL\_CACHE和SQL\_NO\_CACHE來控制某個(gè)查詢語句是否需要進(jìn)行緩存 最后的忠告是不要輕易打開查詢緩存，特別是寫密集型應(yīng)用。如果你實(shí)在是忍不住，可以將query\_cache\_type設(shè)置為DEMAND，這時(shí)只有加入SQL\_CACHE的查詢才會(huì)走緩存，其他查詢則不會(huì)，這樣可以非常自由地控制哪些查詢需要被緩存。 當(dāng)然查詢緩存系統(tǒng)本身是非常復(fù)雜的，這里討論的也只是很小的一部分，其他更深入的話題，比如：緩存是如何使用內(nèi)存的？如何控制內(nèi)存的碎片化？事務(wù)對(duì)查詢緩存有何影響等等，讀者可以自行閱讀相關(guān)資料，這里權(quán)當(dāng)拋磚引玉吧。 **語法解析和預(yù)處理**

MySQL通過關(guān)鍵字將SQL語句進(jìn)行解析，并生成一顆對(duì)應(yīng)的解析樹。這個(gè)過程解析器主要通過語法規(guī)則來驗(yàn)證和解析。比如SQL中是否使用了錯(cuò)誤的關(guān)鍵字或者關(guān)鍵字的順序是否正確等等。預(yù)處理則會(huì)根據(jù)MySQL規(guī)則進(jìn)一步檢查解析樹是否合法。比如檢查要查詢的數(shù)據(jù)表和數(shù)據(jù)列是否存在等等。

7.系統(tǒng)內(nèi)核參數(shù)優(yōu)化

```bash

#基礎(chǔ)配置

datadir=/data/datafile

socket=/var/lib/mysql/mysql.sock

log-error=/data/log/mysqld.log

pid-file=/var/run/mysqld/mysqld.pid

character_set_server=utf8

#允許任意IP訪問

bind-address = 0.0.0.0

#是否支持符號(hào)鏈接，即數(shù)據(jù)庫或表可以存儲(chǔ)在my.cnf中指定datadir之外的分區(qū)或目錄，為0不開啟

#symbolic-links=0

#支持大小寫

lower_case_table_names=1

#二進(jìn)制配置

server-id = 1

log-bin = /data/log/mysql-bin.log

log-bin-index =/data/log/binlog.index

log_bin_trust_function_creators=1

expire_logs_days=7

#sql_mode定義了mysql應(yīng)該支持的sql語法，數(shù)據(jù)校驗(yàn)等

#mysql5.0以上版本支持三種sql_mode模式：ANSI、TRADITIONAL和STRICT_TRANS_TABLES。

#ANSI模式：寬松模式，對(duì)插入數(shù)據(jù)進(jìn)行校驗(yàn)，如果不符合定義類型或長(zhǎng)度，對(duì)數(shù)據(jù)類型調(diào)整或截?cái)啾４?，?bào)warning警告。

#TRADITIONAL模式：嚴(yán)格模式，當(dāng)向mysql數(shù)據(jù)庫插入數(shù)據(jù)時(shí)，進(jìn)行數(shù)據(jù)的嚴(yán)格校驗(yàn)，保證錯(cuò)誤數(shù)據(jù)不能插入，報(bào)error錯(cuò)誤。用于事物時(shí)，會(huì)進(jìn)行事物的回滾。

#STRICT_TRANS_TABLES模式：嚴(yán)格模式，進(jìn)行數(shù)據(jù)的嚴(yán)格校驗(yàn)，錯(cuò)誤數(shù)據(jù)不能插入，報(bào)error錯(cuò)誤。

sql_mode=STRICT_TRANS_TABLES，NO_ZERO_IN_DATE，NO_ZERO_DATE，ERROR_FOR_DIVISION_BY_ZERO，NO_AUTO_CREATE_USER，NO_ENGINE_SUBSTITUTION

#InnoDB存儲(chǔ)數(shù)據(jù)字典、內(nèi)部數(shù)據(jù)結(jié)構(gòu)的緩沖池，16MB已經(jīng)足夠大了。

innodb_additional_mem_pool_size = 16M

#InnoDB用于緩存數(shù)據(jù)、索引、鎖、插入緩沖、數(shù)據(jù)字典等

#如果是專用的DB服務(wù)器，且以InnoDB引擎為主的場(chǎng)景，通?？稍O(shè)置物理內(nèi)存的60%

#如果是非專用DB服務(wù)器，可以先嘗試設(shè)置成內(nèi)存的1/4

innodb_buffer_pool_size = 4G

#InnoDB的log buffer，通常設(shè)置為 64MB 就足夠了

innodb_log_buffer_size = 64M

#InnoDB redo log大小，通常設(shè)置256MB 就足夠了

innodb_log_file_size = 256M

#InnoDB redo log文件組，通常設(shè)置為 2 就足夠了

innodb_log_files_in_group = 2

#共享表空間：某一個(gè)數(shù)據(jù)庫的所有的表數(shù)據(jù)，索引文件全部放在一個(gè)文件中，默認(rèn)這個(gè)共享表空間的文件路徑在data目錄下。默認(rèn)的文件名為：ibdata1 初始化為10M。

#獨(dú)占表空間：每一個(gè)表都將會(huì)生成以獨(dú)立的文件方式來進(jìn)行存儲(chǔ)，每一個(gè)表都有一個(gè).frm表描述文件，還有一個(gè).ibd文件。其中這個(gè)文件包括了單獨(dú)一個(gè)表的數(shù)據(jù)內(nèi)容以及索引內(nèi)容，默認(rèn)情況下它的存儲(chǔ)位置也是在表的位置之中。

#設(shè)置參數(shù)為1啟用InnoDB的獨(dú)立表空間模式，便于管理

innodb_file_per_table = 1

#InnoDB共享表空間初始化大小，默認(rèn)是 10MB，改成 1GB，并且自動(dòng)擴(kuò)展

innodb_data_file_path = ibdata1autoextend

#設(shè)置臨時(shí)表空間最大4G

innodb_temp_data_file_path=ibtmp1autoextend4096M

#啟用InnoDB的status file，便于管理員查看以及監(jiān)控

innodb_status_file = 1

#當(dāng)設(shè)置為0，該模式速度最快，但不太安全，mysqld進(jìn)程的崩潰會(huì)導(dǎo)致上一秒鐘所有事務(wù)數(shù)據(jù)的丟失。

#當(dāng)設(shè)置為1，該模式是最安全的，但也是最慢的一種方式。在mysqld 服務(wù)崩潰或者服務(wù)器主機(jī)crash的情況下，binary log 只有可能丟失最多一個(gè)語句或者一個(gè)事務(wù)。

#當(dāng)設(shè)置為2，該模式速度較快，也比0安全，只有在操作系統(tǒng)崩潰或者系統(tǒng)斷電的情況下，上一秒鐘所有事務(wù)數(shù)據(jù)才可能丟失。

innodb_flush_log_at_trx_commit = 1

#設(shè)置事務(wù)隔離級(jí)別為 READ-COMMITED，提高事務(wù)效率，通常都滿足事務(wù)一致性要求

#transaction_isolation = READ-COMMITTED

#max_connections：針對(duì)所有的賬號(hào)所有的客戶端并行連接到MYSQL服務(wù)的最大并行連接數(shù)。簡(jiǎn)單說是指MYSQL服務(wù)能夠同時(shí)接受的最大并行連接數(shù)。

#max_user_connections ： 針對(duì)某一個(gè)賬號(hào)的所有客戶端并行連接到MYSQL服務(wù)的最大并行連接數(shù)。簡(jiǎn)單說是指同一個(gè)賬號(hào)能夠同時(shí)連接到mysql服務(wù)的最大連接數(shù)。設(shè)置為0表示不限制。

#max_connect_errors：針對(duì)某一個(gè)IP主機(jī)連接中斷與mysql服務(wù)連接的次數(shù)，如果超過這個(gè)值，這個(gè)IP主機(jī)將會(huì)阻止從這個(gè)IP主機(jī)發(fā)送出去的連接請(qǐng)求。遇到這種情況，需執(zhí)行flush hosts。

#執(zhí)行flush host或者 mysqladmin flush-hosts，其目的是為了清空host cache里的信息?？蛇m當(dāng)加大，防止頻繁連接錯(cuò)誤后，前端host被mysql拒絕掉

#在 show global 里有個(gè)系統(tǒng)狀態(tài)Max_used_connections，它是指從這次mysql服務(wù)啟動(dòng)到現(xiàn)在，同一時(shí)刻并行連接數(shù)的最大值。它不是指當(dāng)前的連接情況，而是一個(gè)比較值。如果在過去某一個(gè)時(shí)刻，MYSQL服務(wù)同時(shí)有10

00個(gè)請(qǐng)求連接過來，而之后再也沒有出現(xiàn)這么大的并發(fā)請(qǐng)求時(shí)，則Max_used_connections=1000.請(qǐng)注意與show variables 里的max_user_connections的區(qū)別。#Max_used_connections / max_connections * 100% ≈ 85%

max_connections=600

max_connect_errors=1000

max_user_connections=400

#設(shè)置臨時(shí)表最大值，這是每次連接都會(huì)分配，不宜設(shè)置過大 max_heap_table_size 和 tmp_table_size 要設(shè)置一樣大

max_heap_table_size = 100M

tmp_table_size = 100M

#每個(gè)連接都會(huì)分配的一些排序、連接等緩沖，一般設(shè)置為 2MB 就足夠了

sort_buffer_size = 2M

join_buffer_size = 2M

read_buffer_size = 2M

read_rnd_buffer_size = 2M

#建議關(guān)閉query cache，有些時(shí)候?qū)π阅芊炊且环N損害

query_cache_size = 0

#如果是以InnoDB引擎為主的DB，專用于MyISAM引擎的 key_buffer_size 可以設(shè)置較小，8MB 已足夠

#如果是以MyISAM引擎為主，可設(shè)置較大，但不能超過4G

key_buffer_size = 8M

#設(shè)置連接超時(shí)閥值，如果前端程序采用短連接，建議縮短這2個(gè)值，如果前端程序采用長(zhǎng)連接，可直接注釋掉這兩個(gè)選項(xiàng)，是用默認(rèn)配置（8小時(shí)）

#interactive_timeout = 120

#wait_timeout = 120

#InnoDB使用后臺(tái)線程處理數(shù)據(jù)頁上讀寫I/0請(qǐng)求的數(shù)量，允許值的范圍是1-64

#假設(shè)CPU是2顆4核的，且數(shù)據(jù)庫讀操作比寫操作多，可設(shè)置

#innodb_read_io_threads=5

#innodb_write_io_threads=3

#通過show engine innodb status的FILE I/O選項(xiàng)可查看到線程分配

#設(shè)置慢查詢閥值，單位為秒

long_query_time = 120

slow_query_log=1 #開啟mysql慢sql的日志

log_output=table，F(xiàn)ile #日志輸出會(huì)寫表，也會(huì)寫日志文件，為了便于程序去統(tǒng)計(jì)，所以最好寫表

slow_query_log_file=/data/log/slow.log

##針對(duì)log_queries_not_using_indexes開啟后，記錄慢sql的頻次、每分鐘記錄的條數(shù)

#log_throttle_queries_not_using_indexes = 5

##作為從庫時(shí)生效，從庫復(fù)制中如何有慢sql也將被記錄

#log_slow_slave_statements = 1

##檢查未使用到索引的sql

#log_queries_not_using_indexes = 1

#快速預(yù)熱緩沖池

innodb_buffer_pool_dump_at_shutdown=1

innodb_buffer_pool_load_at_startup=1

#打印deadlock日志

innodb_print_all_deadlocks=1

這些參數(shù)可按照自己的實(shí)際服務(wù)器以及數(shù)據(jù)庫的大小進(jìn)行適當(dāng)調(diào)整，主要起參考作用

8.表字段優(yōu)化

很多系統(tǒng)一開始并沒有考慮表字段拆分的問題，因?yàn)椴鸱謺?huì)帶來邏輯、部署、運(yùn)維的各種復(fù)雜度，一般以整型值為主的表在千萬級(jí)以下，字符串為主的表在五百萬以下，而事實(shí)上很多時(shí)候MySQL單表的性能依然有不少優(yōu)化空間，甚至能正常支撐千萬級(jí)以上的數(shù)據(jù)量：

下面直接看下如何去優(yōu)化字段

盡量使用TINYINT、SMALLINT、MEDIUM_INT作為整數(shù)類型而非INT，如果非負(fù)則加上UNSIGNED

單表不要有太多字段，建議在15以內(nèi)

盡量使用TIMESTAMP而非DATETIME

使用枚舉或整數(shù)代替字符串類型

VARCHAR的長(zhǎng)度只分配真正需要的空間

避免使用NULL字段，很難查詢優(yōu)化且占用額外索引空間

用整型來存IP

9.分布式場(chǎng)景下常用優(yōu)化手段

升級(jí)硬件

Scale up，這個(gè)不多說了，根據(jù)MySQL是CPU密集型還是I/O密集型，通過提升CPU和內(nèi)存、使用SSD，都能顯著提升MySQL性能

讀寫分離

也是目前常用的優(yōu)化，從庫讀主庫寫，一般不要采用雙主或多主引入很多復(fù)雜性，盡量采用文中的其他方案來提高性能。同時(shí)目前很多拆分的解決方案同時(shí)也兼顧考慮了讀寫分離

使用緩存

緩存可以發(fā)生在這些層次：

MySQL內(nèi)部：在系統(tǒng)內(nèi)核參數(shù)優(yōu)化介紹了相關(guān)設(shè)置

數(shù)據(jù)訪問層：比如MyBatis針對(duì)SQL語句做緩存，而Hibernate可以精確到單個(gè)記錄，這里緩存的對(duì)象主要是持久化對(duì)象Persistence Object

應(yīng)用服務(wù)層：這里可以通過編程手段對(duì)緩存做到更精準(zhǔn)的控制和更多的實(shí)現(xiàn)策略，這里緩存的對(duì)象是數(shù)據(jù)傳輸對(duì)象Data Transfer Object

Web層：針對(duì)web頁面做緩存

瀏覽器客戶端：用戶端的緩存

可以根據(jù)實(shí)際情況在一個(gè)層次或多個(gè)層次結(jié)合加入緩存。這里重點(diǎn)介紹下服務(wù)層的緩存實(shí)現(xiàn)，目前主要有兩種方式：

直寫式（Write Through）：在數(shù)據(jù)寫入數(shù)據(jù)庫后，同時(shí)更新緩存，維持?jǐn)?shù)據(jù)庫與緩存的一致性。這也是當(dāng)前大多數(shù)應(yīng)用緩存框架如Spring Cache的工作方式。這種實(shí)現(xiàn)非常簡(jiǎn)單，同步好，但效率一般。

回寫式（Write Back）：當(dāng)有數(shù)據(jù)要寫入數(shù)據(jù)庫時(shí)，只會(huì)更新緩存，然后異步批量的將緩存數(shù)據(jù)同步到數(shù)據(jù)庫上。這種實(shí)現(xiàn)比較復(fù)雜，需要較多的應(yīng)用邏輯，同時(shí)可能會(huì)產(chǎn)生數(shù)據(jù)庫與緩存的不同步，但效率非常高。

水平拆分。

總結(jié)

其實(shí)MySQL的優(yōu)化還有很多，有興趣的可以讀讀MySQL高性能優(yōu)化的書，但以上這些是在我們實(shí)際生產(chǎn)環(huán)境中比較常用的優(yōu)化手段，掌握這些，不是我吹，能吊打一般的面試官了。

原文標(biāo)題：MySQL 海量數(shù)據(jù)優(yōu)化（理論+實(shí)戰(zhàn)） 吊打面試官

文章出處：【微信公眾號(hào)：Linux愛好者】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq