過去我對MySQL不夠重視，僅停留在應用階段，對原理和優化不求甚解，這種拿來主義在數據庫引擎和索引方面尤爲明顯，是眼界限制了我的想法。幸運的是得到兩位前輩的及時指出，我感覺距離成爲一名高水平的研發人員又更進一步。這兩天經過幾番查閱資料，這個知識盲區正在被照亮，但是這僅停留在理論知識，還需要更加開闊的眼界看問題，還需要更多的實踐在實驗中驗證想法，最終在實踐中完成知識的吸收內化。
參考書籍《MySql技術內幕 InnoDb存儲引擎》 第五章 索引與算法
數據庫引擎的區別。
答：
MyISAM：高速查詢及插入。擅長插入和查詢，不支持事務。
Innodb ：數據完整性，併發性處理，擅長更新，刪除，支持事務。
MyISAM強調性能，而Innodb強調安全。
爲什麼Innodb適合擅長更新和刪除而MyISAM擅長插入和查詢？
答：
前者Innodb擅長處理併發的。
因爲它使用了行級鎖定，只該行鎖了，其它行沒有鎖，
把數據和索引存放在表空間裏面。
後者MyISAM擅長高速讀與寫。
因爲它本身是一種文件系統，是索引順序存取方法的縮寫，
索引文件和數據文件是分離，維護索引效率高。
數據和索引各種獨立表空間和共享表空間的優缺點。
答:
獨立的優點：
維護索引的效率高，
碎片化不明顯，可回縮不用的空間。
共享的缺點：
建立索引並且大量刪除記錄後，共享表空間不能回縮。
共享的優點：
管理方便，如：分表操作方便。
獨立的缺點：
庫中表數量多時，難以拆庫拆表。
索引有哪些？
答：
按功能分有：
主鍵索引、唯一索引、普通索引、聯合索引
按搜索引擎分類：
hash索引、btree索引（二分叉算法）
索引爲什麼會快？
答：
沒有索引時，查找記錄會按主鍵從頭到尾掃描，
需要掃描N行，時間複雜度O(n)。
有索引時，索引分3種，hash，btree，全文。
hash查找時，直接定位到記錄的主鍵，時間複雜度O(1)。
二分查找時，因爲B+樹的高度一般都在2-4層，
最多只需要2-4次IO，效率也比較可供。
全文檢索用了反向索引，假如關鍵字被收錄，時間複雜度O(1)。
若關鍵字沒收錄，則根據最左前綴匹配來查找。
若記錄大量重複，建立索引會有什麼問題？
答：建索引先要考慮區分度，這種情況下會有性能問題，
反面教材舉例：給性別字段建立普通索引。
將導致普通索引和聚集索引中來回切換，總開銷大。
從索引中拿到的只是地址，要想真正訪問到數據還是要對錶進行一次IO。
如果是從10行數據中取5行數據，相當於訪問5次索引，再訪問5次表，
加起來的開銷並不會比直接對錶進行一次完整掃描小。
爲什麼varchar不適合建立索引？
答:
區別性能的是採用哪種索引方式，
而不是索引的數據類型。
若採用hash作爲索引，效率不會降低。
若採用btree索引，維護索引很可能會消耗大量性能。
這種非單調的字段在插入新記錄時，
數據文件爲了維持B+Tree的特性而頻繁的分裂調整，
在某些情況下會十分低效，不過也有改善的辦法，
可以使用短索引，計算最大的辨識度M=m/q，
比如說前5位近似是唯一的，
那麼就不要對整個列進行索引。
存了很多IP到數據庫中，可能重複，如何取出最高效？
答：
1.給IP建立普通索引，大部分人都能想到。
2.點分法IP轉十進制數值類型，使用int UNSIGNED類型存儲更高效。
3.若不需要模糊查詢，啓用自適應hash索引。（針對Innodb）
4.若IP前綴相同導致區分度不高，
但是又需要按區間取出可考慮多列索引。
5.考慮是否可以覆蓋索引查詢。
6.字段參與的表達中，保證字段獨立在運算符一側。
7.若需要模糊查詢，左邊不要以通配符開頭。
在查詢上，有什麼高效的技巧或注意事項？
答：
建複合索引時，區別度最高在最左邊。
多判斷條件查詢時，等號的條件放最左邊。
使用覆蓋索引來進行查詢，避免回表。
索引文件有最左前綴匹配特性，避免使用左模糊或全模糊。
如何高效查詢一個時間段的記錄？
答：
1.建立索引可以加快查詢速度
2.時間類型datetime,
時間戳考慮用數值類型int(11)
3.使用BETWEEN-AND，索引建立後，可以用索引掃描提高了查詢的效率。
4.不要使用數據庫函數，會導致無法使用索引。
不走索引可能的情況有哪些？
答：
1.函數操作
2.隱式轉換
3.模糊查詢
4.範圍查詢
5.計算操作
全文索引是什麼原理？
答：
過去只有MyISAM支持全文索引，現在Innodb也支持全文索引。
但是不支持沒有單詞界定符的語言，如中日韓文。
需要安裝sphinx等搜索引擎支持全文索引。
原理是使用倒排索引，
innodb會把單詞拆分進行存儲，查找時，根據單詞匹配。
這裏頗有搜索引擎的味道，
但是僅僅是精確的查詢方式，
lucene等搜索引擎更擅長分詞並且捨去了事務、
訪問控制以及可能遺漏的一小部分記錄（文檔），
換取來快速的搜索響應。
數據庫優化技能還有哪些？
答：
較頻繁的作爲查詢條件的字段應該創建索引
唯一性太差的字段不適合單獨創建索引，即使頻繁作爲查詢條件
更新非常頻繁的字段不適合創建索引
不會出現在 WHERE 子句中的字段不該創建索引