MySQL5.7中InnoDB不可不知的新特性
大家好，首先非常感謝社群的引薦，讓我有機會在這裡跟廣大的DBA群友們交流。
今天的分享主要是針對MySQL5.7中InnoDB的新特性，InnoDB大家都應該非常熟悉，作為MySQL的儲存引擎，而且現在變成預設的儲存引擎，它為MySQL提供了強大的儲存支援。伴隨著MySQL從5.6演進到5.7，InnoDB 也有了一些新的變化。今天想跟大家分享的就是InnoDB在5.7中的這些變化。
我主要從效能和功能兩大方面來給大家介紹：
2、新功能（透明壓縮，加密，虛擬列等）
一、效能提升
首先，是效能方面。在5.7中，我的老闆（大牛）做了一個很重要的工作，就是對InnoDB的事務（transaction）進行了優化。
1、事務優化
在這方面他做的第一件事情就是建立事務池（Transaction Pool），這樣就能減少很多事務建立和釋放的開銷。
他做的第二件事情就是優化了事務的生命週期管理。所有事務首先都預設為是隻讀事務，這樣這些事務就不會和其他事務衝突，只有當此事務開始一個寫操作時才認為它是一個讀寫事務。
另外，對事務的優先順序也有了一些調整。
接下來我們看看經過這些修改之後，效能有些什麼變化。
圖上我們可以看到對於單點查詢，sysbench oltp測試中，5.7可以達到1.6MQPS，比5.6有接近3倍的效能提升！
對於只讀事務，我們用sysbench oltp測試下，5.7比5.6有超過一倍的效能提升！
對於只讀事務，我們用sysbench oltp測試下，5.7比5.6有超過一倍的效能提升！
而對於讀寫事務，我們也有50%左右的效能提升。是不是很強勁？當然，這只是其中一項效能優化，接下來還有更精彩的。
2、臨時表優化
我們在5.7中另一項重大效能優化是對臨時表達優化。
在5.7中，我們將臨時表從資料字典中分離出來，這樣，臨時表就不會跟其它正常表爭搶資料字典的鎖。同時，我們還將臨時表的表空間跟普通表空間區別開來，以減少I/O的開銷。
對於臨時表的DML操作，我們只記錄Undo日誌，不記錄Redo日誌，因為，臨時表不需要在Crash的時候Recovery，但是它需要rollback。這樣也減少了大量的日誌開銷。
這張圖顯示了5.7的臨時表create和drop的效能提升，這個應該是重複幾萬次create和drop所耗費的時間。5.7快到飛起來！
這是對臨時表插入5M行當資料的測試，一倍以上的提升。
這是刪除，開銷減少了75%左右。
update，減少40%左右。所以，如果大家在應用中會使用InnoDB的臨時表，那這個優化就能帶來很大的好處。
剛才談到的這個優化實際上不光是對InnoDB的臨時表有用，還對一種大家平時看不見的表，優化器用的快取表也有好處。之前，MySQL的優化器是用MyISAM來快取SQL執行的中間結果集的， 現在，採用了InnoDB優化後的臨時表，大家可以看圖，明顯快多了嘛！
好了，介紹完兩個最大頭的效能優化點，接下來我們瀏覽一下其他一些也非常重要的效能優化工作。
3、其他效能優化工作
- 緩衝區
這個是對於緩衝區的優化，頁的reference count採用了原子操作，可以極大的提高這個計數器的操作效率。可以看到，這個優化最重要的是解決在12核甚至更多核機器上效能問題。
同時，也對原來的刷寫演算法做了優化，提升了刷寫效率。
緩衝區刷寫採用多執行緒，而且可以配置執行緒數，同樣能提高刷寫效率。
- Redo日誌的I/O
對於Redo 日誌的I/O，我們不僅解決了一些bug而且還優化了checksum以及mutex的演算法。
- Memcached 外掛
得益於前面介紹的只讀事務的優化，InnoDB的Memcached 外掛也有了效能的飛躍，現在已經可以達到1.1M QPS。建議大家嘗試一下，特別是對資料量很小， 但訪問非常頻繁的只讀操作，可以採用InnoDB的Memcached外掛。
這是memcached的測試結果，效能大幅提升。
- 索引上的鎖
這項優化是針對索引上的鎖，一個非常複雜但是值得的優化。
- DDL和truncate的優化
對於DDL和truncate的優化，現在truncate可以做到原子操作了，之前truncate中如果crash了，會導致出錯。alter table也支援了更多新操作。
更快的DDL，這裡主要指的是Alter table增加索引之類的操作。原來建索引是讀一行插一行，現在是讀一批，排序再批量插入。所以，效能有了170%的提升。
呵呵，這下，大家增加一個索引就快多了。
- AHI
對於AHI的優化主要是將原來的雜湊索引拆分成多個。
對於效能的優化這一部分就介紹到這裡，總結一下，就是InnoDB在5.7中對效能做了一些非常重大的優化， 不光可以大幅加速資料的訪問和儲存的速度， 還能讓大家節省很多日常維護的時間。
接下來，再講講我們在5.7中增加了哪些新功能。
二、新功能
1、分割槽功能
首先是分割槽功能。以前，InnoDB內部是沒有分割槽的，大家看到的都是在InnoDB外面做的分割槽。而現在，InnoDB原生支援了分割槽。
這樣帶來的好處是，減少了記憶體開銷。以這樣一個8k的分割槽的表為例，當開啟十個例項的時候，可以減少90%的記憶體開銷。
而且現在我們還可以對一個單獨的分割槽做import/export了。
對於分割槽也支援了ICP和使用HANDLER來訪問了。
2、表空間管理
接下來一個新功能是表空間管理。其實這個不是什麼新功能，只是讓大家以更為習慣的方式來管理表空間。
3、動態調整緩衝區的大小
再接下來這個功能，我想大家肯定會喜歡，就是動態調整緩衝區的大小。
大家再也不用關資料庫，改配置檔案，再啟動資料庫來修改緩衝區的大小了，so easy！
4、日誌管理
日誌管理的新功能是自動截斷，這樣日誌檔案就不會再不停的增長了。這個功能我想大家也應該挺喜歡。
5、資料頁
支援更大的資料頁。之前我們支援的是4k，8k，16k，現在可以支援32k，64k了。這樣一些blob資料就可以直接存在頁裡，訪問起來更快。
6、對GIS的支援
在5.7中最大頭的新功能是對GIS的支援，主要由同事Jimmy和我來完成。
我們在InnoDB內部實現了基於R-tree的空間索引，這樣使用者就能很方便的查詢地理資訊資料了。
比如：查詢以我為中心，周圍2公里範圍內的飯店之類的操作將變得異常迅速。
7、虛擬列和虛擬列上的索引
5.7中還有一個大頭功能是虛擬列和虛擬列上的索引。也就是對於那些可以通過其他列的資料計算出來的列，大家可以建立一個虛擬列，它實際上是不儲存資料的，每次讀這個列都是臨時在InnoDB內部計算出來。這個功能是客戶要求的，但我不知道這裡的同學是不是對此有需求。
8、透明加密
為了讓使用者的資料更加安全，5.7中InnoDB實現了透明加密。（這個是我乾的）
使用者只需要在建表時加上加密選項，該表就被加密了，這樣，就算你的ibd檔案被偷了，別人也無法獲得任何資訊。
9、全文索引
對於全文索引，5.7中開始可以支援外部解析器。
比如說n-gram。
又比如說MECAB。
10、新儲存裝置
對於新儲存裝置的支援方面，我們在5.7中支援了原子寫入，在NVMFS上關掉了DW buffer。
11、資料壓縮
另一個重要的新功能是新的資料壓縮方法。基於頁IO的壓縮，也就是說，資料的壓縮和解壓發生在頁IO的過程中。我們利用了一些檔案系統的Punch Hole(檔案打洞）功能來輔助實現這一新功能。
這裡不詳細介紹其實現方法了，總之效果就是檔案更小，效率更高。
這裡還有一些其他功能就不一一列舉了，大家可以稍微瀏覽一下看看有沒有自己感興趣的，尤其是PFS這塊，對於運維來說應該有幫助， 可以讓DBA更多的瞭解當前系統的狀態。
我今天要講的內容大體就是這麼多。總結一下，InnoDB在5.7中在效能和功能方面做了很多工作，非常期待大家的試用和反饋。
Q1：網際網路金融企業，用MySQL 5.7的話，老師在高可用元件方面有什麼推薦？
A1：我覺得對於5.7來說，高可用方面在InnoDB這部分並沒有做太大的改進。所以，總體來說，5.7在高可用方面會更為可靠和高效，但是，5.7在replication方面有很多提升。至於推薦什麼高可用方案，我想還是要根據實際的應用情況來定。
Q2：分割槽表的分割槽鍵，可以是多個列嗎？
A2：可以多列。
Q3：虛擬列 都是臨時在InnoDB內部計算出來 ，是否意味著會消耗更多的CPU資源？
A3：有影響，但不大。
Q4：官方版本為什麼不把TokuDB帶到版本里去？
A4：這個是管理層決定的事情，我想他們有自己的考慮，可能主要是基於商業目的，而非技術原因。
Q5：關於MySQL優化，和原理解壓，有沒有推薦的書籍？
A5：市面上關於MySQL優化的書有很多，比如《高效能MySQL》，但是，我想多看看一些相關文章，結合自己的工作實踐會更有效果。
Q6：MySQL有沒有什麼好用的效能監控工具，類似於Oracle的AWR報告這種？
A6：目前官方是沒有的，可以找找其他的監控工具。
Q7：對事務的優先順序也有了一些調整。是如何調整的呀？
A7：這個主要是提高了一些事務的優先順序，比如說複製的GCS事務，這些高優先順序事務可以有一些特權，比如說可以跳過排隊的佇列，使得高優先順序的事務可以優先執行。
Q8：建立表加密時可以指定只加密部分列嗎？
A8：我今天說的這個表加密是在I/O層進行加密的，不能針對列進行加密，它只針對表，如果要只加密部分列，可以使用MySQL的 加密函式，在插入資料時進行加密。
Q9：資料庫從5.6遷移到5.7要注意一些什麼問題？
A9：升級工作正常來收不會遇到大的問題，因為我們在釋出版本的時候都會有相應的升級測試，只有萬一碰到什麼問題，也可以具體情況具體分析，實在不行，可以告訴我，看是不是有bug需要修改。
Q10：truncate table加入了原子性，那速度是否會變慢？
A10：這個工作只是保證了truncate的操作不會導致問題。
Q11：5.7在dblink方面是否有改進？
A11：這方面的改進我沒有聽說。
Q12：聽說sap的HANA記憶體資料庫處理效率很高，請問MySQL（或Oracle）有無與其它產品做過對比測試（如高併發，效能等）呢？
A12：HANA 是列式儲存的記憶體資料庫，體系結構和MySQL完全不一樣。因為不是同類型的產品，我們沒有專門針對HANA做對比測試。
文章出處：DBAplus社群