mysql中的事務
mysql默認採用自動提交模式，也就是說，如果不是明顯地開始一個事務，每個查詢都會被當做一個事務執行提交操作，在當前連接中，可以通過設置AUTOCOMMIT變量來啓動或者禁用自動提交模式，1表示啓動。
事務的ACID特性
事務的原子性是指事務內的語句要麼全部執行，要麼全部執行失敗。
事務的一致性是指數據庫總是從一個一致性的狀態轉移到另外一個一致性的狀態。
事務的隔離性是指一個事務在最終提交以前，對其他的事務是不可見的。
事務的持久性是指一旦事務被提交，則其所做的修改會永久保存到數據庫中
事務的隔離級別
未提交讀（Read Uncommitted）
讀寫均不使用鎖，數據的一致性最差，也會出現許多邏輯錯誤。在未提交讀級別中，事務中的修改，沒有提交，對其他事務也都是可見的，事務可以讀取未提交的數據，造成髒讀。
提交讀（Read Committed）
使用寫鎖，但是讀會出現不一致，造成不可重複讀（兩次讀取不一致）。提交讀是大多數數據庫系統默認的隔離級別，但MySQL不是，具體是指一個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的。 舉例說明就是對於一個數A由50修改成100，另一個事務在A提交修改之前，讀取到了A是50，剛讀取完，A就被修改成了100，再次讀取就變成100。
可重複讀（Repeatable Read）
使用讀鎖和寫鎖，解決不可重複讀的問題，但會有幻讀，幻讀是指當某個事務在讀取某個範圍內的記錄時另外一個事務又在該範圍內插入了新的記錄，當之前的事務再次讀取該範圍的記錄時，會產生幻行。InnoDB通過加間隙鎖的方式解決了幻讀的問題。間隙鎖就是鎖住了所有的行避免其他的事務改變A 中的變量。總結來說就是在可重複讀的隔離級別下存在幻讀的可能性，但是MySQL的InnoDB通過加間隙鎖的方式解決了幻讀。MySQL引擎的默認級別是可重複讀。
可串行化（Serializable）
可串行化是最高的隔離級別，它通過強制事務串行執行，避免了前面說的幻讀的問題，簡單說就是可串行化會在每一行的數據上都加鎖，所以可能導致大量的超時和鎖爭用的問題。
| 隔離級別 | 髒讀可能性 | 不可重複讀可能性 | 幻讀可能性 |
|---|---|---|---|
| 未提交讀 | YES | YES | YES |
| 提交讀 | NO | YES | YES |
| 可重複讀 | NO | NO | YES |
| 串行化 | NO | NO | NO |
索引
索引一般是放在磁盤中的，索引是存儲引擎用於快速找到記錄的一種數據結構。索引優化應該是對查詢優化最有效的手段了。索引能夠輕易將查詢性能提高几個數量級，創建一個最優的索引經常需要重寫查詢。索引可以包含一個或多個列的值，如果索引包含多個列，那麼列的順序也十分重要，因爲MySQL只能高效地使用索引的最左前綴。創建一個包含兩個列的索引，和創建兩個包含只包含一列的索引是大不相同的。
B+Tree索引
B+Tree索引是使用B+Tree數據結構來存儲數據。存儲引擎以不同的方式使用B+Tree索引，性能也各有不同，各有優劣。例如，MyISAM使用前綴壓縮技術使得索引更小，InnoDB則按照原數據格式進行存儲。再如MyISAM索引通過數據的物理位置引用被索引的行，而InnoDB則根據主鍵引用被索引的行。B+Tree索引之所以能夠加快訪問數據的速度，因爲存儲引擎不再需要進行全表掃描來獲取需要的數據，取而代之的是從索引的根節點開始進行搜索。根節點的槽中存放了指向子節點的指針，存儲引擎根據這些指針向下層查找。葉子節點比較特別，它們的指針指向的是被索引的數據，而不是其他的節點頁。B+Tree對索引列是按照順序組織存儲的，所以適合查找範圍數據。例如，在一個基於文本域的索引樹上，按字母順序傳遞連續的值進行查找是非常合適的，所以像“找出所有以I到K開頭的名字”這樣的查找效率會非常。索引對多個值進行排序的依據是CREATE TABLE語句中定義索引時列的順序。B+Tree索引適應於全鍵值、鍵值範圍或鍵前綴查找。其中鍵前綴查找只適用於根據最左前綴的查找。
B+Tree索引特性
•全值匹配全值匹配指的是和索引中所有的列進行匹配
•匹配最左前綴指的是和索引中第一列進行匹配
•匹配列前綴指的是隻匹配某一列的值的開頭部分
•匹配範圍值指的是匹配某一列的範圍
•精確匹配某一列並範圍匹配另外一列精確匹配是指某一列的值已知，再範圍匹配另一列
•只訪問索引的查詢B-Tree通常可以支持“只訪問索引的查詢”，即查詢只需要訪問索引，而無需訪問數據行。這種又稱爲“覆蓋索引”。
•索引樹中的節點是有序的，所以除了按值查找以外，所以還有可以擁有查詢中ORDER BY操作。
下面是一些關於B+Tree索引的限制：
•如果不是按照索引的最左列開始查找，則無法使用索引。
•不能跳過索引的列。
•如果查詢中有某個列的範圍查詢，則其右邊所有列都無法使用索引優化查詢。
索引的順序非常重要，這些限制都和索引的順序有關。在性能優化的時候，可能需要使用相同的列但順序不同的索引來滿足不同類型的查詢需求。
爲什麼選用B+樹作爲索引的底層結構（B+樹比B樹好在哪裏，比哈希好在哪裏）
B+樹的特性是在B樹的基礎上進行改造。
B樹是一個多路搜索樹（多路排序樹），每個節點都可以擁有多（M）個孩子節點，設計成多路是爲了降低樹的高度，減少查詢時間。索引是存放在磁盤的，內存讀取磁盤中的數據，內存是個瘦子一次只能讀取很少的數據，先讀取B樹的根節點，在接着往下讀取，直到找到那個值。
B+樹葉子節點存儲數據且葉子節點之間還加了指針形成鏈表，查找與樹的高度有關，哈希查找的時間爲O(1)。在實際的業務場景中，一般是一次性查詢多條有序數據。比如說要查詢最後10條id的數據，這時B+樹存儲的數據都是有序的，這種情況下B+樹的查詢效率比哈希要快。