原文鏈接: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-0.html

Note

這是一個(gè)里程碑版本，使用者風(fēng)險(xiǎn)自擔(dān)侥祭。里程碑版本間(或者從一個(gè)里程碑版本到一個(gè)GA版本)的升級不予支持晰房。里程碑版本間的變更非常大亮蛔，使用者可能會遇到兼容性問題勇垛，例如在運(yùn)行通常的升級過程 mysql_upgrade 時(shí)胜卤，需要注意數(shù)據(jù)格式的變化丧靡。舉例說明祖能，使用者可能終究會發(fā)現(xiàn)在升級版本前歉秫，使用 mysqldump 轉(zhuǎn)儲數(shù)據(jù)是非常有必要的。（在任何情況下升級版本前做備份都是一種必要的審慎預(yù)防措施养铸。）

賬戶管理事項(xiàng)

• 不兼容的變更：在mysql系統(tǒng)數(shù)據(jù)庫中的權(quán)限表現(xiàn)在的底層引擎是 InnoDB(事務(wù)型)雁芙。之前，這些表的存儲引擎是 MyISAM(非事務(wù)型)钞螟。這個(gè)變更應(yīng)用于這些表: user, db, tables_priv, columns_priv, procs_priv, proxies_priv兔甘。
  權(quán)限表存儲引擎的變更時(shí)改變賬戶管理語句行為的基礎(chǔ)。之前鳞滨，一個(gè)指派給多個(gè)用戶的賬戶管理語句可能會產(chǎn)生某些用戶成功同時(shí)某些用戶失敗的結(jié)果《幢海現(xiàn)在，每個(gè)語句都是事務(wù)型的拯啦，對于指定給多個(gè)用戶的語句或者都成功澡匪，或者一旦有任何錯(cuò)誤都進(jìn)行回滾而不會有任何改變。如果語句執(zhí)行成功褒链，則寫入二進(jìn)制日志仙蛉，否則不會寫入；在語句執(zhí)行失敗的情況下碱蒙，會發(fā)生回滾并且不會產(chǎn)生行為變更荠瘪。上述的行為適用于以下類型的語句: ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, GRANT, RENAME USER, REVOKE。（SET PASSWORD 沒有被列入是因?yàn)樗疃嘀荒苡糜谝幻脩羧停缇褪鞘聞?wù)型的了哀墓。）這個(gè)變化的一個(gè)副作用是在 MySQL 5.7 主服務(wù)器往 MySQL 8.0 從服務(wù)器復(fù)制時(shí) 主服務(wù)器上會部分執(zhí)行成功的賬戶管理語句在從服務(wù)器會完全失敗。更多的信息喷兼，請查看 原子數(shù)據(jù)定義語句支持篮绰。
  如果你從早起版本升級到該版本，必須運(yùn)行 mysql_upgrade (并且重啟服務(wù)器)以將這些變更引入到 mysql 系統(tǒng)數(shù)據(jù)庫中季惯。

  Note

  如果 從一個(gè)老版本升級到該版本 MySQL卻沒有將授權(quán)表從 MyISAM 升級到 InnoDB, 服務(wù)器將認(rèn)為這些表只讀吠各，執(zhí)行賬戶管理語句會返回錯(cuò)誤。

  歸因于存儲引擎從 MyISAM 到 InnoDB 的變更, 在權(quán)限表上執(zhí)行不帶 ‘ORDER BY’ 的 SELECT 生成的結(jié)果行序可能與之前的版本不同勉抓。如果查詢結(jié)果要求具有特定的行序特性贾漏，請使用包含 ORDER BY 子句的語句。

• MySQL 現(xiàn)在支持角色藕筋，被命名為特權(quán)集合纵散。角色允許為賬戶分配特權(quán)組，并為授予個(gè)人特權(quán)提供了一種方便的替代方法，既可以用于形式化用戶所需的特權(quán)分配伍掀，并且可以實(shí)現(xiàn)：

  • 角色可被創(chuàng)建或刪除掰茶。
  • 角色能夠進(jìn)行擁有授予和撤銷的權(quán)限。
  • 角色能夠被授予給用戶賬戶和撤銷授權(quán)蜜笤。
  • 賬戶在會話中的有效角色可以在被授權(quán)的角色組間進(jìn)行選擇濒蒋，同時(shí)在會話期間，角色類型可能發(fā)生變化把兔。

  如需獲得更多信息沪伙，請查看 用戶角色。

  Note

  ROLE 在該版本中已經(jīng)成為了保留字垛贤，因此如果沒有引用標(biāo)識符的話不能被用于標(biāo)識符焰坪。

C API 事項(xiàng)

libmysqlclient 共享庫的主版本號從20（MySQL 5.7）增加到21(MySQL 8.0)趣倾。 （Bug #77600聘惦，Bug #21363863）

字符集支持

• utf8mb4 Unicode 字符集一個(gè)新的通用排序歸類，被命名為 utf8mb4_0900_ai_ci儒恋。 utf8mb4 還有幾個(gè)新的特定于語言的歸類善绎，其特征類似于utf8mb4_0900_ai_ci，但特定于語言的歸類優(yōu)先適用诫尽。語言特性的歸類才用了類似于 ISO 639-1 語言編碼相似的歸類名禀酱，正如下表所示。有兩種情況語言編碼名字組成有額外變量( German phone book order, Traditional Spanish)牧嫉。

  表5 utf8mb4 UCA9.0.0 語言特性類集

  Language	Collation
  Croatian	utf8mb4_hr_0900_ai_ci
  Czech	utf8mb4_cs_0900_ai_ci
  Danish	utf8mb4_da_0900_ai_ci
  Esperanto	utf8mb4_eo_0900_ai_ci
  Estonian	utf8mb4_et_0900_ai_ci
  German phone book order	utf8mb4_de_pb_0900_ai_ci
  Hungarian	utf8mb4_hu_0900_ai_ci
  Icelandic	utf8mb4_is_0900_ai_ci
  Latvian	utf8mb4_lv_0900_ai_ci
  Lithuanian	utf8mb4_lt_0900_ai_ci
  Polish	utf8mb4_pl_0900_ai_ci
  Classical Latin	utf8mb4_la_0900_ai_ci
  Romanian	utf8mb4_ro_0900_ai_ci
  Slovak	utf8mb4_sk_0900_ai_ci
  Slovenian	utf8mb4_sl_0900_ai_ci
  Modern Spanish	utf8mb4_es_0900_ai_ci
  Traditional Spanish	utf8mb4_es_trad_0900_ai_ci
  Swedish	utf8mb4_sv_0900_ai_ci
  Turkish	utf8mb4_tr_0900_ai_ci
  Vietnamese	utf8mb4_vi_0900_ai_ci

  utf8mb4_0900_ai_ci 還可以用作下表語言中的不區(qū)分重音剂跟、不區(qū)分大小寫的歸類。

  表6 utf8mb4_0900_ai_ci 適用語言

  語言名	語言編碼
  German (dictionary order)	de
  English	en
  Canadian French (locale fr_CA)	fr
  Irish Gaelic	ga
  Indonesian	id
  Italian	it
  Luxembourgian	lb
  Malay	ms
  Dutch	nl
  Portuguese	pt
  Swahili	sw
  Zulu	zu

  utf8mb4_da_0900_ai_ci 也可以在下表所列的語言中支持不區(qū)分重音酣藻、不區(qū)分大小寫曹洽。

  表7 utf8mb4_da_0900_ai_ci 適用的語言

  語言名	語言代碼
  Norwegian	no
  Norwegian Bokm?l	nb
  Norwegian Nynorsk	nn

  獨(dú)立于特定語言的utf8mb4_0900_ai_ci和適用于特定語言的 utf8mb4_LANG_0900_ai_ci Unicode 排序歸類都有如下特性：

  • 排序歸類不區(qū)分重音、不區(qū)分大小寫辽剧，基于 Unicode Collation Algorithm(UCA) 9.0.0 和 Common Locale Data Repository(CLDR) v30送淆。這些特性可從排序歸類的名字組成中可以看出(_0900, _ai, _ci)。例外：utf8mb4_la_0900_ai_ci 不基于 CLDR 庫因?yàn)?Classical Latin 沒有在 CLDR 中定義怕轿。
  • 排序歸類集適用于字符范圍 [U+0, U+10FFFF]偷崩。
  • 如果排序字符集(與歸類集一樣，翻譯者的主觀喜好撞羽，譯者注) 不是基于特定語言的阐斜，排序字符集會以默認(rèn)順序排序所有字符，包含補(bǔ)充字符诀紊。如果排序字符集基于特定語言的智听，其依據(jù)基于特定語言的規(guī)則進(jìn)行排序能夠適用的語言，不適用的語言仍按默認(rèn)順序。
  • 排序字符集的默認(rèn)順序是：排序字符集基于 DUCET 表 (Default Unicode Collation Element Table, 默認(rèn)統(tǒng)一編碼排序集元素表) 根據(jù)字符編碼在表中的權(quán)重進(jìn)行排序到推。如果在 DUCET 表中沒有對應(yīng)權(quán)重值的字符編碼考赛，排序字符集將根據(jù) UCA 算法構(gòu)建。
  • 對于獨(dú)立于特定語言的排序字符集莉测，縮寫的字符序列被視為單獨(dú)的字符串颜骤。對于基于特定語言的排序字符集，縮寫可能改變字符排序順序捣卤。

  更多信息忍抽，請查看 統(tǒng)一編碼字符集。

編譯事項(xiàng)

• Microsoft Windows: 如果要在 Windows 上構(gòu)建 MySQL, 現(xiàn)有工具鏈對64位的工具支持度更好（之前是32位）董朝。在64位系統(tǒng)上的構(gòu)建工具加速了鏈接過程鸠项，同時(shí)避免了由于32位鏈接器產(chǎn)生的地址空間有限的問題。（Bug #80675, Bug #22900585）
• CMake 現(xiàn)在使用 GNU gold 鏈接器（可用的情況下）進(jìn)行鏈接構(gòu)建子姜。如果不想要使用該鏈接器祟绊，請使用 CMake 選項(xiàng) -DUSE_LD_GOLD=0。（Bug #23759968, Bug #82163）
• CMake選項(xiàng) WITH_EXTRA_CHARSET 已經(jīng)被移除哥捕。MySQL 現(xiàn)在默認(rèn)配置所有的字符集牧抽。用戶如果想要更少的字符集，請直接編輯 cmake/character_sets.cmake, 然后重新編譯服務(wù)器遥赚。（Bug #80005, Bug #22552125）
• 現(xiàn)在服務(wù)器構(gòu)建依賴的 Boost 庫的最小版本是 1.60.0扬舒。（Bug #79380, Bug #22253921）
• 已經(jīng)清理完源碼庫，包括：清楚不必要的 CMake 檢測凫佛，移除源文件中無用宏讲坎；重新組織頭文件減少依賴數(shù)，以使其更模塊化愧薛，移除函數(shù)沒有定義的函數(shù)聲明晨炕，使用同等功能的工業(yè)標(biāo)準(zhǔn)庫中的函數(shù)替換部分自有函數(shù)。
• MySQL 源碼現(xiàn)在支持和使用了 C++11 特性厚满。為了能夠在所支持平臺上獲得 C++11 帶來的優(yōu)勢府瞄，一下編譯器應(yīng)該適用的最小版本為:
  • GCC: >= 4.8
  • Clang: >=3.4 (Xcode 7 on OS X)
  • Solaris Studio: >=12.4 (僅支持 Solaris 客戶端構(gòu)建)
  • Visual Studio: 2015
  • CMake: 在 Windows 平臺上，因 Visual Studio 版本的限制導(dǎo)致至少需要 CMake 版本 >= 3.2.3

在 Solaris 平臺上碘箍， stlport 庫不再使用遵馆。因此 SUNPRO_CXX_LIBRARY CMake選項(xiàng)y已無法使用，所以現(xiàn)在的版本中已移除該選項(xiàng)丰榴。

組件事項(xiàng)

• MySQL 服務(wù)器現(xiàn)在包含基于組件的基礎(chǔ)設(shè)施已提高服務(wù)器可擴(kuò)展性:
  • 組件可以提供對服務(wù)器和其他組件使用的服務(wù)货邓。（相對于使用中的服務(wù)，服務(wù)器本身也是一個(gè)組件四濒，等價(jià)于其他組件换况。）組件間只能通過他們提高的服務(wù)交互职辨。
  • INSTALL_COMPONENT 和 UNINSTALL_COMPONENT語句為運(yùn)行時(shí)操作組件提供了 SQL 接口。
  • 加載器服務(wù)將已安裝的組件注冊在 mysql.component 系統(tǒng)表中戈二，并為隨后的服務(wù)器重啟時(shí)在啟動(dòng)序列中安裝已注冊組件舒裤。

關(guān)于組件基礎(chǔ)設(shè)置及其 SQL 級接口的常用信息，請查看 MySQL 服務(wù)器組件觉吭。如果想查看組件內(nèi)部實(shí)現(xiàn)信息腾供，請查看 http://dev.mysql.com/doc/dev/mysql-server/latest/。

配置事項(xiàng)

• 不兼容的變更: InnoDB: 之前鲜滩，激活 innodb_read_only 系統(tǒng)變量只能為 InnoDB 存儲引擎防止創(chuàng)建表和刪除表伴鳖。在 MySQL 8.0 版本中，激活 innodb_read_only 會為任何存儲引起阻止這些操作徙硅。在 mysql 系統(tǒng)數(shù)據(jù)庫中使用表創(chuàng)建和刪除操作會修改數(shù)據(jù)字典表榜聂，但是這些表使用了 InnoDB 存儲引擎，當(dāng)激活 innodb_read_only 時(shí)不能進(jìn)行修改嗓蘑。同樣的原則適用于其他需要修改數(shù)據(jù)字典表的操作须肆，包括在使用 innoDB 存儲引擎的 mysql 數(shù)據(jù)庫中修改其他表，例如權(quán)限表和 func 以及 plugin 表等脐往。（Bug #21611899）
• 內(nèi)存映射事務(wù)協(xié)調(diào)器的 8KB 的硬編碼內(nèi)存頁大小對于諸如 ARM64 和 PowerPC 平臺等頁面大小大得多的平臺來說太小了休吠。服務(wù)器現(xiàn)在通過系統(tǒng)調(diào)用獲得當(dāng)前平臺的頁面大小扳埂，而非硬編碼其值业簿。造成的后果是 --log-tc-size 選項(xiàng)最小值和默認(rèn)值現(xiàn)在是6倍頁面大小。而且阳懂，這個(gè)值必須是頁面大小的整數(shù)倍梅尤。感謝 Alexey Kopytov 提供了補(bǔ)丁包。（Bug #23014086, Bug #80818, Bug #26931470, Bug #87995）
• MySQL 現(xiàn)在為了在運(yùn)行時(shí)能夠改變配置同事在服務(wù)器重啟后保持配置支持 SET 語句語法的變體 SET_PERSIST岩调。正如 SET_GLOBAL, SET_PERSIST 可被允許用于任何動(dòng)態(tài)(可在運(yùn)行時(shí)設(shè)置)?全局系統(tǒng)變量巷燥。這個(gè)語句不僅可以改變運(yùn)行時(shí)變量值，還可以在數(shù)據(jù)目錄中在名為 mysqld-auto.conf 的選項(xiàng)文件中寫入變量設(shè)置号枕。服務(wù)器啟動(dòng)時(shí)缰揪，會在處理玩其他選項(xiàng)文件后處理此文件。如需更多信息葱淳，請查看 使用選項(xiàng)文件 和 [ SET 變量賦值語法] (https://dev.mysql.com/doc/refman/8.0/en/set-variable.html)钝腺。
  為了提供每個(gè)變量最近設(shè)值的相關(guān)信息，Performance Schema 現(xiàn)在有一個(gè) variables_info 表列示了每個(gè)系統(tǒng)變量及其被設(shè)值的來源赞厕。請查看 Performance Schema variables_info 表艳狐。
  如果你從一個(gè)較早的版本升級到該版本 MySQL， 你必須運(yùn)行 mysql_upgrade （并重啟服務(wù)器）以在 Performance Shema中引入這個(gè)變更皿桑。
• 被廢棄的 mysql_install_db 計(jì)劃已經(jīng)從 MySQL 版本中移除『聊浚現(xiàn)在應(yīng)該使用帶有 --initialize 或 --initialize-insecure 選項(xiàng)的 mysqld 命令進(jìn)行數(shù)據(jù)目錄初始化蔬啡。另外，過去用于 mysql_install_db镀虐，現(xiàn)在用于 mysqld 里被廢棄的 --bootstrap 選項(xiàng)已經(jīng)被移除箱蟆，并且 mysql_install_db 中控制安裝位置的 INSTALL_SCRIPTDIR CMake 選項(xiàng)也被移除。
  第1個(gè)版本測試套件代碼之前位于 MySQL 源碼的 mysql-test/lib/v1 目錄刮便，這部分代碼使用了 mysql_install_db顽腾，因此現(xiàn)在被移除。MYSQL_INSTALL_DB 環(huán)境變量和 MTR_VERSION 值為1的環(huán)境變量已不再支持诺核。

數(shù)據(jù)字典事項(xiàng)

• 不兼容的變更: MySQL Server現(xiàn)在在事務(wù)表整合了一個(gè)全局?jǐn)?shù)據(jù)字典抄肖，其中包含數(shù)據(jù)庫對象的信息。在之前的 MySQL 發(fā)行版中窖杀，字典數(shù)據(jù)存放在元數(shù)據(jù)文件和非事務(wù)表中漓摩。

Important

與沒有數(shù)據(jù)字典的服務(wù)器相比，啟用數(shù)據(jù)字典的服務(wù)器通常有所差別入客，詳細(xì)信息請查看 數(shù)據(jù)字典用法差異管毙。而且，如果要升級到 MySQL 8.0桌硫，升級過程不像以往夭咬，會要求你先檢查環(huán)境條件確認(rèn)可以升級。更多信息铆隘，請查看 升級 MySQL, 尤其是 在 MySQL 5.7 環(huán)境中確認(rèn)升級準(zhǔn)備就緒卓舵。

InnoDB 在 MySQL 8.0.0 發(fā)行版中繼續(xù)使用自己的數(shù)據(jù)字典。
以下簡要描述這個(gè)變更的影響：
- 先前與基表和視圖關(guān)聯(lián)的.frm 元數(shù)據(jù)文件不再存在膀钠。以前存儲在 .frm 文件重的元數(shù)據(jù)現(xiàn)在存儲在數(shù)據(jù)字典表中掏湾。
與之類似，先前存儲在 .TRG 和 .TRN 文件中的觸發(fā)器元數(shù)據(jù)現(xiàn)在存儲在數(shù)據(jù)字典表中肿嘲，這些文件不再存在融击。
- 由于 .frm 文件的移除，因 .frm 文件結(jié)構(gòu)造成的 64KB 表定義大小的限制被取消雳窟。
- 由于 .frm 文件的移除尊浪， INFORMATION_SCHEMA.TABLES 的 VERSION 字段現(xiàn)在硬編碼為10，該值為 MySQL 5.6 中使用的最后一個(gè) .frm 文件版本封救。
- 提供給 MySQL 數(shù)據(jù)字典使用的新字典對象緩存將訪問過的數(shù)據(jù)字典對象存儲在內(nèi)存中拇涤，以便最小化磁盤I/O重用對象⌒四啵基于 LRU 的淘汰策略將最近最少使用的對象從內(nèi)存移除工育。緩存由存儲不同對象類型的幾個(gè)分區(qū)構(gòu)成。更多信息搓彻，請查看 字典對象緩存如绸。
- 服務(wù)器嘱朽、內(nèi)部存儲引擎和插件能夠使用新的內(nèi)部數(shù)據(jù)字典 API 在 MySQL 數(shù)據(jù)字典中訪問和存儲數(shù)據(jù)。內(nèi)部數(shù)據(jù)字典 API 包含了處理模式怔接、表空間搪泳、表空間文件、表扼脐、分區(qū)表岸军、表分區(qū)數(shù)據(jù)、觸發(fā)器瓦侮、存儲例程艰赞、事件、表對象肚吏、視圖方妖、字符集和排序字符集的操作。
由于這個(gè)變更罚攀，CREATE TRIGGER 和 DROP TRIGGER 產(chǎn)生的數(shù)據(jù)字典更新和二進(jìn)制日志寫入現(xiàn)在已被合并為單一原子事務(wù)党觅。
- 數(shù)據(jù)字典表現(xiàn)在不可見，但是在大部分情況下斋泄，可以使用 INFORMATION_SCHEMA 表替代查詢杯瞻。這樣一方面隨著服務(wù)器繼續(xù)開發(fā)底層數(shù)據(jù)字典表繼續(xù)變化，另一方面炫掐，可以保持一個(gè)穩(wěn)定的 INFORMATION_SCHEMA 接口以供應(yīng)用程序使用魁莉。
一些 INFORMATION_SCHEMA 表以及被完全重寫作為數(shù)據(jù)字典表的視圖：

1. CHARACTER_SETS
2. COLLATIONS
3. COLLATION_CHARACTER_SET_APPLICABILITY
4. COLUMNS
5. KEY_COLUMN_USAGE
6. SCHEMATA
7. STATISTICS
8. TABLES
9. TABLE_CONSTRAINTS
10. VIEWS

在上述表中查詢現(xiàn)在更高效，因?yàn)楝F(xiàn)在這些表可以從數(shù)據(jù)字典表中獲取信息卒废，而非更慢的其他媒介沛厨。尤其特別的是宙地，對于每個(gè)作為數(shù)據(jù)字典表的視圖的 `INFORMATION_SCHEMA` 表來說：
    - 對于每個(gè)針對 `INFORMATION_SCHEMA` 表的查詢來說服務(wù)器不再一定要?jiǎng)?chuàng)建臨時(shí)表摔认。
    - 當(dāng)?shù)讓訑?shù)據(jù)字典表存儲以前通過目錄掃描獲得的值（例如，枚舉數(shù)據(jù)庫中的數(shù)據(jù)庫名稱或表名稱）或文件打開操作（例如宅粥，從 `.frm` 文件讀取信息）時(shí)参袱，現(xiàn)在`INFORMATION_SCHEMA` 使用表查詢這些值。 （另外秽梅，即使對于非視圖 `INFORMATION_SCHEMA` 表抹蚀，也可以通過在數(shù)據(jù)字典查找來檢索數(shù)據(jù)庫和表名等值，不需要目錄或文件掃描企垦。）
    - 底層數(shù)據(jù)字典的索引允許優(yōu)化器創(chuàng)建高效的執(zhí)行計(jì)劃环壤，而之前處理 `INFORMATION_SCHEMA` 表需要對每個(gè)查詢都構(gòu)建一個(gè)臨時(shí)表。