1.MySQL解決幻讀問題
MySQL InnoDB通過版本號解決事務(wù)的幻讀問題
a.select情況：
InnoDB只會查找版本高于當(dāng)前事務(wù)版本的數(shù)據(jù)行（即行的系統(tǒng)版本小于或等于事務(wù)的系統(tǒng)版本號）竭钝，這樣確保了事務(wù)讀取的行是當(dāng)前事務(wù)開始之前已經(jīng)存在的行，或者是事務(wù)自己自身插入或者修改的行。
b.insert情況：
InnoDB為新插入的每一行記錄保存當(dāng)前系統(tǒng)的版本號作為行版本號兆解。
c.delete情況：
InnoDB為刪除的每一行記錄保存當(dāng)前系統(tǒng)的版本號作為行刪除標(biāo)示蛛砰。
d.update情況：
InnoDB為新插入的每一行記錄保存當(dāng)前系統(tǒng)的版本號作為行版本號散庶，同時保存當(dāng)前系統(tǒng)版本號到原來的行作為行刪除標(biāo)示抛蚤。
2.MySQL不走索引的情況
1.使用like '%abc'宝冕；
2.where 中的or不是所有字段都是索引字段旧蛾；
3.組合索引莽龟，不包含第一個字段的查詢；
4.子查詢中order by的索引會失效锨天，同時可能導(dǎo)致子查詢中的where條件索引都不能用毯盈；
5.列類型為字符串類型，查詢時沒有用單引號引起來病袄；
6.在where查詢語句中使用表達(dá)式或者函數(shù)搂赋；
7.在where查詢語句中對字段進(jìn)行NULL值判斷；
8.DATE_FORMAT()格式化時間益缠，格式化后的時間再去比較脑奠，可能會導(dǎo)致索引失效。
3.B+樹的優(yōu)點(diǎn)
1.從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的搜索效率基本相同幅慌，不會出現(xiàn)大幅波動宋欺；
2.方便順序掃描，只需要遍歷所有葉子節(jié)點(diǎn)即可；
3.磁盤讀寫代價低齿诞，因?yàn)榉侨~子節(jié)點(diǎn)不保存行數(shù)據(jù)酸休，同一個數(shù)據(jù)塊，非葉子節(jié)點(diǎn)保存的關(guān)鍵字?jǐn)?shù)據(jù)量比B樹要高很多祷杈，因此一次讀入的關(guān)鍵字也就越多斑司，降低了IO次數(shù)；
4.B+樹支持范圍查詢吠式，而B樹對范圍查詢支持性很差陡厘。
4.MySQL自增主鍵
優(yōu)點(diǎn)：
1.插入效率高，每次插入新的記錄特占，記錄會順序的添加到當(dāng)前索引節(jié)點(diǎn)的后續(xù)位置糙置，當(dāng)前頁寫滿后，自動開辟新的一頁是目；
2.節(jié)省索引存儲空間谤饭，技術(shù)是UUID的兩倍；
3.使用UUID(Universally Unique Identifier)主鍵的時候懊纳，每次插入主鍵時揉抵，插入的索引中的位置幾乎隨機(jī)，會導(dǎo)致非葉子節(jié)點(diǎn)的分裂嗤疯，MySQL不得不為了插入新紀(jì)錄而移動數(shù)據(jù)冤今，，甚至導(dǎo)致磁盤IO和不飽和的節(jié)點(diǎn)茂缚，造成大量的碎片戏罢，甚至觸發(fā)optimize table重建表來優(yōu)化。
缺點(diǎn)：
1.不適合分表脚囊、分庫和分布式的場景龟糕。這些場景只能犧牲性能，使用UUID悔耘，但是UUID適合小規(guī)模的分布式環(huán)境讲岁，不適合大規(guī)模的分布式環(huán)境，特別數(shù)據(jù)量大時衬以，UUID帶來的讀寫性能的下降很厲害缓艳。
Twitter為解決分布式自增ID的問題，給出了snowflake雪花算法來實(shí)現(xiàn)全局自增ID泄鹏，這樣ID的生成不依賴于DB郎任，而是依賴于內(nèi)存，高性能高可用备籽。但是snowflake算法依賴于系統(tǒng)時鐘的一致性，如果機(jī)器的時鐘回?fù)埽赡軙?dǎo)致ID沖突车猬。
