1. 什么是MySQL?
2. 存儲引擎
3. 字符集及校對規(guī)則
4. 索引
5. 查詢緩存的使用
6. 事務(wù)的定義
7. 事務(wù)的四大特性(ACID)
8. 并發(fā)事務(wù)帶來哪些問題钩乍？
9. 事務(wù)隔離級別有哪些? MySQL的默認(rèn)隔離級別获三？
10. 鎖機(jī)制與InnoDB鎖算法
11. 大表優(yōu)化
12. 解釋一下什么是池化設(shè)計(jì)思想岛抄。什么是數(shù)據(jù)庫連接池?為什么需要數(shù)據(jù)庫連接池?
13. 分庫分表之后,id 主鍵如何處理乾蛤？
14. 一條sql語句在Mysql之中是怎么執(zhí)行的?
15. 一條SQL語句執(zhí)行的很慢的原因
16. 關(guān)于數(shù)據(jù)庫存儲時間的思考

1. 什么是MySQL?

MySQL是一種關(guān)系數(shù)據(jù)庫斗搞， 方便擴(kuò)展 && 有保障的穩(wěn)定性 && 默認(rèn)端口號是3306

2. 存儲引擎

不同的存儲引擎: 數(shù)據(jù)使用各種不同的技術(shù)存儲在文件(內(nèi)存中)绷跑，不同的技術(shù)包括存儲機(jī)制，索引技巧以及鎖定水平等氮发。

2.1 一些常用指令

1. 查看MySQL提供的所有存儲引擎

show engines;

查看MySQL提供的所有存儲引擎

2. 查看MySQL當(dāng)前默認(rèn)的存儲引擎

show variables like '%storage_engine%';

查看MySQL當(dāng)前默認(rèn)的存儲引擎

3. 查看表的存儲引擎

show table status like "table_name" ;

查看表的存儲引擎

2.2 MyISAM和InnoDB區(qū)別

MyISAM是MySQL的默認(rèn)數(shù)據(jù)庫引擎（5.5版之前）。雖然性能極佳冗懦，而且提供了大量的特性爽冕，包括全文索引、壓縮披蕉、空間函數(shù)等颈畸，但MyISAM不支持事務(wù)和行級鎖乌奇，而且最大的缺陷就是崩潰后無法安全恢復(fù)。不過眯娱，5.5版本之后礁苗，MySQL引入了InnoDB（事務(wù)性數(shù)據(jù)庫引擎），MySQL 5.5版本后默認(rèn)的存儲引擎為InnoDB徙缴。

大多數(shù)時候我們使用的都是 InnoDB 存儲引擎试伙，但是在某些情況下使用 MyISAM 也是合適的比如讀密集的情況下。

兩者對比:

1. 是否支持行級鎖 : MyISAM 只有表級鎖(table-level locking)于样，而InnoDB 支持行級鎖(row-level locking)和表級鎖,默認(rèn)為行級鎖疏叨。
2. 是否支持事務(wù)和崩潰后的安全恢復(fù)： MyISAM 強(qiáng)調(diào)的是性能，每次查詢具有原子性,其執(zhí)行速度比InnoDB類型更快穿剖，但是不提供事務(wù)支持蚤蔓。但是InnoDB 提供事務(wù)支持事務(wù)，外部鍵等高級數(shù)據(jù)庫功能糊余。 具有事務(wù)(commit)秀又、回滾(rollback)和崩潰修復(fù)能力(crash recovery capabilities)的事務(wù)安全(transaction-safe (ACID compliant))型表。
3. 是否支持外鍵： MyISAM不支持贬芥，而InnoDB支持吐辙。
4. 是否支持MVCC ：僅 InnoDB 支持。應(yīng)對高并發(fā)事務(wù), MVCC比單純的加鎖更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 兩個隔離級別下工作;MVCC可以使用 樂觀(optimistic)鎖 和 悲觀(pessimistic)鎖來實(shí)現(xiàn);各數(shù)據(jù)庫中MVCC實(shí)現(xiàn)并不統(tǒng)一誓军。

一般情況下我們選擇 InnoDB 都是沒有問題的袱讹，但是某些情況下你并不在乎可擴(kuò)展能力和并發(fā)能力，也不需要事務(wù)支持昵时，也不在乎崩潰后的安全恢復(fù)問題的話捷雕，選擇MyISAM也是一個不錯的選擇。但是一般情況下壹甥，我們都是需要考慮到這些問題的救巷。

MyISAM和InnoDB區(qū)別

MVCC簡述

3. 字符集及校對規(guī)則

字符集指的是一種從二進(jìn)制編碼到某類字符符號的映射, eg: utf-8, ascii, gbk, latin1。校對規(guī)則則是指某種字符集下的排序規(guī)則句柠。MySQL中每一種字符集都會對應(yīng)一系列的校對規(guī)則浦译。

MySQL采用的是類似繼承的方式指定字符集的默認(rèn)值，每個數(shù)據(jù)庫以及每張數(shù)據(jù)表都有自己的默認(rèn)值溯职，他們逐層繼承精盅。比如：某個庫中所有表的默認(rèn)字符集將是該數(shù)據(jù)庫所指定的字符集（這些表在沒有指定字符集的情況下，才會采用默認(rèn)字符集）

4. 索引

MySQL索引使用的數(shù)據(jù)結(jié)構(gòu)主要有BTree索引 和 哈希索引 谜酒。對于哈希索引來說叹俏，底層的數(shù)據(jù)結(jié)構(gòu)就是哈希表，因此在絕大多數(shù)需求為單條記錄查詢的時候僻族，可以選擇哈希索引粘驰，查詢性能最快屡谐；其余大部分場景，建議選擇BTree索引蝌数。

MySQL的BTree索引使用的是B樹中的B+Tree愕掏，但對于主要的兩種存儲引擎的實(shí)現(xiàn)方式是不同的。

• MyISAM: B+Tree葉節(jié)點(diǎn)的data域存放的是數(shù)據(jù)記錄的地址顶伞。在索引檢索的時候饵撑，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在枝哄，則取出其 data 域的值肄梨，然后以 data 域的值為地址讀取相應(yīng)的數(shù)據(jù)記錄。這被稱為“非聚簇索引”挠锥。

MyISAM索引實(shí)現(xiàn)

• InnoDB: 其數(shù)據(jù)文件本身就是索引文件众羡。相比MyISAM，索引文件和數(shù)據(jù)文件是分離的蓖租，其表數(shù)據(jù)文件本身就是按B+Tree組織的一個索引結(jié)構(gòu)粱侣，樹的葉節(jié)點(diǎn)data域保存了完整的數(shù)據(jù)記錄。這個索引的key是數(shù)據(jù)表的主鍵蓖宦，因此InnoDB表數(shù)據(jù)文件本身就是主索引齐婴。這被稱為“聚簇索引（或聚集索引）”。而其余的索引都作為輔助索引稠茂，輔助索引的data域存儲相應(yīng)記錄主鍵的值而不是地址柠偶，這也是和MyISAM不同的地方。在根據(jù)主索引搜索時睬关，直接找到key所在的節(jié)點(diǎn)即可取出數(shù)據(jù)诱担；在根據(jù)輔助索引查找時，則需要先取出主鍵的值电爹，再走一遍主索引蔫仙。 因此，在設(shè)計(jì)表的時候丐箩，不建議使用過長的字段作為主鍵摇邦，也不建議使用非單調(diào)的字段作為主鍵，這樣會造成主索引頻繁分裂屎勘。

InnoDB索引實(shí)現(xiàn)

5. 查詢緩存的使用

執(zhí)行查詢語句的時候施籍，會先查詢緩存。不過概漱，MySQL 8.0 版本后移除丑慎，因?yàn)檫@個功能不太實(shí)用

5.1 開啟緩存的方式

1. my.cnf加入以下配置，重啟MySQL開啟查詢緩存

query_cache_type=1
query_cache_size=600000

2. MySQL執(zhí)行以下命令也可以開啟查詢緩存

set global  query_cache_type=1;
set global  query_cache_size=600000;

5.2 查詢緩存的作用以及優(yōu)缺點(diǎn)

如上，開啟查詢緩存后在同樣的查詢條件以及數(shù)據(jù)情況下立哑，會直接在緩存中返回結(jié)果。這里的查詢條件包括查詢本身姻灶、當(dāng)前要查詢的數(shù)據(jù)庫铛绰、客戶端協(xié)議版本號等一些可能影響結(jié)果的信息。因此任何兩個查詢在任何字符上的不同都會導(dǎo)致緩存不命中产喉。此外捂掰，如果查詢中包含任何用戶自定義函數(shù)、存儲函數(shù)曾沈、用戶變量这嚣、臨時表、MySQL庫中的系統(tǒng)表塞俱，其查詢結(jié)果也不會被緩存姐帚。

緩存建立之后，MySQL的查詢緩存系統(tǒng)會跟蹤查詢中涉及的每張表障涯，如果這些表（數(shù)據(jù)或結(jié)構(gòu)）發(fā)生變化罐旗，那么和這張表相關(guān)的所有緩存數(shù)據(jù)都將失效。

緩存雖然能夠提升數(shù)據(jù)庫的查詢性能唯蝶，但是緩存同時也帶來了額外的開銷九秀，每次查詢后都要做一次緩存操作，失效后還要銷毀粘我。 因此鼓蜒，開啟緩存查詢要謹(jǐn)慎，尤其對于寫密集的應(yīng)用來說更是如此征字。如果開啟都弹，要注意合理控制緩存空間大小，一般來說其大小設(shè)置為幾十MB比較合適柔纵。

還可以通過sql_cache和sql_no_cache來控制某個查詢語句是否需要緩存：

select sql_no_cache count(*) from usr;

6. 事務(wù)的定義

事務(wù)是邏輯上的一組操作缔杉，要么都執(zhí)行，要么都不執(zhí)行搁料。

7. 事務(wù)的四大特性(ACID)

事務(wù)的四大特性

1. 原子性（Atomicity）： 事務(wù)是最小的執(zhí)行單位或详，不允許分割。事務(wù)的原子性確保動作要么全部完成郭计，要么完全不起作用霸琴；
2. 一致性（Consistency）： 執(zhí)行事務(wù)前后，數(shù)據(jù)保持一致昭伸，多個事務(wù)對同一個數(shù)據(jù)讀取的結(jié)果是相同的梧乘；
3. 隔離性（Isolation）： 并發(fā)訪問數(shù)據(jù)庫時，一個用戶的事務(wù)不被其他事務(wù)所干擾，各并發(fā)事務(wù)之間數(shù)據(jù)庫是獨(dú)立的选调；
4. 持久性（Durability）： 一個事務(wù)被提交之后夹供。它對數(shù)據(jù)庫中數(shù)據(jù)的改變是持久的，即使數(shù)據(jù)庫發(fā)生故障也不應(yīng)該對其有任何影響仁堪。

8. 并發(fā)事務(wù)帶來哪些問題哮洽？

在典型的應(yīng)用程序中，多個事務(wù)并發(fā)運(yùn)行弦聂，經(jīng)常會操作相同的數(shù)據(jù)來完成各自的任務(wù)（多個用戶對同一數(shù)據(jù)進(jìn)行操作）鸟辅。并發(fā)雖然是必須的，但可能會導(dǎo)致以下的問題莺葫。

• 臟讀（Dirty read）: 當(dāng)一個事務(wù)正在訪問數(shù)據(jù)并且對數(shù)據(jù)進(jìn)行了修改匪凉，而這種修改還沒有提交到數(shù)據(jù)庫中，這時另外一個事務(wù)也訪問了這個數(shù)據(jù)捺檬，然后使用了這個數(shù)據(jù)再层。因?yàn)檫@個數(shù)據(jù)是還沒有提交的數(shù)據(jù)，那么另外一個事務(wù)讀到的這個數(shù)據(jù)是“臟數(shù)據(jù)”堡纬，依據(jù)“臟數(shù)據(jù)”所做的操作可能是不正確的树绩。
• 丟失修改（Lost to modify）: 指在一個事務(wù)讀取一個數(shù)據(jù)時，另外一個事務(wù)也訪問了該數(shù)據(jù)隐轩，那么在第一個事務(wù)中修改了這個數(shù)據(jù)后饺饭，第二個事務(wù)也修改了這個數(shù)據(jù)。這樣第一個事務(wù)內(nèi)的修改結(jié)果就被丟失职车，因此稱為丟失修改瘫俊。 例如：事務(wù)1讀取某表中的數(shù)據(jù)A=20，事務(wù)2也讀取A=20悴灵，事務(wù)1修改A=A-1扛芽，事務(wù)2也修改A=A-1，最終結(jié)果A=19积瞒，事務(wù)1的修改被丟失川尖。
• 不可重復(fù)讀（Unrepeatableread）: 指在一個事務(wù)內(nèi)多次讀同一數(shù)據(jù)。在這個事務(wù)還沒有結(jié)束時茫孔，另一個事務(wù)也訪問該數(shù)據(jù)叮喳。那么，在第一個事務(wù)中的兩次讀數(shù)據(jù)之間缰贝，由于第二個事務(wù)的修改導(dǎo)致第一個事務(wù)兩次讀取的數(shù)據(jù)可能不太一樣馍悟。這就發(fā)生了在一個事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的情況，因此稱為不可重復(fù)讀剩晴。
• 幻讀（Phantom read）: 幻讀與不可重復(fù)讀類似锣咒。它發(fā)生在一個事務(wù)（T1）讀取了幾行數(shù)據(jù)侵状，接著另一個并發(fā)事務(wù)（T2）插入了一些數(shù)據(jù)時。在隨后的查詢中毅整，第一個事務(wù)（T1）就會發(fā)現(xiàn)多了一些原本不存在的記錄趣兄，就好像發(fā)生了幻覺一樣，所以稱為幻讀悼嫉。

不可重復(fù)讀和幻讀區(qū)別：
不可重復(fù)讀的重點(diǎn)是修改比如多次讀取一條記錄發(fā)現(xiàn)其中某些列的值被修改诽俯，幻讀的重點(diǎn)在于新增或者刪除比如多次讀取一條記錄發(fā)現(xiàn)記錄增多或減少了。

9. 事務(wù)隔離級別有哪些? MySQL的默認(rèn)隔離級別承粤？

SQL 標(biāo)準(zhǔn)定義了四個隔離級別：

• READ-UNCOMMITTED(讀取未提交)： 最低的隔離級別，允許讀取尚未提交的數(shù)據(jù)變更闯团，可能會導(dǎo)致臟讀辛臊、幻讀或不可重復(fù)讀。
• READ-COMMITTED(讀取已提交)： 允許讀取并發(fā)事務(wù)已經(jīng)提交的數(shù)據(jù)房交，可以阻止臟讀彻舰，但是幻讀或不可重復(fù)讀仍有可能發(fā)生。
• REPEATABLE-READ(可重復(fù)讀)： 對同一字段的多次讀取結(jié)果都是一致的候味，除非數(shù)據(jù)是被本身事務(wù)自己所修改刃唤，可以阻止臟讀和不可重復(fù)讀，但幻讀仍有可能發(fā)生白群。
• SERIALIZABLE(可串行化)： 最高的隔離級別尚胞，完全服從ACID的隔離級別。所有的事務(wù)依次逐個執(zhí)行帜慢，這樣事務(wù)之間就完全不可能產(chǎn)生干擾笼裳，也就是說，該級別可以防止臟讀粱玲、不可重復(fù)讀以及幻讀躬柬。

隔離級別

MySQL InnoDB 存儲引擎的默認(rèn)支持的隔離級別是 REPEATABLE-READ（可重讀）。我們可以通過SELECT @@tx_isolation;命令來查看抽减，MySQL 8.0 該命令改為SELECT @@transaction_isolation;

MySQL InnoDB 存儲引擎的默認(rèn)支持的隔離級別

這里需要注意的是：與 SQL 標(biāo)準(zhǔn)不同的地方在于 InnoDB 存儲引擎在 REPEATABLE-READ（可重讀） 事務(wù)隔離級別下使用的是Next-Key Lock 鎖算法允青，因此可以避免幻讀的產(chǎn)生，這與其他數(shù)據(jù)庫系統(tǒng)(如 SQL Server) 是不同的卵沉。所以說InnoDB 存儲引擎的默認(rèn)支持的隔離級別是 REPEATABLE-READ（可重讀） 已經(jīng)可以完全保證事務(wù)的隔離性要求颠锉，即達(dá)到了 SQL標(biāo)準(zhǔn)的 SERIALIZABLE(可串行化) 隔離級別。因?yàn)楦綦x級別越低史汗，事務(wù)請求的鎖越少木柬，所以大部分?jǐn)?shù)據(jù)庫系統(tǒng)的隔離級別都是 READ-COMMITTED(讀取提交內(nèi)容) ，但是你要知道的是InnoDB 存儲引擎默認(rèn)使用 REPEATABLE-READ（可重讀） 并不會有任何性能損失淹办。

InnoDB 存儲引擎在 分布式事務(wù) 的情況下一般會用到 SERIALIZABLE(可串行化) 隔離級別眉枕。

10. 鎖機(jī)制與InnoDB鎖算法

10.1 MyISAM和InnoDB存儲引擎使用的鎖

• MyISAM采用表級鎖(table-level locking)。
• InnoDB支持行級鎖(row-level locking)和表級鎖,默認(rèn)為行級鎖

10.2 表級鎖和行級鎖對比

• 表級鎖： MySQL中鎖定粒度最大的一種鎖，對當(dāng)前操作的整張表加鎖速挑，實(shí)現(xiàn)簡單谤牡，資源消耗也比較少，加鎖快姥宝，不會出現(xiàn)死鎖翅萤。其鎖定粒度最大，觸發(fā)鎖沖突的概率最高腊满，并發(fā)度最低套么，MyISAM和 InnoDB引擎都支持表級鎖。
• 行級鎖： MySQL中鎖定粒度最小的一種鎖碳蛋，只針對當(dāng)前操作的行進(jìn)行加鎖胚泌。 行級鎖能大大減少數(shù)據(jù)庫操作的沖突。其加鎖粒度最小肃弟，并發(fā)度高玷室，但加鎖的開銷也最大，加鎖慢笤受，會出現(xiàn)死鎖穷缤。

10.3 InnoDB存儲引擎的鎖的算法有三種

• Record lock：單個行記錄上的鎖
• Gap lock：間隙鎖，鎖定一個范圍箩兽，不包括記錄本身
• Next-key lock：record+gap鎖定一個范圍津肛，包含記錄本身

關(guān)于鎖的相關(guān)知識點(diǎn)

1. innodb對于行的查詢使用next-key lock
2. Next-locking keying為了解決Phantom Problem幻讀問題
3. 當(dāng)查詢的索引含有唯一屬性時，將next-key lock降級為record key
4. Gap鎖設(shè)計(jì)的目的是為了阻止多個事務(wù)將記錄插入到同一范圍內(nèi)汗贫，而這會導(dǎo)致幻讀問題的產(chǎn)生
5. 有兩種方式顯式關(guān)閉gap鎖：（除了外鍵約束和唯一性檢查外快耿，其余情況僅使用record lock）
   A. 將事務(wù)隔離級別設(shè)置為RC (READ-COMMITTED)
   B. 將參數(shù)innodb_locks_unsafe_for_binlog設(shè)置為1

11. 大表優(yōu)化

當(dāng)MySQL單表記錄數(shù)過大時，數(shù)據(jù)庫的CRUD性能會明顯下降芳绩，一些常見的優(yōu)化措施如下：

1. 限定數(shù)據(jù)的范圍
   務(wù)必禁止不帶任何限制數(shù)據(jù)范圍條件的查詢語句掀亥。
2. 讀/寫分離
   經(jīng)典的數(shù)據(jù)庫拆分方案，主庫負(fù)責(zé)寫妥色，從庫負(fù)責(zé)讀搪花；
3. 垂直分區(qū)
   根據(jù)數(shù)據(jù)庫里面數(shù)據(jù)表的相關(guān)性進(jìn)行拆分。 例如嘹害，用戶表中既有用戶的登錄信息又有用戶的基本信息撮竿，可以將用戶表拆分成兩個單獨(dú)的表，甚至放到單獨(dú)的庫做分庫笔呀。
   簡單來說垂直拆分是指數(shù)據(jù)表列的拆分幢踏，把一張列比較多的表拆分為多張表。

• 垂直拆分的優(yōu)點(diǎn)： 可以使得列數(shù)據(jù)變小许师，在查詢時減少讀取的Block數(shù)房蝉，減少I/O次數(shù)僚匆。此外，垂直分區(qū)可以簡化表的結(jié)構(gòu)搭幻，易于維護(hù)咧擂。
• 垂直拆分的缺點(diǎn)： 主鍵會出現(xiàn)冗余，需要管理冗余列檀蹋，并會引起Join操作松申，可以通過在應(yīng)用層進(jìn)行Join來解決。此外俯逾，垂直分區(qū)會讓事務(wù)變得更加復(fù)雜贸桶；

4. 水平分區(qū)
   保持?jǐn)?shù)據(jù)表結(jié)構(gòu)不變，通過某種策略存儲數(shù)據(jù)分片桌肴。這樣每一片數(shù)據(jù)分散到不同的表或者庫中皇筛，達(dá)到了分布式的目的。水平拆分可以支撐非常大的數(shù)據(jù)量识脆。
   水平拆分可以支持非常大的數(shù)據(jù)量。需要注意的一點(diǎn)是：分表僅僅是解決了單一表數(shù)據(jù)過大的問題善已，但由于表的數(shù)據(jù)還是在同一臺機(jī)器上灼捂，其實(shí)對于提升MySQL并發(fā)能力沒有什么意義，所以水平拆分最好分庫 换团。
   水平拆分能夠支持非常大的數(shù)據(jù)量存儲悉稠，應(yīng)用端改造也少，但分片事務(wù)難以解決 艘包，跨節(jié)點(diǎn)Join性能較差的猛，邏輯復(fù)雜∠牖ⅲ《Java工程師修煉之道》的作者推薦盡量不要對數(shù)據(jù)進(jìn)行分片卦尊，因?yàn)椴鸱謺磉壿嫛⒉渴鹕喑⑦\(yùn)維的各種復(fù)雜度岂却，一般的數(shù)據(jù)表在優(yōu)化得當(dāng)?shù)那闆r下支撐千萬以下的數(shù)據(jù)量是沒有太大問題的。如果實(shí)在要分片裙椭，盡量選擇客戶端分片架構(gòu)躏哩，這樣可以減少一次和中間件的網(wǎng)絡(luò)I/O。

下面補(bǔ)充一下數(shù)據(jù)庫分片的兩種常見方案：

• 客戶端代理： 分片邏輯在應(yīng)用端揉燃，封裝在jar包中扫尺，通過修改或者封裝JDBC層來實(shí)現(xiàn)。 當(dāng)當(dāng)網(wǎng)的 Sharding-JDBC 炊汤、阿里的TDDL是兩種比較常用的實(shí)現(xiàn)正驻。
• 中間件代理： 在應(yīng)用和數(shù)據(jù)中間加了一個代理層弊攘。分片邏輯統(tǒng)一維護(hù)在中間件服務(wù)中。 我們現(xiàn)在談的 Mycat 拨拓、360的Atlas肴颊、網(wǎng)易的DDB等等都是這種架構(gòu)的實(shí)現(xiàn)。

垂直分區(qū)與水平分區(qū)

12. 解釋一下什么是池化設(shè)計(jì)思想渣磷。什么是數(shù)據(jù)庫連接池?為什么需要數(shù)據(jù)庫連接池?

池化設(shè)計(jì)會初始預(yù)設(shè)資源婿着，解決的問題就是抵消每次獲取資源的消耗，如創(chuàng)建線程的開銷醋界，獲取遠(yuǎn)程連接的開銷等竟宋。除了初始化資源，池化設(shè)計(jì)還包括如下這些特征：池子的初始值形纺、池子的活躍值丘侠、池子的最大值等，這些特征可以直接映射到j(luò)ava線程池和數(shù)據(jù)庫連接池的成員屬性中逐样。

數(shù)據(jù)庫連接本質(zhì)就是一個 socket 的連接蜗字。數(shù)據(jù)庫服務(wù)端還要維護(hù)一些緩存和用戶權(quán)限信息之類的 所以占用了一些內(nèi)存。我們可以把數(shù)據(jù)庫連接池是看做是維護(hù)的數(shù)據(jù)庫連接的緩存脂新，以便將來需要對數(shù)據(jù)庫的請求時可以重用這些連接挪捕。為每個用戶打開和維護(hù)數(shù)據(jù)庫連接，尤其是對動態(tài)數(shù)據(jù)庫驅(qū)動的網(wǎng)站應(yīng)用程序的請求争便，既昂貴又浪費(fèi)資源级零。在連接池中，創(chuàng)建連接后滞乙，將其放置在池中奏纪，并再次使用它，因此不必建立新的連接斩启。如果使用了所有連接序调，則會建立一個新連接并將其添加到池中。 連接池還減少了用戶必須等待建立與數(shù)據(jù)庫的連接的時間兔簇。

13. 分庫分表之后,id 主鍵如何處理炕置？

分庫分表之后，我們需要全局唯一的id來支持男韧。

• UUID：不適合作為主鍵朴摊，因?yàn)樘L了，并且無序不可讀此虑，查詢效率低甚纲。比較適合用于生成唯一的名字的標(biāo)示比如文件的名字。
• 數(shù)據(jù)庫自增 id : 兩臺數(shù)據(jù)庫分別設(shè)置不同步長朦前，生成不重復(fù)ID的策略來實(shí)現(xiàn)高可用介杆。這種方式生成的 id 有序鹃操，但是需要獨(dú)立部署數(shù)據(jù)庫實(shí)例，成本高春哨，還會有性能瓶頸荆隘。
• 利用 redis 生成 id : 性能比較好，靈活方便赴背，不依賴于數(shù)據(jù)庫椰拒。但是，引入了新的組件造成系統(tǒng)更加復(fù)雜凰荚，可用性降低燃观，編碼更加復(fù)雜，增加了系統(tǒng)成本便瑟。
• Twitter的snowflake算法
• 美團(tuán)的Leaf分布式ID生成系統(tǒng) ：Leaf 是美團(tuán)開源的分布式ID生成器缆毁，能保證全局唯一性、趨勢遞增到涂、單調(diào)遞增脊框、信息安全，里面也提到了幾種分布式方案的對比践啄，但也需要依賴關(guān)系數(shù)據(jù)庫浇雹、Zookeeper等中間件。

14. 一條sql語句在Mysql之中是怎么執(zhí)行的?

這部分請參考: http://www.reibang.com/p/a593641fdba9

15. 一條SQL語句執(zhí)行的很慢的原因

這部分請參考: http://www.reibang.com/p/b94f4b63c4a7

16. 關(guān)于數(shù)據(jù)庫存儲時間的思考

這部分請參考: http://www.reibang.com/p/bea57a239741