摘要：但是這將嚴重影響程序的性能。垂直分區的優點在于可以使得行數據變小，在查詢時減少讀取的數，減少次數。此外，垂直分區可以簡化表的結構，易于維護。垂直分區的缺點在于主鍵會出現冗余，需要管理冗余列，并會引起操作，可以通過在應用層進行來解決。

Java面試通關手冊（Java學習指南，歡迎Star，會一直完善下去，歡迎建議和指導）：https://github.com/Snailclimb/Java_Guide

書籍推薦

《高性能MySQL : 第3版》

文字教程推薦

MySQL 教程（菜鳥教程）

MySQL教程（易百教程）

視頻教程推薦

基礎入門： 與MySQL的零距離接觸-慕課網

Mysql開發技巧： MySQL開發技巧（一）　　MySQL開發技巧（二）　　MySQL開發技巧（三）

Mysql5.7新特性及相關優化技巧： MySQL5.7版本新特性　　性能優化之MySQL優化

MySQL集群（PXC）入門　　MyCAT入門及應用

常見問題總結

存儲引擎

MySQL常見的兩種存儲引擎：MyISAM與InnoDB的愛恨情仇

字符集及校對規則

字符集指的是一種從二進制編碼到某類字符符號的映射。校對規則則是指某種字符集下的排序規則。Mysql中每一種字符集都會對應一系列的校對規則。

Mysql采用的是類似繼承的方式指定字符集的默認值，每個數據庫以及每張數據表都有自己的默認值，他們逐層繼承。比如：某個庫中所有表的默認字符集將是該數據庫所指定的字符集（這些表在沒有指定字符集的情況下，才會采用默認字符集） PS：整理自《Java工程師修煉之道》

詳細內容可以參考： MySQL字符集及校對規則的理解

索引相關的內容（數據庫使用中非常關鍵的技術，合理正確的使用索引可以大大提高數據庫的查詢性能）

　　Mysql索引使用的數據結構主要有BTree索引和哈希索引。對于哈希索引來說，底層的數據結構就是哈希表，因此在絕大多數需求為單條記錄查詢的時候，可以選擇哈希索引，查詢性能最快；其余大部分場景，建議選擇BTree索引。

　　Mysql的BTree索引使用的是B數中的B+Tree，但對于主要的兩種存儲引擎的實現方式是不同的。

　　MyISAM: B+Tree葉節點的data域存放的是數據記錄的地址。在索引檢索的時候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然后以data域的值為地址讀取相應的數據記錄。這被稱為“非聚簇索引”。

　　InnoDB: 其數據文件本身就是索引文件。相比MyISAM，索引文件和數據文件是分離的，其表數據文件本身就是按B+Tree組織的一個索引結構，樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此InnoDB表數據文件本身就是主索引。這被稱為“聚簇索引（或聚集索引）”。而其余的索引都作為輔助索引，輔助索引的data域存儲相應記錄主鍵的值而不是地址，這也是和MyISAM不同的地方。在根據主索引搜索時，直接找到key所在的節點即可取出數據；在根據輔助索引查找時，則需要先取出主鍵的值，在走一遍主索引。 因此，在設計表的時候，不建議使用過長的字段作為主鍵，也不建議使用非單調的字段作為主鍵，這樣會造成主索引頻繁分裂。 PS：整理自《Java工程師修煉之道》

詳細內容可以參考：

干貨：mysql索引的數據結構

MySQL優化系列（三）--索引的使用、原理和設計優化

查詢緩存的使用

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

query_cache_type=1
query_cache_size=600000

Mysql執行以下命令也可以開啟查詢緩存

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

如上，開啟查詢緩存后在同樣的查詢條件以及數據情況下，會直接在緩存中返回結果。這里的查詢條件包括查詢本身、當前要查詢的數據庫、客戶端協議版本號等一些可能影響結果的信息。因此任何兩個查詢在任何字符上的不同都會導致緩存不命中。此外，如果查詢中包含任何用戶自定義函數、存儲函數、用戶變量、臨時表、Mysql庫中的系統表，其查詢結果也不會被緩存。

緩存建立之后，Mysql的查詢緩存系統會跟蹤查詢中涉及的每張表，如果這些表（數據或結構）發生變化，那么和這張表相關的所有緩存數據都將失效。

緩存雖然能夠提升數據庫的查詢性能，但是緩存同時也帶來了額外的開銷，每次查詢后都要做一次緩存操作，失效后還要銷毀。 因此，開啟緩存查詢要謹慎，尤其對于寫密集的應用來說更是如此。如果開啟，要注意合理控制緩存空間大小，一般來說其大小設置為幾十MB比較合適。此外，還可以通過sql_cache和sql_no_cache來控制某個查詢語句是否需要緩存：

select sql_no_cache count(*) from usr;

事務機制

關系性數據庫需要遵循ACID規則，具體內容如下：

原子性： 事務是最小的執行單位，不允許分割。事務的原子性確保動作要么全部完成，要么完全不起作用；

一致性： 執行事務前后，數據保持一致；

隔離性： 并發訪問數據庫時，一個用戶的事物不被其他事物所干擾，各并發事務之間數據庫是獨立的；

持久性: 一個事務被提交之后。它對數據庫中數據的改變是持久的，即使數據庫 發生故障也不應該對其有任何影響。

為了達到上述事務特性，數據庫定義了幾種不同的事務隔離級別：

READ_UNCOMMITTED（未授權讀取）: 最低的隔離級別，允許讀取尚未提交的數據變更，可能會導致臟讀、幻讀或不可重復讀

READ_COMMITTED（授權讀取）: 允許讀取并發事務已經提交的數據，可以阻止臟讀，但是幻讀或不可重復讀仍有可能發生

REPEATABLE_READ（可重復讀）: 對同一字段的多次讀取結果都是一致的，除非數據是被本身事務自己所修改，可以阻止臟讀和不可重復讀，但幻讀仍有可能發生。

SERIALIZABLE（串行）: 最高的隔離級別，完全服從ACID的隔離級別。所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止臟讀、不可重復讀以及幻讀。但是這將嚴重影響程序的性能。通常情況下也不會用到該級別。

這里需要注意的是：Mysql 默認采用的 REPEATABLE_READ隔離級別 Oracle 默認采用的 READ_COMMITTED隔離級別.

事務隔離機制的實現基于鎖機制和并發調度。其中并發調度使用的是MVVC（多版本并發控制），通過保存修改的舊版本信息來支持并發一致性讀和回滾等特性。

詳細內容可以參考： 可能是最漂亮的Spring事務管理詳解

鎖機制

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

MyISAM采用表級鎖(table-level locking)。

InnoDB支持行級鎖(row-level locking)和表級鎖,默認為行級鎖

表級鎖和行級鎖對比：

表級鎖： Mysql中鎖定 粒度最大 的一種鎖，對當前操作的整張表加鎖，實現簡單，資源消耗也比較少，加鎖快，不會出現死鎖。其鎖定粒度最大，觸發鎖沖突的概率最高，并發度最低，MyISAM和 InnoDB引擎都支持表級鎖。

行級鎖： Mysql中鎖定 粒度最小 的一種鎖，只針對當前操作的行進行加鎖。 行級鎖能大大減少數據庫操作的沖突。其加鎖粒度最小，并發度高，但加鎖的開銷也最大，加鎖慢，會出現死鎖。

詳細內容可以參考：
Mysql鎖機制簡單了解一下

大表優化

當MySQL單表記錄數過大時，數據庫的CRUD性能會明顯下降，一些常見的優化措施如下：

限定數據的范圍： 務必禁止不帶任何限制數據范圍條件的查詢語句。比如：我們當用戶在查詢訂單歷史的時候，我們可以控制在一個月的范圍內。；

讀/寫分離： 經典的數據庫拆分方案，主庫負責寫，從庫負責讀；

緩存： 使用MySQL的緩存，另外對重量級、更新少的數據可以考慮使用應用級別的緩存；

垂直分區： 根據數據庫里面數據表的相關性進行拆分。例如，用戶表中既有用戶的登錄信息又有用戶的基本信息，可以將用戶表拆分成兩個多帶帶的表，甚至放到多帶帶的庫做分庫。垂直分區的優點在于可以使得行數據變小，在查詢時減少讀取的Block數，減少I/O次數。此外，垂直分區可以簡化表的結構，易于維護。

垂直分區的缺點在于主鍵會出現冗余，需要管理冗余列，并會引起Join操作，可以通過在應用層進行Join來解決。此外，垂直分區會讓事務變得更加復雜；

水平分區： 保持數據表結構不變，通過某種策略存儲數據分片。這樣每一片數據分散到不同的表或者庫中，達到了分布式的目的。水品分區可以支持非常大的數據量。需要注意的一點是:分表僅僅是解決了單一表數據過大的問題，但由于表的數據還是在同一臺機器上，其實對于提升MySQL并發能力沒有什么意義，所以水品分區最好分庫。水品分區能夠支持非常大的數據量存儲，應用端改造也少，但分片事務難以解決，跨界點Join性能較差，邏輯復雜。《Java工程師修煉之道》的作者推薦盡量不要對數據進行分片，拆分會帶來邏輯、部署、運維的各種復雜度，一般的數據表在優化得當的情況下支撐千萬以下的數據量是沒有太大問題的。如果實在要分片，盡量選擇客戶端分片架構，這樣可以減少一次和中間件的網絡I/O。

詳細內容可以參考：
MySQL大表優化方案

歡迎關注我的微信公眾號:"Java面試通關手冊"（一個有溫度的微信公眾號，無廣告，單純技術分享，期待與你共同進步~~~堅持原創，分享美文，分享各種Java學習資源。)