講爛了的mysql，今天再給你們重溫一下

mysql事務：

MySQL 事務主要用於處理操做量大，複雜度高的數據。好比說，在人員管理系統中，你刪除一我的員，你既須要刪除人員的基本資料，也要刪除和該人員相關的信息，如信箱，文章等等，這樣，這些數據庫操做語句就構成一個事務！

• 在 MySQL 中只有使用了 Innodb 數據庫引擎的數據庫或表才支持事務。• 事務處理能夠用來維護數據庫的完整性，保證成批的 SQL 語句要麼所有執行，要麼所有不執行。• 事務用來管理 insert,update,delete 語句通常來講，事務是必須知足4個條件（ACID）：：原子性（Atomicity，或稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。• 原子性：一個事務（transaction）中的全部操做，要麼所有完成，要麼所有不完成，不會結束在中間某個環節。事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。• 一致性：在事務開始以前和事務結束之後，數據庫的完整性沒有被破壞。這表示寫入的資料必須徹底符合全部的預設規則，這包含資料的精確度、串聯性以及後續數據庫能夠自發性地完成預約的工做。• 隔離性：數據庫容許多個併發事務同時對其數據進行讀寫和修改的能力，隔離性能夠防止多個事務併發執行時因爲交叉執行而致使數據的不一致。事務隔離分爲不一樣級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（Serializable）。• 持久性：事務處理結束後，對數據的修改就是永久的，即使系統故障也不會丟失

mysql索引：

MySQL索引的創建對於MySQL的高效運行是很重要的，索引能夠大大提升MySQL的檢索速度。打個比方，若是合理的設計且使用索引的MySQL是一輛蘭博基尼的話，那麼沒有設計和使用索引的MySQL就是一我的力三輪車。拿漢語字典的目錄頁（索引）打比方，咱們能夠按拼音、筆畫、偏旁部首等排序的目錄（索引）快速查找到須要的字。索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表能夠有多個單列索引，但這不是組合索引。組合索引，即一個索引包含多個列。建立索引時，你須要確保該索引是應用在 SQL 查詢語句的條件(通常做爲 WHERE 子句的條件)。實際上，索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄。上面都在說使用索引的好處，但過多的使用索引將會形成濫用。所以索引也會有它的缺點：雖然索引大大提升了查詢速度，同時卻會下降更新表的速度，如對錶進行INSERT、UPDATE和DELETE。由於更新表時，MySQL不只要保存數據，還要保存一下索引文件。創建索引會佔用磁盤空間的索引文件。

索引的數據結構

上面講了索引的基本原理，數據庫的複雜性，以及操做系統的一些內容，目的就是讓你們瞭解到，任何一種數據結構都不是憑空產生的，必定有它的背景和使用場景。那麼，咱們須要這些數據結構可以作什麼呢？其實很簡單，就是：每次查找數據的時候，把磁盤I/O次數限制在一個很小的數量級，最好是一個常量數量級。那麼咱們就想到，若是一個高度可控的多路搜索樹，是否可以知足需求呢？在這樣的背景下，B+樹應運而生。

詳解B+樹

如上圖，是一棵B+樹。B+樹的定義，童鞋能夠自行百度，咱們只說一些重點。圖中淺藍色的塊，咱們稱之爲一個磁盤，能夠看到，每一個磁盤塊包含幾個數據項（深藍色）和指針（黃色）。如：磁盤塊1包含數據17和數據35，包含指針P1,P2,P3，P1指向數據小於17的磁盤塊，P2指向數據在17到35之間的數據所在磁盤塊，P3指向數據大於35的數據所在的磁盤塊。真實數據存在於葉子節點，即3，5，9，10，13，15，28，29，36，60，75，79，90，99 。非葉子節點不存儲真實數據，只存儲指引搜索方向的數據項，如1七、35並不真實存在於數據表中。

B+樹的查找過程

仍是使用上面的B+樹。假設，咱們要查找數據項29，那麼咱們首先會把磁盤塊1由磁盤加載到內存中，此時進行了一次I/O，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存計算時間因爲很是短（對比於I/O）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址指向磁盤塊3，由磁盤加載到內存，此時進行了第二次I/O，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，此時進行了第三次I/O，同時內存中計算二分查找找到29，查詢結束。這一過程，一共進行了3次I/O。在真實使用場景中，三層的B+樹能夠表示上百萬的數據，若是上百萬的數據查詢只須要三次I/O，性能提升將會是巨大的。B+樹就是一種索引數據結構，若是沒有這樣的索引，每一個數據項發生一次I/O，那麼成本將會大大提高。

B+樹的性質

在上面的查找例子中，咱們能夠分析出一些B+樹的性質：

1，I/O的次數取決於B+樹的高度H，假設當前數據表的數據爲N，每一個磁盤塊的數據項的數量是M，則有：H=log(M+1)N，當數據量N必定的狀況下，M越大，H越小；而M=磁盤塊大小/數據項大小，磁盤塊大小也就是一個數據頁的大小，是固定的，若是數據項佔的空間越小，數據項的數量越多，樹的高度也就越低。這也就是爲何每一個數據項，即索引字段要儘可能的小，好比int佔4個字節，要比bigint的8個字節小一半。這也是爲何B+樹要求把真實數據放在葉子節點內而不是內層節點內，一旦放到內層節點內，磁盤塊的數據項會大幅度的降低，致使樹層級的增高。當數據項爲1時，B+樹會退化成線性表。

2，B+樹的數據項是複合性數據結構，好比（name，age，gender）的時候，B+樹是按照從左到右的順序來創建搜索樹的，好比當（小張，22，女）這樣的數據來檢索的時候，B+樹會優先比較name來肯定下一步的搜索方向，若是name相同再依次比較age和gender，最後獲得檢索的數據。可是，當（22，女）這樣沒有name的數據來的時候，B+樹就不知道下一步該查哪一個節點，由於創建搜索樹的時候，name就是第一個比較因子，必須根據name來搜索才知道下一步去哪裏查詢。好比，當（小張，男）這樣的數據來檢索時，B+樹就能夠根據name來指定搜索方向，但下一字段age缺失，因此只能把名字是「小張」的全部數據都找到，而後再匹配性別是「男」的數據了。這個是很是重要的一條性質，即索引的最左匹配特性。

索引的類型

在MySQL中，索引分爲兩大類：聚簇索引和非聚簇索引。聚簇索引是按照數據存放的物理位置爲順序的，而非聚簇索引則不一樣；聚簇索引可以提升多行檢索的速度，而非聚簇索引則對單行的檢索速度很快。

在這兩大類的索引類型下，還能夠將索引分紅四個小類：

1，普通索引：最基本的索引，沒有任何限制，是咱們大多數狀況下使用到的索引。

2，惟一索引：與普通索引類型，不一樣的是惟一索引的列值必須惟一，但容許爲空值。

3，全文索引：全文索引（FULLTEXT）僅能夠適用於MyISAM引擎的數據表；做用於CHAR、VARCHAR、TEXT數據類型的列。

4，組合索引：將幾個列做爲一條索引進行檢索，使用最左匹配原則。

創建索引的原則

咱們回頭來看一開始提到的慢查詢，當咱們瞭解完索引原理以後，對慢查詢的優化應該有一些想法，這裏咱們先總結一下創建索引的一些原則：

1，最左前綴匹配原則。這是很是重要、很是重要、很是重要（重要的事情說三遍）的原則，MySQL會一直向右匹配直到遇到範圍查詢（>,<,BETWEEN,LIKE）就中止匹配，好比：a = 1 AND b = 2 AND c > 3 AND d = 4，若是創建 （a,b,c,d）順序的索引，d是用不到索引的，若是創建（a,b,d,c）的索引，則均可以用到，a,b,d的順序能夠任意調整。

2，等於（=）和in 能夠亂序。好比，a = 1 AND b = 2 AND c = 3 創建（a,b,c）索引能夠任意順序，MySQL的查詢優化器會幫你優化成索引能夠識別的模式。

3，儘可能選擇區分度高的列做爲索引，區分度的公式是 COUNT(DISTINCT col) / COUNT(*)。表示字段不重複的比率，比率越大咱們掃描的記錄數就越少，惟一鍵的區分度是1，而一些狀態、性別字段可能在大數據面前區分度是0。可能有人會問，這個比率有什麼經驗麼？使用場景不一樣，這個值也很難肯定，通常須要JOIN的字段咱們要求在0.1以上，即平均1條掃描10條記錄。

4，索引列不能參與計算，儘可能保持列「乾淨」。好比，FROM_UNIXTIME(create_time) = ‘2016-06-06’ 就不能使用索引，緣由很簡單，B+樹中存儲的都是數據表中的字段值，可是進行檢索時，須要把全部元素都應用函數才能比較，顯然這樣的代價太大。因此語句要寫成 ：create_time = UNIX_TIMESTAMP(‘2016-06-06’)。

5，儘量的擴展索引，不要新創建索引。好比表中已經有了a的索引，如今要加（a,b）的索引，那麼只須要修改原來的索引便可。

6，單個多列組合索引和多個單列索引的檢索查詢效果不一樣，由於在執行SQL時，MySQL只能使用一個索引，會從多個單列索引中選擇一個限制最爲嚴格的索引。

根據上面這些原則，咱們來修改開篇的慢查詢：

SELECTcount(*) AS countFROM trade_bASe AS aWHEREa.trade_status = 7 AND a.create_time BETWEEN '2015-09-01' AND '2016-01-14' AND a.booking_source = '2'

根據這條SQL，應該創建的索引是：trade_status, booking_source,create_time的聯合索引；其中，trade_status、booking_source的順序能夠顛倒，並且 create_time 的區間查詢放到後面。這就是利用了索引的最左匹配原則。這一點和oracle恰好相反，oracle是從右到左

慢查詢的優化步驟

1，查看運行效果，是否真的很慢，主要設置SQL_NO_CACHE。

2，WHERE條件單表查詢，鎖定最小返回記錄表。這句話的意思是，把查詢語句的WHERE都應用到表中返回的記錄數最小的表開始查起，單表每一個字段分別查詢，看哪一個字段的區分度最高

3，EXPLAIN查看執行計劃，是否與1預期一致（從鎖定記錄較少的表開始查詢）

4，ORDER BY LIMIT 形式的SQL語句，讓排序的表優先查

5，多去了解業務的使用場景

6，加索引時，要參照創建索引的幾大原則

7，觀察結果，不符合預期，則從新從1開始分析。

索引的優化方法

1，什麼時候使用聚簇索引或非聚簇索引：

2，索引不會包含有NULL值的列：只要列中包含有NULL值，都將不會被包含在索引中，組合索引中只要有一列有NULL值，那麼這一列對於此條組合索引就是無效的。因此咱們在數據庫設計時，不要讓索引字段的默認值爲NULL。

3，使用短索引：假設，若是有一個數據類型爲CHAR(255)的列，在前10個或20個字符內，絕大部分數據的值是惟一的，那麼就不要對整個列進行索引。短索引不只能夠提升查詢速度並且能夠節省I/O操做。

4，索引列排序：MySQL查詢只使用一個索引，所以若是WHERE子句中已經使用了索引的話，那麼ORDER BY中的列是不會使用索引的。所以數據庫默認排序能夠符合要求的狀況下，不要使用排序操做；儘可能不要包含多個列的排序，若是須要，最好給這些列也建立組合索引。

5，LIKE語句操做：通常狀況下，不建議使用LIKE操做；若是非使用不可，如何使用也是一個研究的課題。LIKE 「%aaaaa%」不會使用索引，可是LIKE 「aaa%」卻可使用索引。

6，不要在索引列上進行運算：在創建索引的原則中，提到了索引列不能進行運算，這裏就再也不贅述了。

最後，總結一下，其實任何數據庫層面的優化，都抵不上應用系統的優化，一樣是MySQL，Facebook/Google等等均可以支撐，因此且行且珍惜吧！

前段時間，有個大佬面上了某大廠，送給我一批學習資料，整理出來，就造成了如下文檔（數據庫方面），主要包括MySQL面試題、MySQL基礎到高級到調優筆記、MySQL知識總結、MySQL性能調優與架構設計解析文檔，已打包好

添加小助手VX：xuanwo008便可獲取~

因爲篇幅字數緣由，在這隻展現詳細目錄及內容的截圖了，有須要的朋友添加小助手VX：xuanwo008便可獲取~