如果有同學(xué)看完上一篇關(guān)于 MySQL 文章，文末留有兩個(gè)很開放的問題，如有興趣可以在腦袋里想想。本文也會(huì)試著回答這兩個(gè)問題，希望能給你一些參考?，F(xiàn)在可以思考一個(gè)問題，如果數(shù)據(jù)量非常大的情況下，您根據(jù)業(yè)務(wù)選擇了合適的字段，精心設(shè)計(jì)了表和索引，還仔細(xì)的檢查了所有的 SQL，并確認(rèn)已經(jīng)沒什么問題，但性能仍然不能滿足您的要求，該怎么辦呢？還有其他優(yōu)化策略嗎？答案是肯定的。接下來繼續(xù)和您討論一些常用的 MySQL 高級(jí)特性以及其背后的工作原理。

分區(qū)表

合理的使用索引可以極大提升 MySQL 的查詢性能，但如果單表數(shù)據(jù)量達(dá)到一定的程度，索引就無法起作用，因?yàn)樵跀?shù)據(jù)量超大的情況下，除非覆蓋索引，因回表查詢會(huì)產(chǎn)生大量的隨機(jī) I/O，數(shù)據(jù)庫的響應(yīng)時(shí)間可能會(huì)達(dá)到不可接受的程度。而且索引維護(hù)（磁盤空間、I/O 操作）的代價(jià)也會(huì)非常大。

因此，當(dāng)單表數(shù)據(jù)量達(dá)到一定程度時(shí)（在 MySQL4.x 時(shí)代，MyISAM 存儲(chǔ)引擎業(yè)內(nèi)公認(rèn)的性能拐點(diǎn)是 500W 行，MySQL5.x 時(shí)代的性能拐點(diǎn)則為 1KW ~ 2KW 行級(jí)別，具體需根據(jù)實(shí)際情況測試），為了提升性能，最為常用的方法就是分表。分表的策略可以是垂直拆分（比如：不同訂單狀態(tài)的訂單拆分到不同的表），也可以是水平拆分（比如：按月將訂單拆分到不同表）。但總的來說，分表可以看作是從業(yè)務(wù)角度來解決大數(shù)據(jù)量問題，它在一定程度上可以提升性能，但也大大提升了編碼的復(fù)雜度，有過這種經(jīng)歷的同學(xué)可能深有體會(huì)。

在業(yè)務(wù)層分表大大增加了編碼的復(fù)雜程度，而且處理數(shù)據(jù)庫的相關(guān)代碼會(huì)大量散落在應(yīng)用各處，維護(hù)困難。那是否可以將分表的邏輯抽象出來，統(tǒng)一處理，這樣業(yè)務(wù)層就不用關(guān)心底層是否分表，只需要專注在業(yè)務(wù)即可。答案當(dāng)然是肯定的，目前有非常多的數(shù)據(jù)庫中間件都可以屏蔽分表后的細(xì)節(jié)，讓業(yè)務(wù)層像查詢單表一樣查詢分表后的數(shù)據(jù)。如果再將抽象的邏輯下移到數(shù)據(jù)庫的服務(wù)層，就是我們今天要講的分區(qū)表。

分區(qū)可以看作是從技術(shù)層面解決大數(shù)據(jù)問題的有效方法，簡單的理解，可以認(rèn)為是 MySQL 底層幫我們實(shí)現(xiàn)分表，分區(qū)表是一個(gè)獨(dú)立的邏輯表，底層由多個(gè)物理子表組成。存儲(chǔ)引擎管理分區(qū)的各個(gè)底層表和管理普通表一樣（所有底層表必須使用相同的存儲(chǔ)引擎），分區(qū)表的索引也是在各個(gè)底層表上各自加上一個(gè)完全相同的索引。從存儲(chǔ)引擎的角度來看，底層表和普通表沒有任何不同，存儲(chǔ)引擎也無須知道。在執(zhí)行查詢時(shí)，優(yōu)化器會(huì)根據(jù)分區(qū)的定義過濾那些沒有我們需要數(shù)據(jù)的分區(qū)，這樣查詢就無需掃描所有分區(qū)，只需要查找包含需要數(shù)據(jù)的分區(qū)就可以了。

更好的理解分區(qū)表，我們從一個(gè)示例入手：一張訂單表，數(shù)據(jù)量大概有 10TB，如何設(shè)計(jì)才能使性能達(dá)到最優(yōu)？

首先可以肯定的是，因?yàn)閿?shù)據(jù)量巨大，肯定不能走全表掃描。使用索引的話，你會(huì)發(fā)現(xiàn)數(shù)據(jù)并不是按照想要的方式聚集，而且會(huì)產(chǎn)生大量的碎片，最終會(huì)導(dǎo)致一個(gè)查詢產(chǎn)生成千上萬的隨機(jī) I/O，應(yīng)用隨之僵死。所以需要選擇一些更粗粒度并且消耗更少的方式來檢索數(shù)據(jù)。比如先根據(jù)索引找到一大塊數(shù)據(jù)，然后再在這塊數(shù)據(jù)上順序掃描。

這正是分區(qū)要做的事情，理解分區(qū)時(shí)還可以將其當(dāng)作索引的最初形態(tài)，以代價(jià)非常小的方式定位到需要的數(shù)據(jù)在哪一片 “區(qū)域”，在這片 “區(qū)域” 中，你可以順序掃描，可以建索引，還可以將數(shù)據(jù)都緩存在內(nèi)存中。因?yàn)榉謪^(qū)無須額外的數(shù)據(jù)結(jié)構(gòu)記錄每個(gè)分區(qū)有哪些數(shù)據(jù)，所以其代價(jià)非常低。只需要一個(gè)簡單的表達(dá)式就可以表達(dá)每個(gè)分區(qū)存放的是什么數(shù)據(jù)。

對(duì)表分區(qū)，可以在創(chuàng)建表時(shí)，使用如下語句：

CREATE TABLE sales {order_date DATETIME NOT NULL-- other columns } ENGINE=InnoDB PARTITION BY RANGE(YEAR(order_date)) (PARTITION p_2014 VALUES LESS THAN (2014),PARTITION p_2015 VALUES LESS THAN (2015)PARTITION p_2016 VALUES LESS THAN (2016)PARTITION p_2017 VALUES LESS THAN (2017)PARTITION p_catchall VALUES LESS THAN MAXVALUE )

分區(qū)子句中可以使用各種函數(shù)，但表達(dá)式的返回值必須是一個(gè)確定的整數(shù)，且不能是一個(gè)常數(shù)。MySQL 還支持一些其他分區(qū)，比如鍵值、哈希、列表分區(qū)，但在生產(chǎn)環(huán)境中很少見到。在 MySQL5.5 以后可以使用 RANGE COLUMNS 類型分區(qū)，這樣即使是基于時(shí)間分區(qū)，也無需再將其轉(zhuǎn)化成一個(gè)整數(shù)。

接下來簡單看下分區(qū)表上的各種操作邏輯：

• SELECT：當(dāng)查詢一個(gè)分區(qū)表時(shí)，分區(qū)層先打開并鎖住所有的底層表，優(yōu)化器先判斷是否可以過濾部分分區(qū)，然后在調(diào)用對(duì)應(yīng)的存儲(chǔ)引擎接口訪問各個(gè)分區(qū)的數(shù)據(jù)
• INSERT：當(dāng)插入一條記錄時(shí)，分區(qū)層先打開并鎖住所有的底層表，然后確定哪個(gè)分區(qū)接收這條記錄，再將記錄寫入對(duì)應(yīng)的底層表，DELETE操作與其類似
• UPDATE：當(dāng)更新一條數(shù)據(jù)時(shí)，分區(qū)層先打開并鎖住所有的底層表，然后確定數(shù)據(jù)對(duì)應(yīng)的分區(qū)，然后取出數(shù)據(jù)并更新，再判斷更新后的數(shù)據(jù)應(yīng)該存放到哪個(gè)分區(qū)，最后對(duì)底層表進(jìn)行寫入操作，并對(duì)原數(shù)據(jù)所在的底層表進(jìn)行刪除操作

有些操作是支持條件過濾的。例如，當(dāng)刪除一條記錄時(shí)，MySQL 需要先找到這條記錄，如果WHERE條件恰好和分區(qū)表達(dá)式匹配，就可以將所有不包含這條記錄的分區(qū)都過濾掉，這對(duì)UPDATE語句同樣有效。如果是INSERT操作，本身就只命中一個(gè)分區(qū)，其他分區(qū)都會(huì)被過濾。

雖然每個(gè)操作都會(huì) “先打開并鎖住所有的底層表”，但這并不是說分區(qū)表在處理過程中是鎖住全表的。如果存儲(chǔ)引擎能夠自己實(shí)現(xiàn)行級(jí)鎖，例如 InnoDB，則會(huì)在分區(qū)層釋放對(duì)應(yīng)表鎖。這個(gè)加鎖和解鎖的操作過程與普通 InnoDB 上的查詢類似。

在使用分區(qū)表時(shí)，為了保證大數(shù)據(jù)量的可擴(kuò)展性，一般有兩個(gè)策略：

• 全量掃描數(shù)據(jù)，不用索引。即只要能夠根據(jù) WHERE 條件將需要查詢的數(shù)據(jù)限制在少數(shù)分區(qū)中，效率是不錯(cuò)的
• 索引數(shù)據(jù)，分離熱點(diǎn)。如果數(shù)據(jù)有明顯的 “熱點(diǎn)”，而且除了這部分?jǐn)?shù)據(jù)，其他數(shù)據(jù)很少被訪問到，那么可以將這部分熱點(diǎn)數(shù)據(jù)單獨(dú)存放在一個(gè)分區(qū)中，讓這個(gè)分區(qū)的數(shù)據(jù)能夠有機(jī)會(huì)都緩存在內(nèi)存中。這樣查詢就可以只訪問一個(gè)很小的分區(qū)表，能夠使用索引，也能夠有效的利用緩存。

分區(qū)表的優(yōu)點(diǎn)是優(yōu)化器可以根據(jù)分區(qū)函數(shù)來過濾一些分區(qū)，但很重要的一點(diǎn)是要在WHERE條件中帶入分區(qū)列，有時(shí)候即使看似多余的也要帶上，這樣就可以讓優(yōu)化器能夠過濾掉無須訪問的分區(qū)，如果沒有這些條件，MySQL 就需要讓對(duì)應(yīng)的存儲(chǔ)引擎訪問這個(gè)表的所有分區(qū)，如果表非常大的話，就可能會(huì)非常慢。

上面兩個(gè)分區(qū)策略基于兩個(gè)非常重要的前提：查詢都能夠過濾掉很多額外的分區(qū)，分區(qū)本身并不會(huì)帶來很多額外的代價(jià)。而這兩個(gè)前提在某些場景下是有問題的，比如：

1、NULL 值會(huì)使分區(qū)過濾無效

假設(shè)按照PARTITION BY RANGE YEAR(order_date)分區(qū)，那么所有order_date為 NULL 或者非法值時(shí)，記錄都會(huì)被存放到第一個(gè)分區(qū)。所以WHERE order_date BETWEEN '2017-05-01' AND ‘2017-05-31’，這個(gè)查詢會(huì)檢查兩個(gè)分區(qū)，而不是我們認(rèn)為的 2017 年這個(gè)分區(qū)（會(huì)額外的檢查第一個(gè)分區(qū)），是因?yàn)閅EAR()在接收非法值時(shí)會(huì)返回 NULL。如果第一個(gè)分區(qū)的數(shù)據(jù)量非常大，而且使用全表掃描的策略時(shí)，代價(jià)會(huì)非常大。為了解決這個(gè)問題，我們可以創(chuàng)建一個(gè)無用的分區(qū)，比如：PARTITION p_null values less than (0)。如果插入的數(shù)據(jù)都是有效的話，第一個(gè)分區(qū)就是空的。

在 MySQL5.5 以后就不需要這個(gè)技巧了，因?yàn)榭梢灾苯邮褂昧斜旧矶皇腔诹械暮瘮?shù)進(jìn)行分區(qū)：PARTITION BY RANGE COLUMNS(order_date)。直接使用這個(gè)語法可避免這個(gè)問題。

2、分區(qū)列和索引列不匹配

當(dāng)分區(qū)列和索引列不匹配時(shí)，可能會(huì)導(dǎo)致查詢無法進(jìn)行分區(qū)過濾，除非每個(gè)查詢條件中都包含分區(qū)列。假設(shè)在列 a 上定義了索引，而在列 b 上進(jìn)行分區(qū)。因?yàn)槊總€(gè)分區(qū)都有其獨(dú)立的索引，所以在掃描列 b 上的索引就需要掃描每一個(gè)分區(qū)內(nèi)對(duì)應(yīng)的索引，當(dāng)然這種速度不會(huì)太慢，但是能夠跳過不匹配的分區(qū)肯定會(huì)更好。這個(gè)問題看起來很容易避免，但需要注意一種情況就是，關(guān)聯(lián)查詢。如果分區(qū)表是關(guān)聯(lián)順序的第 2 張表，并且關(guān)聯(lián)使用的索引與分區(qū)條件并不匹配，那么關(guān)聯(lián)時(shí)對(duì)第一張表中符合條件的每一行都需要訪問并搜索第二張表的所有分區(qū)（關(guān)聯(lián)查詢?cè)?#xff0c;請(qǐng)參考前一篇文章）

3、選擇分區(qū)的成本可能很高

分區(qū)有很多種類型，不同類型的分區(qū)實(shí)現(xiàn)方式也不同，所以它們的性能也不盡相同，尤其是范圍分區(qū)，在確認(rèn)這一行屬于哪個(gè)分區(qū)時(shí)會(huì)掃描所有的分區(qū)定義，這樣的線性掃描效率并不高，所以隨著分區(qū)數(shù)的增長，成本會(huì)越來越高。特別是在批量插入數(shù)據(jù)時(shí)，由于每條記錄在插入前，都需要確認(rèn)其屬于哪一個(gè)分區(qū)，如果分區(qū)數(shù)太大，會(huì)造成插入性能的急劇下降。因此有必要限制分區(qū)數(shù)量，但也不用太過擔(dān)心，對(duì)于大多數(shù)系統(tǒng)，100 個(gè)左右的分區(qū)是沒有問題的。

4、打開并鎖住所有底層表的成本在某些時(shí)候會(huì)很高

前面說過，打開并鎖住所有底層表并不會(huì)對(duì)性能有太大的影響，但在某些情況下，比如只需要查詢主鍵，那么鎖住的成本相對(duì)于主鍵的查詢來說，成本就略高。

5、維護(hù)分區(qū)的成本可能會(huì)很高

新增和刪除分區(qū)的速度都很快，但是修改分區(qū)會(huì)造成數(shù)據(jù)的復(fù)制，這與ALTER TABLE的原理類似，需要先創(chuàng)建一個(gè)歷史分區(qū)，然后將數(shù)據(jù)復(fù)制到其中，最后刪除原分區(qū)。因此，設(shè)計(jì)數(shù)據(jù)庫時(shí)，考慮業(yè)務(wù)的增長需要，合理的創(chuàng)建分區(qū)表是一個(gè)非常好的習(xí)慣。在 MySQL5.6 以后的版本可以使用ALTER TABLE EXCHAGE PARTITION語句來修改分區(qū)，其性能會(huì)有很大提升。

分區(qū)表還有一些其他限制，比如所有的底層表必須使用相同的存儲(chǔ)引擎，某些存儲(chǔ)引擎也不支持分區(qū)。分區(qū)一般應(yīng)用于一臺(tái)服務(wù)器上，但一臺(tái)服務(wù)器的物理資源總是有限的，當(dāng)數(shù)據(jù)達(dá)到這個(gè)極限時(shí)，即使分區(qū)，性能也可能會(huì)很低，所以這個(gè)時(shí)候分庫是必須的。但不管是分區(qū)、分庫還是分表，它們的思想都是一樣的，大家可以好好體會(huì)下。

視圖

對(duì)于一些關(guān)聯(lián)表的復(fù)雜查詢，使用視圖有時(shí)候會(huì)大大簡化問題，因此在許多場合下都可以看到視圖的身影，但視圖真如我們所想那樣簡單嗎？它和直接使用JOIN的 SQL 語句有何區(qū)別？視圖背后的原理又了解多少？

視圖本身是一個(gè)虛擬表，不存放任何數(shù)據(jù)，查詢視圖的數(shù)據(jù)集由其他表生成。MySQL 底層通過兩種算法來實(shí)現(xiàn)視圖：臨時(shí)表算法（TEMPTABLE）和合并算法（MERGE）。所謂臨時(shí)表算法就是將 SELECT 語句的結(jié)果存放到臨時(shí)表中，當(dāng)需要訪問視圖的時(shí)候，直接訪問這個(gè)臨時(shí)表即可。而合并算法則是重寫包含視圖的查詢，將視圖定義的 SQL 直接包含進(jìn)查詢 SQL 中。通過兩個(gè)簡單的示例來體會(huì)兩個(gè)算法的差異，創(chuàng)建如下視圖：

-- 視圖的作用是查詢未支付訂單 CREATE VIEW unpay_order AS SELECT * FROM sales WHERE status = 'new' WITH CHECK OPTION; -- 其作用下文會(huì)講

現(xiàn)要從未支付訂單中查詢購買者為csc的訂單，可以使用如下查詢：

-- 查詢購買者為csc且未支付的訂單 SELECT order_id,order_amount,buyer FROM unpay_order WHERE buyer = 'csc';

使用臨時(shí)表來模擬視圖：

CREATE TEMPORARY TABLE tmp_order_unpay AS SELECT * FROM sales WHERE status = 'new'; SELECT order_id,order_amount,buyer FROM tmp_order_unpay WHERE buyer = 'csc';

使用合并算法將視圖定義的 SQL 合并進(jìn)查詢 SQL 后的樣子：

SELECT order_id,order_amount,buyer FROM sales WHERE status = 'new' AND buyer = 'csc';

MySQL 可以嵌套定義視圖，即在一個(gè)視圖上在定義另一個(gè)視圖，可以在EXPLAIN EXTENDED之后使用SHOW WARNINGS來查看使用視圖的查詢重寫后的結(jié)果。如果采用臨時(shí)表算法實(shí)現(xiàn)的視圖，EXPLAIN中會(huì)顯示為派生表（DERIVED），注意EXPLAIN時(shí)需要實(shí)際執(zhí)行并產(chǎn)生臨時(shí)表，所以有可能會(huì)很慢。

明顯地，臨時(shí)表上沒有任何索引，而且優(yōu)化器也很難優(yōu)化臨時(shí)表上的查詢，因此，如有可能，盡量使用合并算法會(huì)有更好的性能。那么問題來了：合并算法（類似于直接查詢）有更好的性能，為什么還要使用視圖？

首先視圖可以簡化應(yīng)用上層的操作，讓應(yīng)用更專注于其所關(guān)心的數(shù)據(jù)。其次，視圖能夠?qū)γ舾袛?shù)據(jù)提供安全保護(hù)，比如：對(duì)不同的用戶定義不同的視圖，可以使敏感數(shù)據(jù)不出現(xiàn)在不應(yīng)該看到這些數(shù)據(jù)的用戶視圖上；也可以使用視圖實(shí)現(xiàn)基于列的權(quán)限控制，而不需要真正的在數(shù)據(jù)庫中創(chuàng)建列權(quán)限。再者，視圖可以方便系統(tǒng)運(yùn)維，比如：在重構(gòu) schema 的時(shí)候使用視圖，使得在修改視圖底層表結(jié)構(gòu)的時(shí)候，應(yīng)用代碼還可以繼續(xù)運(yùn)行不報(bào)錯(cuò)。

基于此，使用視圖其實(shí)更多的是基于業(yè)務(wù)或者維護(hù)成本上的考慮，其本身并不會(huì)對(duì)性能提升有多大作用（注意：此處只是基于 MySQL 考慮，其他關(guān)系性數(shù)據(jù)庫中視圖可能會(huì)有更好的性能，比如ORACLE和MS SQL SERVER都支持物化視圖，它們都比 MySQL 視圖有更好的性能）。而且使用臨時(shí)表算法實(shí)現(xiàn)的視圖，在某些時(shí)候性能可能會(huì)非常糟糕，比如：

-- 視圖的作用是統(tǒng)計(jì)每日支出金額，DATE('2017-06-15 12:00:23') = 2017-06-15 CREATE VIEW cost_per_day AS SELECT DATE(create_time) AS date,SUM(cost) AS cost FROM costs GROUP BY date;

現(xiàn)要統(tǒng)計(jì)每日的收入與支出，有類似于上面的收入表，可以使用如下 SQL：

SELECT c.date,c.cost,s.amount FROM cost_per_day AS c JOIN sale_per_day AS s USING(date) WHERE date BETWEEN '2017-06-01' AND '2017-06-30'

這個(gè)查詢中，MySQL 先執(zhí)行視圖的 SQL，生成臨時(shí)表，然后再將sale_per_day表和臨時(shí)表進(jìn)行關(guān)聯(lián)。這里WHERE字句中的BETWEEN條件并不能下推到視圖中，因而視圖在創(chuàng)建時(shí)，會(huì)將所有的數(shù)據(jù)放到臨時(shí)表中，而不是一個(gè)月數(shù)據(jù)，并且這個(gè)臨時(shí)表也不會(huì)有索引。

當(dāng)然這個(gè)示例中的臨時(shí)表數(shù)據(jù)不會(huì)太大，畢竟日期的數(shù)量不會(huì)太多，但仍然要考慮生成臨時(shí)表的性能（如果 costs 表數(shù)據(jù)過大，GROUP BY有可能會(huì)比較慢）。而且本示例中索引也不是問題，通過上一篇我們知道，如果 MySQL 將臨時(shí)表作為關(guān)聯(lián)順序中的第一張表，仍然可以使用sale_per_day中的索引。但如果是對(duì)兩個(gè)視圖做關(guān)聯(lián)的話，優(yōu)化器就沒有任何索引可以使用，這時(shí)就需要嚴(yán)格測試應(yīng)用的性能是否滿足需求。

我們很少會(huì)在實(shí)際業(yè)務(wù)場景中去更新視圖，因此印象中，視圖是不能更新的。但實(shí)際上，在某些情況下，視圖是可以更新的。可更新視圖是指通過更新這個(gè)視圖來更新視圖涉及的相關(guān)表，只要指定了合適的條件，就可以更新、刪除甚至是向視圖中插入數(shù)據(jù)。通過上文的了解，不難推斷出：更新視圖的實(shí)質(zhì)就是更新視圖關(guān)聯(lián)的表，將創(chuàng)建視圖的WHERE子句轉(zhuǎn)化為UPDATE語句的WHERE子句，只有使用合并算法的視圖才能更新，并且更新的列必須來自同一個(gè)表中。回顧上文創(chuàng)建視圖的 SQL 語句，其中有一句：WITH CHECK OPTION，其作用就是表示通過視圖更新的行，都必須符合視圖本身的WHERE條件定義，不能更新視圖定義列以外的列，否則就會(huì)拋出check option failed錯(cuò)誤。

視圖還有一個(gè)容易造成誤解的地方：“對(duì)于一些簡單的查詢，視圖會(huì)使用合并算法，而對(duì)于一些比較復(fù)雜的查詢，視圖就會(huì)使用臨時(shí)表算法”。但實(shí)際上，視圖的實(shí)現(xiàn)算法是視圖本身的屬性決定的，跟作用在視圖上的 SQL 沒有任何關(guān)系。那什么時(shí)候視圖采用臨時(shí)表算法，什么時(shí)候采用合并算法呢？一般來說，只要原表記錄和視圖中的記錄無法建立一一映射的關(guān)系時(shí)，MySQL 都將使用臨時(shí)表算法來實(shí)現(xiàn)視圖。比如創(chuàng)建視圖的 SQL 中包含GROUP BY、DISTINCT、UNION、聚合函數(shù)、子查詢的時(shí)候，視圖都將采用臨時(shí)表算法（這些規(guī)則在以后的版本中，可能會(huì)發(fā)生改變，具體請(qǐng)參考官方手冊(cè)）。

相比于其它關(guān)系型數(shù)據(jù)庫的視圖，MySQL 的視圖在功能上會(huì)弱很多，比如ORACLE和MS SQL SERVER都支持物化視圖。物化視圖是指將視圖結(jié)果數(shù)據(jù)存放在一個(gè)可以查詢的表中，并定期從原始表中刷新數(shù)據(jù)到這張表中，這張表和普通物理表一樣，可以創(chuàng)建索引、主鍵約束等等，性能相比于臨時(shí)表會(huì)有質(zhì)的提升。但遺憾的是 MySQL 目前并不支持物化視圖，當(dāng)然 MySQL 也不支持在視圖中創(chuàng)建索引。

存儲(chǔ)過程與觸發(fā)器

回到第二個(gè)問題，有非常多的人在分享時(shí)都會(huì)拋出這樣一個(gè)觀點(diǎn)：盡可能不要使用存儲(chǔ)過程，存儲(chǔ)過程非常不容易維護(hù)，也會(huì)增加使用成本，應(yīng)該把業(yè)務(wù)邏輯放到客戶端。既然客戶端都能干這些事，那為什么還要存儲(chǔ)過程？

如果有深入了解過存儲(chǔ)過程，就會(huì)發(fā)現(xiàn)存儲(chǔ)過程并沒有大家描述的那么不堪。我曾經(jīng)經(jīng)歷過一些重度使用存儲(chǔ)過程的產(chǎn)品，依賴到什么程度呢？就這么說吧，上層的應(yīng)用基本上只處理交互與動(dòng)效的邏輯，所有的業(yè)務(wù)邏輯，甚至是參數(shù)的校驗(yàn)均在存儲(chǔ)過程中實(shí)現(xiàn)。曾經(jīng)有出現(xiàn)過一個(gè)超大的存儲(chǔ)過程，其文件大小達(dá)到驚人的 80K，可想而知，其業(yè)務(wù)邏輯有多么復(fù)雜。在大多數(shù)人眼中，這樣的技術(shù)架構(gòu)簡直有點(diǎn)不可理喻，但實(shí)際上這款產(chǎn)品非常成功。

其成功的原因在一定程度上得益于存儲(chǔ)過程的優(yōu)點(diǎn)，由于業(yè)務(wù)層代碼沒有任何侵入業(yè)務(wù)的代碼，在不改變前端展示效果的同時(shí)，可以非?？焖俚男迯?fù) BUG、開發(fā)新功能。由于這款產(chǎn)品需要部署在客戶的私有環(huán)境上，快速響應(yīng)客戶的需求就變得尤為重要，正是得益于這種架構(gòu)，可以在客戶出現(xiàn)問題或者提出新需求時(shí)，快速響應(yīng)，極端情況下，我們可以在 1 小時(shí)內(nèi)修復(fù)客戶遇到的問題。正是這種快速響應(yīng)機(jī)制，讓我們獲得大量的客戶。

當(dāng)然存儲(chǔ)過程還有其他的優(yōu)點(diǎn)，比如，可以非常方便的加密存儲(chǔ)過程代碼，而不用擔(dān)心應(yīng)用部署到私有環(huán)境造成源代碼泄露、可以像調(diào)試其他應(yīng)用程序一樣調(diào)試存儲(chǔ)過程、可以設(shè)定存儲(chǔ)過程的使用權(quán)限來保證數(shù)據(jù)安全等等。一切都非常美好，但我們的產(chǎn)品是基于MS SQL SERVER實(shí)現(xiàn)的，其可以通過T-SQL非常方便的實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。你可以把T-SQL看做是一門編程語言，其包含SQL的所有功能，還具備流程控制、批處理、定時(shí)任務(wù)等能力，你甚至可以用其來解析 XML 數(shù)據(jù)。關(guān)于T-SQL的更多信息可以參考MSDN，主流的關(guān)系型數(shù)據(jù)庫目前只有MS SQL SERVER支持T-SQL，因此，MySQL 并不具備上文描述的一些能力，比如，MySQL 的存儲(chǔ)過程調(diào)試非常不方便（當(dāng)然可以通過付費(fèi)軟件來獲得很好的支持）。

除此之外，MySQL 存儲(chǔ)過程還有一些其他的限制：

• 優(yōu)化器無法評(píng)估存儲(chǔ)過程的執(zhí)行成本
• 每個(gè)連接都有獨(dú)立的存儲(chǔ)過程執(zhí)行計(jì)劃緩存，如果有多個(gè)連接需要調(diào)用同一個(gè)存儲(chǔ)過程，將會(huì)浪費(fèi)緩存空間來緩存相同的執(zhí)行計(jì)劃

因此，在 MySQL 中使用存儲(chǔ)過程并不是一個(gè)太好策略，特別是在一些大數(shù)據(jù)、高并發(fā)的場景下，將復(fù)雜的邏輯交給上層應(yīng)用實(shí)現(xiàn)，可以非常方便的擴(kuò)展已有資源以便獲得更高的計(jì)算能力。而且對(duì)于熟悉的編程語言，其可讀性會(huì)比存儲(chǔ)過程更好一些，也更加靈活。不過，在某些場景下，如果存儲(chǔ)過程比其他實(shí)現(xiàn)會(huì)快很多，并且是一些較小的操作，可以適當(dāng)考慮使用存儲(chǔ)過程。

和存儲(chǔ)過程類似的，還有觸發(fā)器，觸發(fā)器可以讓你在執(zhí)行INSERT、UPDATE和DELETE時(shí)，執(zhí)行一些特定的操作。在 MySQL 中可以選擇在 SQL 執(zhí)行之前觸發(fā)還是在 SQL 執(zhí)行后觸發(fā)。觸發(fā)器一般用于實(shí)現(xiàn)一些強(qiáng)制的限制，這些限制如果在應(yīng)用程序中實(shí)現(xiàn)會(huì)讓業(yè)務(wù)代碼變得非常復(fù)雜，而且它也可以減少客戶端與服務(wù)器之間的通信。MySQL 觸發(fā)器的實(shí)現(xiàn)非常簡單，所以功能非常有限，如果你在其他數(shù)據(jù)庫產(chǎn)品中已經(jīng)重度依賴觸發(fā)器，那么在使用 MySQL 觸發(fā)器時(shí)候需要注意，因?yàn)?MySQL 觸發(fā)器的表現(xiàn)和預(yù)想的不一致。

首先對(duì)一張表的每一個(gè)事件，最多只能定義一個(gè)觸發(fā)器，而且它只支持 “基于行的觸發(fā)”，也就是觸發(fā)器始終是針對(duì)一條記錄的，而不是針對(duì)整個(gè) SQL 語句。如果是批量更新的話，效率可能會(huì)很低。其次，觸發(fā)器可以掩蓋服務(wù)器本質(zhì)工作，一個(gè)簡單的 SQL 語句背后，因?yàn)橛|發(fā)器，可能包含了很多看不見的工作。再者，觸發(fā)器出現(xiàn)問題時(shí)很難排查。最后，觸發(fā)器并不一定能保證原子性，比如MyISAM引擎下觸發(fā)器執(zhí)行失敗了，也不能回滾。在InnoDB表上的觸發(fā)器是在同一個(gè)事務(wù)中執(zhí)行完成的，所以他們的執(zhí)行是原子的，原操作和觸發(fā)器操作會(huì)同時(shí)失敗或者成功。

雖然觸發(fā)器有這么多限制，但它仍有適用的場景，比如，當(dāng)你需要記錄 MySQL 數(shù)據(jù)的變更日志，這時(shí)觸發(fā)器就非常方便了。

外鍵約束

目前在大多數(shù)互聯(lián)網(wǎng)項(xiàng)目，特別是在大數(shù)據(jù)的場景下，已經(jīng)不建議使用外鍵了，主要是考慮到外鍵的使用成本：

• 外鍵通常要求每次修改數(shù)據(jù)時(shí)都要在另外一張表中執(zhí)行一次查找操作。在 InnoDB 存儲(chǔ)引擎中會(huì)強(qiáng)制外鍵使用索引，但在大數(shù)據(jù)的情況下，仍然不能忽略外鍵檢查帶來的開銷，特別是當(dāng)外鍵的選擇性很低時(shí)，會(huì)導(dǎo)致一個(gè)非常大且選擇性低的索引。
• 如果向子表中插入一條記錄，外鍵約束會(huì)讓 InnoDB 檢查對(duì)應(yīng)的父表的記錄，也就需要對(duì)父表對(duì)應(yīng)記錄進(jìn)行加鎖操作，來確保這條記錄不會(huì)在這個(gè)事務(wù)完成之時(shí)就被刪除了。這會(huì)導(dǎo)致額外的鎖等待，甚至?xí)?dǎo)致一些死鎖。
• 高并發(fā)場景下，數(shù)據(jù)庫很容易成為性能瓶頸，自然而然的就希望數(shù)據(jù)庫可以水平擴(kuò)展，這時(shí)就需要把數(shù)據(jù)的一致性控制放到應(yīng)用層，也就是讓應(yīng)用服務(wù)器可以承擔(dān)壓力，這種情況下，數(shù)據(jù)庫層面就不能使用外鍵。

因此，當(dāng)不用過多考慮數(shù)據(jù)庫的性能問題時(shí)，比如一些內(nèi)部項(xiàng)目或傳統(tǒng)行業(yè)項(xiàng)目（其使用人數(shù)有限，而且數(shù)據(jù)量一般不會(huì)太大），使用外鍵是一個(gè)不錯(cuò)的選擇，畢竟想要確保相關(guān)表始終有一致的數(shù)據(jù)，使用外鍵要比在應(yīng)用程序中檢查一致性方便簡單許多，此外，外鍵在相關(guān)數(shù)據(jù)的刪除和更新操作上也會(huì)比在應(yīng)用中要高效。

綁定變量

可能大家看到 “綁定變量” 這個(gè)詞時(shí)，會(huì)有一點(diǎn)陌生，換個(gè)說法可能會(huì)熟悉一些：prepared statement。綁定變量的 SQL，使用問號(hào)標(biāo)記可以接收參數(shù)的位置，當(dāng)真正需要執(zhí)行具體查詢的時(shí)候，則使用具體的數(shù)值代替這些問號(hào)，比如：

SELECT order_no, order_amount FROM sales WHERE order_status = ? and buyer = ?

為什么要使用綁定變量？總所周知的原因是可以預(yù)先編譯，減少 SQL 注入的風(fēng)險(xiǎn)，除了這些呢？

當(dāng)創(chuàng)建一個(gè)綁定變量 SQL 時(shí)，客戶端向服務(wù)器發(fā)送了一個(gè) SQL 語句原型，服務(wù)器收到這個(gè) SQL 語句的框架后，解析并存儲(chǔ)這個(gè) SQL 語句的部分執(zhí)行計(jì)劃，返回給客戶端一個(gè) SQL 語句處理句柄，從此以后，客戶端通過向服務(wù)器發(fā)送各個(gè)問號(hào)的取值和這個(gè)句柄來執(zhí)行一個(gè)具體查詢，這樣就可以更高效地執(zhí)行大量重復(fù)語句，因?yàn)?#xff1a;

• 服務(wù)器只需要解析一次 SQL 語句
• 服務(wù)器某些優(yōu)化器的優(yōu)化工作也只需要做一次，因?yàn)?MySQL 會(huì)緩存部分執(zhí)行計(jì)劃
• 通信中僅僅發(fā)送的是參數(shù)，而不是整個(gè)語句，網(wǎng)絡(luò)開銷也會(huì)更小，而且以二進(jìn)制發(fā)送參數(shù)和句柄要比發(fā)送 ASCII 文本的效率更高

需要注意的是，MySQL 并不是總能緩存執(zhí)行計(jì)劃，如果某些執(zhí)行計(jì)劃需要根據(jù)參入的參數(shù)來計(jì)算時(shí)，MySQL 就無法緩存這部分執(zhí)行計(jì)劃。比如：

-- 這里假裝有一個(gè)例子，大家可以自己思考一下

使用綁定變量的最大陷阱是：你知道其原理，但不知道它是如何實(shí)現(xiàn)的。有時(shí)候，很難解釋如下 3 種綁定變量類型之間的區(qū)別：

客戶端模擬的綁定變量：客戶端的驅(qū)動(dòng)程序接收一個(gè)帶參數(shù)的 SQL，再將參數(shù)的值帶入其中，最后將完整的查詢發(fā)送到服務(wù)器。

服務(wù)器綁定變量：客戶端使用特殊的二進(jìn)制協(xié)議將帶參數(shù)的 SQL 語句發(fā)送到服務(wù)器端，然后使用二進(jìn)制協(xié)議將具體的參數(shù)值發(fā)送給服務(wù)器并執(zhí)行。

SQL 接口的綁定變量：客戶端先發(fā)送一個(gè)帶參數(shù)的 SQL 語句到服務(wù)器端，這類似于使用prepared的 SQL 語句，然后發(fā)送設(shè)置的參數(shù)，最后在發(fā)送execute指令來執(zhí)行 SQL，所有這些都是用普通的文本傳輸協(xié)議。

比如某些不支持預(yù)編譯的 JDBC 驅(qū)動(dòng)，在調(diào)用connection.prepareStatement(sql)時(shí)，并不會(huì)把 SQL 語句發(fā)送給數(shù)據(jù)庫做預(yù)處理，而是等到調(diào)用executeQuery方法時(shí)才把整個(gè)語句發(fā)送到服務(wù)器，這種方式就類似于第 1 種情況。因此，在程序中使用綁定變量時(shí)，理解你使用的驅(qū)動(dòng)通過哪種方式來實(shí)現(xiàn)就顯得很有必要。延伸開來說，對(duì)于自己使用的框架、開源工具，不應(yīng)僅僅停留在會(huì)使用這個(gè)層面，有時(shí)間可以深入了解其原理和實(shí)現(xiàn)，不然有可能被騙了都不知道哦。

用戶自定義函數(shù)

MySQL 本身內(nèi)置了非常多的函數(shù)，比如SUM、COUNT、AVG等等，可實(shí)際應(yīng)用中，我們常常需要更多。大多數(shù)情況下，更強(qiáng)大的功能都是在應(yīng)用層面實(shí)現(xiàn)，但實(shí)際上 MySQL 也提供了機(jī)會(huì)讓我們可以去擴(kuò)展 MySQL 函數(shù)，這就是用戶自定義函數(shù) (user-defined function)，也稱為：UDF。需要注意UDF與存儲(chǔ)過程和通過 SQL 創(chuàng)建函數(shù)的區(qū)別，存儲(chǔ)過程只能使用 SQL 來編寫，而UDF沒有這個(gè)限制，可以使用支持 C 語言調(diào)用約定的任何編程語言來實(shí)現(xiàn)。

UDF必須事先編譯好并動(dòng)態(tài)鏈接到服務(wù)器上，這種平臺(tái)相關(guān)性使得UDF在很多方面都很強(qiáng)大，UDF速度非?？?#xff0c;而且可以訪問大量操作系統(tǒng)功能，還可以使用大量庫函數(shù)。如果需要一個(gè) MySQL 不支持的統(tǒng)計(jì)聚合函數(shù)，并且無法使用存儲(chǔ)過程來實(shí)現(xiàn)，而且還想不同的語言都可以調(diào)用，那么UDF是不錯(cuò)的選擇，至少不需要每種語言都來實(shí)現(xiàn)相同的邏輯。

所謂能力越大，責(zé)任也就越大，UDF中的一個(gè)錯(cuò)誤可能直接讓服務(wù)器崩潰，甚至擾亂服務(wù)器的內(nèi)存和數(shù)據(jù)，因此，使用時(shí)需要注意其潛在的風(fēng)險(xiǎn)。在 MySQL 版本升級(jí)時(shí)也需要注意，因?yàn)槟憧赡苄枰匦戮幾g或者修改這些UDF，以便讓它們能在新版本中工作。

這里有一個(gè)簡單的示例來展示如何創(chuàng)建UDF：將結(jié)果集轉(zhuǎn)化為 JSON，具體的代碼請(qǐng)參考：lib_mysqludf_json。

-- 1、首先使用c語言實(shí)現(xiàn)功能 -- 2、編譯 -- 這里省略第1、2步，實(shí)現(xiàn)并編譯成.so -- 3、使用SQL創(chuàng)建函數(shù) DROP FUNCTION json_array; CREATE FUNCTION json_array RETURNS string soname 'lib_mysqludf_json.so'; -- 4、使用函數(shù) SELECTjson_array(customer_id,first_name,last_name,last_update) as customer FROMcustomer WHEREcustomer_id = 1; /* 5、得到的結(jié)果如下： +------------------------------------------+ | customer | +------------------------------------------+ | [1,"MARY","SMITH","2006-02-15 04:57:20"] | +------------------------------------------+ */

其大致的實(shí)現(xiàn)流程：使用 C 語言實(shí)現(xiàn)邏輯 -> 編譯成.so文件 -> 創(chuàng)建函數(shù) -> 使用函數(shù)。UDF在實(shí)際工作中可能很少使用，但作為開發(fā)者的我們，了解這么一款強(qiáng)大的工具，在解決棘手問題時(shí)，也讓我們有了更多的選擇。

字符集

最后說說字符集。

關(guān)于字符集大多數(shù)人的第一印象可能就是：數(shù)據(jù)庫字符集盡量使用UTF8，因?yàn)閁TF8字符集是目前最適合于實(shí)現(xiàn)多種不同字符集之間的轉(zhuǎn)換的字符集，可以最大程度上避免亂碼問題，也可以方便以后的數(shù)據(jù)遷移。But why？

字符集是指一種從二進(jìn)制編碼到某類字符符號(hào)的映射，可以參考如何使用一個(gè)字節(jié)來表示英文字母。校對(duì)規(guī)則是指一組用于某個(gè)字符集的排序規(guī)則，即采用何種規(guī)則對(duì)某類字符進(jìn)行排序。MySQL 每一類編碼字符都有其對(duì)應(yīng)的字符集和校對(duì)規(guī)則。MySQL 對(duì)各種字符集的支持都非常完善，但同時(shí)也帶來一些復(fù)雜性，某些場景下甚至?xí)幸恍┬阅軤奚?/p>

一種字符集可能對(duì)應(yīng)多種校對(duì)規(guī)則，且都有一個(gè)默認(rèn)校對(duì)規(guī)則，那在 MySQL 中是如何使用字符集的？在 MySQL 中可以通過兩種方式設(shè)置字符集：創(chuàng)建對(duì)象時(shí)設(shè)置默認(rèn)值、客戶端與服務(wù)器通信時(shí)顯式設(shè)置。

MySQL 采用 “階梯” 式的方式來設(shè)定字符集默認(rèn)值，每個(gè)數(shù)據(jù)庫，每張表都有自己的默認(rèn)值，它們逐層繼承，最終最靠底層的默認(rèn)設(shè)置將影響你創(chuàng)建的對(duì)象。比如，創(chuàng)建數(shù)據(jù)庫時(shí)，將根據(jù)服務(wù)器上的character_set_server來設(shè)置數(shù)據(jù)庫的默認(rèn)字符集，同樣的道理，根據(jù)database的字符集來指定庫中所有表的字符集…… 不管是對(duì)數(shù)據(jù)庫，還是表和列，只有當(dāng)它們沒有顯式指定字符集時(shí)，默認(rèn)字符集才會(huì)起作用。

當(dāng)客戶端與服務(wù)器通信時(shí)，它們可以使用不同的字符集，這時(shí)候服務(wù)器將進(jìn)行必要的轉(zhuǎn)換工作。當(dāng)客戶端向服務(wù)器發(fā)送請(qǐng)求時(shí)，數(shù)據(jù)以character_set_client設(shè)置的字符集進(jìn)行編碼；而當(dāng)服務(wù)器收到客戶端的 SQL 或者數(shù)據(jù)時(shí)，會(huì)按照character_set_connection設(shè)置的字符集進(jìn)行轉(zhuǎn)換；當(dāng)服務(wù)器將要進(jìn)行增刪改查等操作前會(huì)再次將數(shù)據(jù)轉(zhuǎn)換成character_set_database(數(shù)據(jù)庫采用的字符集，沒有單獨(dú)配置即使用默認(rèn)配置，具體參考上文)，最后當(dāng)服務(wù)器返回?cái)?shù)據(jù)或者錯(cuò)誤信息時(shí)，則將數(shù)據(jù)按character_set_result設(shè)置的字符集進(jìn)行編碼。服務(wù)器端可以使用SET CHARACTER SET來改變上面的配置，客戶端也可以根據(jù)對(duì)應(yīng)的 API 來改變字符集配置。客戶端和服務(wù)器端都使用正確的字符集才能避免在通信中出現(xiàn)問題。

那如何選擇字符集？

在考慮使用何種字符集時(shí)，最主要的衡量因素是存儲(chǔ)的內(nèi)容，在能夠滿足存儲(chǔ)內(nèi)容的前提下，盡量使用較小的字符集。因?yàn)楦〉淖址馕吨倏臻g占用、以及更高的網(wǎng)絡(luò)傳輸效率，也間接提高了系統(tǒng)的性能。如果存儲(chǔ)的內(nèi)容是英文字符等拉丁語系字符的話，那么使用默認(rèn)的latin1字符集完全沒有問題（MySQL 8 默認(rèn)utf8mb4），如果需要存儲(chǔ)漢字、俄文、阿拉伯語等非拉丁語系字符，則建議使用UTF8字符集。當(dāng)然不同字符在使用UTF8字符集所占用的空間是不同的，比如英文字符在UTF8字符集中只使用一個(gè)字節(jié)，而一個(gè)漢字則占用 3 個(gè)字節(jié)。

除了字符集，校對(duì)規(guī)則也是我們需要考慮的問題。對(duì)于校對(duì)規(guī)則，一般來說只需要考慮是否以大小寫敏感的方式比較字符串或者是否用字符串編碼的二進(jìn)制來比較大小，其對(duì)應(yīng)的校對(duì)規(guī)則的后綴分別是_cs、_ci和_bin。大小寫敏感和二進(jìn)制校對(duì)規(guī)則的不同之處在于，二進(jìn)制校對(duì)規(guī)則直接使用字符的字節(jié)進(jìn)行比較，而大小寫敏感的校對(duì)規(guī)則在多字節(jié)字符集時(shí)，如德語，有更復(fù)雜的比較規(guī)則。舉個(gè)簡單的例子，UTF8字符集對(duì)應(yīng)校對(duì)規(guī)則有三種：

• utf8_bin將字符串中的每一個(gè)字符用二進(jìn)制數(shù)據(jù)存儲(chǔ)，區(qū)分大小寫
• utf8_general_ci不區(qū)分大小寫，ci為case insensitive的縮寫，即大小寫不敏感
• utf8_general_cs區(qū)分大小寫，cs為case sensitive的縮寫，即大小寫敏感

比如，創(chuàng)建一張表，使用UTF8編碼，且大小寫敏感時(shí)，可以使用如下語句：

CREATE TABLE sales (order_no VARCHAR(32) NOT NULL PRIMARY KEY,order_amount INT NOT NULL DEFAULT 0,...... ) ENGINE=InnoDB COLLATE=utf8_general_cs;

因此，在項(xiàng)目中直接使用UTF8字符集是完全沒有問題的，但需要記住的是不要在一個(gè)數(shù)據(jù)庫中使用多個(gè)不同的字符集，不同字符集之間的不兼容問題很難纏。有時(shí)候，看起來一切正常，但是當(dāng)某個(gè)特殊字符出現(xiàn)時(shí)，一切操作都會(huì)出錯(cuò)，而且你很難發(fā)現(xiàn)錯(cuò)誤的原因。

字符集對(duì)數(shù)據(jù)庫的性能有影響嗎？

某些字符集和校對(duì)規(guī)則可能會(huì)需要多個(gè)的 CPU 操作，可能會(huì)消耗更多的內(nèi)存和存儲(chǔ)空間，這點(diǎn)在前文已經(jīng)說過。特別是在同一個(gè)數(shù)據(jù)庫中使用不同的字符集，造成的影響可能會(huì)更大。

不同字符集和校對(duì)規(guī)則之間的轉(zhuǎn)換可能會(huì)帶來額外的系統(tǒng)開銷，比如，數(shù)據(jù)表sales在buyer字段上有索引，則可以加速下面的ORDER BY操作：

SELECT order_no,order_amount FROM sales ORDER BY buyer;

只有當(dāng) SQL 查詢中排序要求的字符集與服務(wù)器數(shù)據(jù)的字符集相同時(shí)，才能使用索引進(jìn)行排序。你可能會(huì)說，這不是廢話嗎？其實(shí)不然，MySQL 是可以單獨(dú)指定排序時(shí)使用的校對(duì)規(guī)則的，比如：

-- 你說，這不是吃飽了撐的嗎？我覺得也是，也許會(huì)有其適用的場景吧 -- 這時(shí)候就不能使用索引排序呢，只能使用文件排序 SELECT order_no,order_amount FROM sales ORDER BY buyer COLLATE utf8_bin;

當(dāng)使用兩個(gè)字符集不同的列來關(guān)聯(lián)兩張表時(shí)，MySQL 會(huì)嘗試轉(zhuǎn)換其中一個(gè)列的字符集。這和在數(shù)據(jù)列外面封裝一個(gè)函數(shù)一樣，會(huì)讓 MySQL 無法使用這個(gè)列上的索引。關(guān)于 MySQL 字符集還有一些坑，但在實(shí)際應(yīng)用場景中遇到的字符集問題，其實(shí)不是特別的多，所以就此打住。

結(jié)語

MySQL 還有一些其他高級(jí)特性，但在大多數(shù)場景下我們很少會(huì)使用，因此這里也沒有討論，但多了解一些總是好的，至少在需要的時(shí)候，你知道有這樣一個(gè)東西。我們非常多的人，總是會(huì)認(rèn)為自己所學(xué)的知識(shí)就像碎片一樣不成體系，又找不到解決辦法，那你有沒有想過也許是碎片不夠多的緣故？點(diǎn)太少，自然不能連接成線，線太少，自然不能結(jié)成網(wǎng)。因而，沒有其他辦法，保持好奇心、多學(xué)習(xí)、多積累，量變總有一天會(huì)質(zhì)變，寫在這兒，與大家共勉吧。

前面我寫的一些文章里面會(huì)有提到過，架構(gòu)設(shè)計(jì)是一種平衡的藝術(shù)，其實(shí)質(zhì)應(yīng)該是一種妥協(xié)，是對(duì)現(xiàn)有資源的一種妥協(xié)。有時(shí)候我們會(huì)不自覺的陷入某一個(gè)點(diǎn)，比如，為了追求數(shù)據(jù)的擴(kuò)展性，很多人一上來就開始分庫分表，然后把應(yīng)用搞得非常復(fù)雜，到最后表里還沒有裝滿數(shù)據(jù)，項(xiàng)目就已經(jīng)死了。所以在資源有限或者未來還不可知的情況下，盡量使用數(shù)據(jù)庫、語言本身的特性來完成相應(yīng)的工作，是不是會(huì)更好一點(diǎn)。解決大數(shù)據(jù)問題，也不只是分庫分表，你還應(yīng)該還可以想到分區(qū)；有些業(yè)務(wù)即使在分布式環(huán)境下也不一定非要在業(yè)務(wù)層完成，合理使用存儲(chǔ)過程和觸發(fā)器，也許會(huì)讓你更輕松……

最后，本文所討論的知識(shí)點(diǎn)均出自《高性能 MySQL》，強(qiáng)烈建議大家讀一讀這本書。

參考資料

高性能 MySQL（第 3 版）

• 本文作者：?Yibo
• 本文鏈接：?https://windmt.com/2018/05/04/mysql-optimization-principle-2/
• 版權(quán)聲明：?本博客所有文章除特別聲明外，均采用?CC BY-NC-SA 4.0?許可協(xié)議。轉(zhuǎn)載請(qǐng)注明出處！

總結(jié)

以上是生活随笔為你收集整理的MySQL 优化原理（二）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。