連跳7個(gè)版本之后，MySQL 8.0.12有什么新特性？
引言
時(shí)隔三個(gè)月，MySQL 8.0.12 有什么新內(nèi)容？
今年4月份，MySQL突然直接從8.0.5跳過(guò)多個(gè)版本號(hào)到8.0.11，直接宣布8.0.11 GA，告訴大家說(shuō)，這個(gè)版本已經(jīng)可以到線上用了。
到今年7月底，MySQL 8.0.12版本發(fā)布，我從官方的release note里面，選取出來(lái)我認(rèn)為的重點(diǎn)內(nèi)容，在這里展開(kāi)聊一下。
如果有想要看全文的人，可以直接去看官方的發(fā)布內(nèi)容：
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html
filesort 算法的緩存設(shè)置優(yōu)化
眾所周知，MySQL 在處理 Order by 的時(shí)候，如果沒(méi)有索引可以用，會(huì)采用一個(gè)名為 file sort 的算法排序，但和這個(gè)算法有一個(gè)關(guān)聯(lián)的參數(shù)， sort_buffer_size，估計(jì)很多人都知道這個(gè)參數(shù)，這個(gè)參數(shù)在之前有個(gè)算是比較蛋疼的問(wèn)題：如果 sql 會(huì)話中，執(zhí)行 sql 需要進(jìn)行file sort，那么 mysql 就會(huì)給當(dāng)前回話直接分配 sort_buffer_size大小的內(nèi)存出來(lái)。
這個(gè)乍一看沒(méi)啥問(wèn)題，但需要注意的是，在 MySQL 中，沒(méi)辦法像 Oracle 那樣統(tǒng)一管理 PGA（用戶線程/進(jìn)程消耗的總內(nèi)存大小），遇到那種恰好會(huì)話數(shù)量比較多，filesort 比較多（哪怕SQL語(yǔ)句單拎出來(lái)性能沒(méi)啥問(wèn)題），sql 查詢量比較大的情況，就非常容易讓 MySQL 的內(nèi)存使用量超標(biāo)被操作系統(tǒng) OOM 了。
或者如果你有習(xí)慣設(shè)置 swap 空間，那么巨慢的 swap 會(huì)拖死整個(gè)機(jī)器，只能揮淚重啟，類似這種事故，在互聯(lián)網(wǎng)業(yè)務(wù)中，并不鮮見(jiàn)，也間接導(dǎo)致了很多人非常厭惡 file sort，哪怕多加幾條索引，也要全覆蓋式地處理掉所有 file sort。
但現(xiàn)在，這個(gè)內(nèi)存分配機(jī)制總算改變了，從 8.0.12 開(kāi)始，這個(gè)內(nèi)存分配變成了按需分配。也就是說(shuō)，對(duì)于排序量非常小的 sql（比如某個(gè)人的微博列表）這種，觸發(fā)了file sort，就再也不會(huì)直接分配 sort_buffer_size（默認(rèn)256KB）的大小了，而是分配很小的內(nèi)存出來(lái)用，某種程度上可以避免了很多突發(fā)性流量導(dǎo)致的事故。
rewrite插件支持DML語(yǔ)句
MySQL 從 5.7 開(kāi)始，新增了一個(gè) plugin 的接口，rewrite，用于在服務(wù)器接受 SQL 語(yǔ)句后，執(zhí)行前修改 SQL 語(yǔ)句，最初只是支持 select，從 8.0.12 開(kāi)始，支持了 insert，update，replace 這些 DML 語(yǔ)句。
SELECT ORDER BY與GROUP BY語(yǔ)法變更
8.0.12,8.0.13（未發(fā)布版本，但文檔中已經(jīng)更新內(nèi)容）開(kāi)始，MySQL 的 Order by 支持 GROUPING函數(shù) 以及 WITH ROLLUP語(yǔ)法，然后，在8.0.13開(kāi)始，廢棄掉group gy 中的desc，asc關(guān)鍵字，對(duì)于 WITH ROLLUP 得到的結(jié)果集合的排序，需要使用order by 語(yǔ)法。
對(duì)于搞數(shù)據(jù)聚合比較多的人來(lái)說(shuō)，WITH ROLLUP 與 GROUPING 應(yīng)該不算陌生，這個(gè)語(yǔ)法變更，相當(dāng)于是把 order by 的語(yǔ)法補(bǔ)全完整，更兼容 SQL 標(biāo)準(zhǔn)語(yǔ)法了，如果遷移程序到 8.0，需要注意這種不兼容的變更。
順帶一提，官方文檔此處寫(xiě)的是小寫(xiě)的 grouping，但實(shí)際上指的是 GROUPING函數(shù) 而非普通聚合函數(shù)（普通聚合函數(shù)一直是支持的）。參考代碼：
https://github.com/mysql/mysql-server/commit/d401baf535a69d6f2a945229acecbfd5863c0a48
測(cè)試表數(shù)據(jù)
With rollup語(yǔ)法：
8.0.12 之前（測(cè)試版本為 5.7.22），如果想要排序，會(huì)出現(xiàn)語(yǔ)法錯(cuò)誤：
需要寫(xiě)為（排序關(guān)鍵字寫(xiě)到 group by 里面）：
8.0.12 開(kāi)始可以執(zhí)行并排序（為了顯著效果增加了desc 關(guān)鍵字）：
Group Replication繼續(xù)優(yōu)化
新增了參數(shù) group_replication_exit_state_action 來(lái)控制，如果一個(gè)實(shí)例發(fā)現(xiàn)自己屬于被拋棄（網(wǎng)絡(luò)分區(qū)發(fā)生后的少數(shù)派）的實(shí)例的情況下，這個(gè)值默認(rèn)為ABORT_SERVER，也就是說(shuō)，少數(shù)派會(huì)自己關(guān)閉，這個(gè)值也可以設(shè)置為 READ_ONLY，這個(gè)設(shè)置下，會(huì)以只讀（設(shè)置super read only）的形式加入集群，并設(shè)置狀態(tài)為 ERROR。
InnoDB Alter Table優(yōu)化
這個(gè)可以說(shuō)是一個(gè)源遠(yuǎn)流長(zhǎng)的故事，簡(jiǎn)單來(lái)說(shuō)，就是騰訊游戲部門(mén)的 DBA 們，為了數(shù)據(jù)庫(kù)快速加列（游戲運(yùn)營(yíng)先天的快速變更問(wèn)題），寫(xiě)了補(bǔ)丁出來(lái)用（非常早年的時(shí)候），后來(lái)這個(gè)補(bǔ)丁逐漸被各個(gè)第三方發(fā)行版接受，現(xiàn)在終于進(jìn)入官方發(fā)布版，讓更多的人受益。
MySQL 的 DDL一直是非常出名的問(wèn)題，社區(qū)與官方都在這個(gè)問(wèn)題上投入了很大的精力，從最早 percona 的 toolkit 里面帶的 pt-osc（這個(gè)基于觸發(fā)器實(shí)現(xiàn)的在線改表，由于 MySQL 早年單表只支持一個(gè)觸發(fā)器，為了避免無(wú)法使用 pt-osc，有了早年一直流傳到現(xiàn)在的 MySQL重大守則之一：不許使用觸發(fā)器），到 github 發(fā)布的 gh-ost（基于 row 格式 binlog），官方也一直在搞 alter 相關(guān)的在線修改優(yōu)化（比如加索引等操作，參考鏈接 https://dev.mysql.com/doc/refman/8.0/en/innodb-create-index-overview.html）。
alter table 的 inplace 算法，實(shí)質(zhì)上解決的，是主庫(kù) DDL 不會(huì)導(dǎo)致讀寫(xiě)鎖表，但對(duì)于主從結(jié)構(gòu)，當(dāng) SQL 傳輸?shù)綇膸?kù)執(zhí)行的時(shí)候，從庫(kù)依然會(huì)有相當(dāng)大的延遲出現(xiàn)。因此實(shí)際上，對(duì)于延遲敏感性業(yè)務(wù)，依然是前面提到那倆工具的天下。
8.0.12的優(yōu)化是，新增了一個(gè)算法 ALGORITHM=INSTANT，專門(mén)處理只需要修改元數(shù)據(jù)就可以完成的變更，這個(gè)就可以相對(duì)比較方便地直接使用了，不需要擔(dān)心從庫(kù)延遲。
目前支持的操作是：
1.添加新列。已知限制條件如下：
- 不能與其他不支持INSTANT算法的alter子語(yǔ)句合并在一起。
- 只能添加在表列的末尾。
- 不能用于innodb的壓縮表（ROW_FORMAT=COMPRESSED）。
- 目標(biāo)表不能包含全文索引。
- 目標(biāo)表不能是臨時(shí)表。
- 目標(biāo)表不能是數(shù)據(jù)字典表。
- 這種添加方式下，不會(huì)計(jì)算行長(zhǎng)度是否合適，這個(gè)計(jì)算會(huì)在發(fā)生insert或者update的時(shí)候處理。
2. 添加或者刪除虛擬列。
3. 添加或者去掉列的默認(rèn)值。
4. 修改 enum，set 列類型的定義（題外話，有多少人知道并在用這個(gè)？）
5. 修改索引類型。
6. 重命名表名稱。
binlog支持管道輸入
對(duì)于大個(gè)頭 binlog 的處理，由于 MySQL mysqlbinlog 程序之前是不支持管道的，只能先解壓，之后再處理。從 8.0.12 開(kāi)始，mysqlbinlog支持管道輸入了，簡(jiǎn)單來(lái)說(shuō)，就是下面這么一回事：
- gzip -cd binlog-files_1.gz | ./mysqlbinlog - | ./mysql -uroot -p
當(dāng)一條drop 語(yǔ)句里面包含了關(guān)聯(lián)的父子表，則會(huì)直接刪除，不在額外要求父子表順序正確
如題，對(duì)于每次刪表都需要關(guān)閉外鍵檢查的人來(lái)說(shuō)，無(wú)疑是個(gè)好消息。
MySQL 外鍵關(guān)聯(lián)刪表：
8.0,版本中，普通情況下，刪除父表：
報(bào)錯(cuò) 3730
在更早的版本（5.7）中：
可以看出錯(cuò)誤信息，在 8.0 開(kāi)始更加詳細(xì)了。
如果執(zhí)行 drop table father，child：
必須寫(xiě)成：
但是，在 8.0.12 開(kāi)始：
ADMIN成為關(guān)鍵字
以后 SQL 字段又少了一個(gè)常用的詞哎=_=。
是誰(shuí)關(guān)閉了數(shù)據(jù)庫(kù)？
MySQL 終于會(huì)在日志里面記錄，是誰(shuí)發(fā)的 shutdown 命令了。
MySQL 關(guān)閉數(shù)據(jù)庫(kù)：
那些或許很好玩的bug
下面是從 bugfix 記錄中，找的一些好玩被修復(fù)的內(nèi)容，注意——由于每個(gè)人笑點(diǎn)不同，如果只關(guān)注新特性修改的話，下面的內(nèi)容不看就不看了。
- 早前宣布的新事務(wù)模型 VATS，由于其需要追蹤所有等待其他事務(wù)的事務(wù)數(shù)量，為了避免死鎖，目前被修改為生成出來(lái)的近似值。
- gtid_purge（記錄那些gtid事務(wù)已經(jīng)被purge掉）的值，在Group Replication 運(yùn)行期間，應(yīng)該是不能被修改的，然而現(xiàn)在發(fā)現(xiàn)它是可以修改的，因此改為在 group replication 運(yùn)行時(shí)候不能修改。
- 當(dāng) expire_logs_days 與 binlog_expire_logs_seconds 參數(shù)都設(shè)置的情況下，如果設(shè)置了 skip-log-bin ，現(xiàn)在開(kāi)始這個(gè)信息會(huì)被寫(xiě)入錯(cuò)誤日志。
- 當(dāng)有超大事務(wù)執(zhí)行（binlog 量超過(guò) binlog_cache_size）的時(shí)候，在刷出到臨時(shí)文件期間，如果遇到磁盤(pán)滿導(dǎo)致的刷出失敗，事務(wù)回滾，這個(gè)信息沒(méi)有被記錄在錯(cuò)誤日志里面，并且，事務(wù)回滾后，緩存也不會(huì)被清空。
- SUPER 權(quán)限的用戶，沒(méi)辦法修改 keyring_operations 參數(shù)。
- It was possible to drop the Performance Schema. 哈哈哈哈哈。
- slave_rows_search_algorithms 指定了 row 格式復(fù)制時(shí)候，行匹配的的方式，指定為 INDEX_SCAN 的話，如果表上有索引，則會(huì)使用索引操作。但如果主從庫(kù)的同一張表，使用了不同的列作為主鍵，并且從庫(kù)表上還有唯一索引的情況下，bug 會(huì)導(dǎo)致使用 table scan（全表掃描）而非索引。
- 對(duì)于 MyISAM 來(lái)說(shuō)，特定的 insert 與 delete 語(yǔ)句順序，會(huì)導(dǎo)致表數(shù)據(jù)損壞。
