MySQL 8.0主版本變更日誌

文檔:MySQL 8.0版本日誌.note
鏈接:http://note.youdao.com/noteshare?id=a8b71e5c978fabb4f204773562908f63&sub=45B9DC453C3C4E9EA23522F33D8C4462

參考https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-0.html#mysqld-8-0-0-account-management

賬戶管理

  • 不兼容的更改:MySQL系統數據庫的授權表已由MyISAM表(非事務性)更改爲InnoDB(事務性)表。這個改變適用於如下表:user, db, tables_priv, columns_priv,procs_priv, proxies_priv.

授權表存儲引擎變化時賬戶管理語句行爲變化的基礎。之前,管理多個用戶的賬戶管理語句可能對一些用戶生效,對一些用戶無效。現在,每個語句都是事務型的,要麼對所有用戶都生效,要麼一旦有任何報錯都無效回滾。如果語句執行成功則寫入二進制日誌,否則不寫入日誌,回滾而不產生任何影響。上述行爲適用於如下語句: ALTER USERCREATE ROLECREATE USERDROP ROLEDROP USERGRANTRENAME USERREVOKE.(SET PASSWORD沒有被列出,是因爲它應用於至多一個用戶而且實際上已經是事務性的) 這種行爲變化的一個副作用是,當在MySQL 8.0從屬服務器上覆制時,MySQL 5.7主服務器上部分完成的帳戶管理語句會失敗。

 

  • MySQL現在支持角色了。角色是命名的權限集合。
  1. 角色可以被創建和刪除。
  2. 角色可以被授權和回收權限。
  3. 角色可以授權給用戶賬戶,也可以從用戶賬戶處回收。
  4. 賬戶可以從已被授權的角色中選擇角色激活,也可以在賬戶會話中更改。

 

C API

libmysqlclient 共享庫主版本號從 20 (被 MySQL 5.7使用) 增長爲 21(被MySQL 8.0使用). 

 

Character Set Support

  • utf8mb4 Unicode 字符集新增一個比對方法(collation) utf8mb4_0900_ai_ci.

 

編譯

 

組件

MySQL服務器現在包含一個基於組件的基礎架構來提升服務器的擴展性:

  • 組件提供的服務對服務器和其他組件都可用。(就服務使用而言,服務器是一個組件,等同於其他組件。)組件僅通過它們提供的服務相互交互。
  •  INSTALL COMPONENT 和UNINSTALL COMPONENT 語句爲運行時組件操控提供一個SQL接口 。
  • 一個加載器服務註冊已安裝的組件到 mysql.component系統表,並在後續服務器重啓的啓動隊列事件期間安裝已註冊的組件。

 

配置

  • 不兼容的更改;InnoDB:以前,啓用innodb_read_only系統變量可以阻止只爲InnoDB存儲創建和刪除表。從MySQL 8.0開始。啓用innodb_read_only可以阻止對所有存儲引擎執行這些操作。表創建和刪除操作修改mysql系統數據庫中的數據字典表,但是這些表使用InnoDB存儲引擎,當啓用innodb_read_only時不能修改。同樣的原則也適用於需要修改數據字典表的其他表操作,以及使用InnoDB存儲引擎修改mysql數據庫中的其他表的操作,比如grant表和func和plugin表。(錯誤# 21611899)
  • 硬編碼內存頁大小爲8KB的內存映射事務協調器對於ARM64和PowerPC等頁面大得多的平臺來說太小了。服務器現在調用一個系統調用來獲取當前平臺的頁面大小,而不是使用硬編碼的值。--log-tc-size選項的結果是最小值和默認值現在是頁面大小的6倍。此外,該值必須是頁面大小的倍數。感謝Alexey Kopytov提供的補丁。(Bug #23014086, Bug #80818, Bug #26931470, Bug #87995)
  • MySQL現在支持SET語句語法的SET PERSIST變體,用於在運行時進行配置更改,這些更改也可以跨服務器重啓進行持久化。與SET GLOBAL一樣,SET PERSIST允許用於任何動態的全局系統變量(在運行時可設置)。該語句更改運行時變量值,但也將變量設置寫入data目錄中名爲mysqld-auto.cnf的選項文件。在啓動時,服務器在所有其他選項文件之後處理此文件。有關更多信息,請參見Persisted System Variables.

 

爲了提供顯示每個系統變量最近的配置信息,Performance Schema現在有一個variables_info表,其中列出了每個系統變量及其值的來源。參見Performance Schema variables_info Table.。

 

如果從早期版本升級到這個MySQL版本,則必須運行mysql_upgrade(並重新啓動服務器),以便將此更改合併到 Performance Schema中。

  • 已廢棄的mysql_install_db程序已從MySQL發行版中刪除。應該使用--initialize或--initialize-insecure選項調用mysqld來執行數據目錄初始化。此外,mysql_install_db使用的mysqld的不贊成的--bootstrap選項已經被刪除,控制mysql_install_db安裝位置的INSTALL_SCRIPTDIR CMake選項也已經被刪除。

 

版本1測試套件代碼以前位於MySQL源發行版的mysql-test/lib/v1目錄中。這段代碼使用了mysql_install_db並已被刪除。不再支持MYSQL_INSTALL_DB環境變量和MTR_VERSION環境變量的值1。

數據字典

不兼容的更改

數據字典的主要變更是

1)整合了元數據文件(事務性)和非事務性系統表,利用緩存將其緩存在內存,通過LRU算法維護

2)INFORMATION_SCHEMA不再是表,而是基於底層數據字典表的視圖

3)底層數據字典緩存到內存而不是臨時表空間,且其上的索引可以利用優化器高效查詢計劃提高查詢效率。

MySQL服務器現在合併了一個全局數據字典,其中包含事務表中關於數據庫對象的信息。在以前的MySQL版本中,字典數據存儲在元數據文件和非事務性系統表中。

下面的列表簡要描述了此更改的主要影響:

  • .frm元數據文件以前與基表和視圖相關聯的表和視圖已不復存在。以前存儲在.frm文件中的元數據現在存儲在數據字典表中。

 

類似地,以前存儲在. trg和. trn文件中的觸發器元數據存儲在數據字典表中,這些文件不再存在。

  • 刪除.frm文件後,.frm文件結構所施加的64KB表定義大小限制就消失了
  • 刪除.frm文件後,INFORMATION_SCHEMA.TABLES VERSION字段現在報告一個硬編碼的值10,這是MySQL 5.7中使用的最後一個.frm文件版本。
  • 一個新的dictionary對象緩存,它服務於MySQL數據字典,將以前訪問過的數據字典對象存儲在內存中,以支持對象重用和最小化磁盤I/O。基於邏輯單元的回收策略用於從內存中回收最近最少使用的對象。緩存由多個存儲不同對象類型的分區組成。有關更多信息,請參見字典對象緩存。

 

新的內部數據字典api使服務器、內部存儲引擎和插件能夠訪問和存儲MySQL數據字典中的數據。引入內 部數據字典api來處理模式、表空間、表空間文件、表、分區表、表分區數據、觸發器、存儲例程、事件、表對 象、視圖、字符集和排序。

 

通過此更改,用於CREATE TRIGGER 和 DROP TRIGGER 操作的數據字典更新和二進制日誌寫入將組合到單個原子事務中。

  • 數據字典表是不可見的,但在大多數情況下,可以查詢相應的INFORMATION_SCHEMA表。這允許在服務器開發過程中更改底層數據字典表,同時維護一個穩定的INFORMATION_SCHEMA接口供應用程序使用。

 

一些INFORMATION_SCHEMA表被完全重新實現爲數據字典表的視圖:

CHARACTER_SETS COLLATIONS COLLATION_CHARACTER_SET_APPLICABILITY COLUMNS KEY_COLUMN_USAGE SCHEMATA STATISTICS TABLES TABLE_CONSTRAINTS VIEWS

 

這些表上的查詢現在更有效,因爲它們從數據字典表獲得信息,而不是通過其他更慢的方法。特別是,對於每個作爲數據字典表視圖的INFORMATION_SCHEMA表:

  • 服務器不再必須爲INFORMATION_SCHEMA表的每個查詢創建臨時表。
  • 當底層數據字典表存儲以前通過目錄掃描獲得的值(例如,枚舉數據庫名或數據庫中的表名)或文件打開操作(例如,從.frm文件中讀取信息)時,對這些值的INFORMATION_SCHEMA查詢現在使用表查找。(此外,即使對於非視圖INFORMATION_SCHEMA表,也可以通過從數據字典中查找來檢索數據庫和表名等值,不需要目錄或文件掃描。)
  • 底層數據字典表上的索引允許優化器構造高效的查詢執行計劃,而以前使用每個查詢一個臨時表處理INFORMATION_SCHEMA表的實現則不允許這樣做。
  •  

前面的改進還適用於顯示相應的作爲數據字典表上的視圖的INFORMATION_SCHEMA表信息的SHOW語句。例如,SHOW DATABASES顯示與SCHEMATA表相同的信息。

 

對於檢索表統計信息的INFORMATION_SCHEMA查詢,服務器現在可以使用INFORMATION_SCHEMA表中緩存的統計信息,或者直接從存儲引擎獲取最新的統計信息。information_schema_stats系統變量控制服務器使用的統計信息源。

 

  • 當information_schema_stats是CACHED(缺省值)時,服務器使用存儲在統計信息和表中的高速緩存統計信息。
  • 當information_schema_stats是LATEST時,服務器直接從存儲引擎獲取統計信息。因此,服務器將對統計信息和表的查詢視爲對存儲在STATISTICS_DYNAMIC和TABLES_DYNAMIC表中的最新統計信息的查詢。

 

受影響的INFORMATION_SCHEMA表統計列包括:

STATISTICS.CARDINALITY TABLES.AUTO_INCREMENT TABLES.AVG_ROW_LENGTH TABLES.CHECKSUM TABLES.CHECK_TIME TABLES.CREATE_TIME TABLES.DATA_FREE TABLES.DATA_LENGTH TABLES.INDEX_LENGTH TABLES.MAX_DATA_LENGTH TABLES.TABLE_ROWS TABLES.UPDATE_TIME

 

有關更多信息,請參見Optimizing INFORMATION_SCHEMA Queries.

 

foreign_keys和foreign_key_column_usage現在存儲外鍵信息。獲取外鍵信息的標準SQL方法是使用REFERENTIAL_CONSTRAINTS 和KEY_COLUMN_USAGE表;這些表現在通過作爲foreign_keys、foreign_key_column_usage和其他數據字典表的視圖實現。

 

對於某些外鍵錯誤,服務器現在會生成更合適、更有用的錯誤消息。

 

注意:

不兼容性:以前,MySQL支持長度超過64個字符的外鍵名。按照SQL標準,存儲在foreign_keys和foreign_key_column_usage表中的外鍵名最多爲64個字符,因此不再允許使用更長的外鍵名。

 

  • 因爲數據字典提供了關於數據庫對象的信息,所以服務器不再檢查data目錄中的目錄名來查找數據庫。因此,--ignore-db-dir選項和ignore_db_dirs系統變量是無關的,並且已經被刪除。相應地更新系統配置和應用程序。

 

  • 以前,可以使用CREATE TEMPORARY TABLE通過用不存在的數據庫的名稱限定表名在不存在的數據庫中創建表。今後不再被允許。

 

  • 系統表的變化:
  1. 許多系統表已經從MyISAM(非事務性)錶轉換爲InnoDB(事務性)表。例如,正如在這些發佈說明的其他地方 所討論的,grant表現在是InnoDB表。其他的例子如下。
  2. 在mysql系統數據庫中存儲用戶定義函數信息的func表現在是一個InnoDB(事務)表。以前,它是一個MyISAM(非事務性)表。
  3. 由於這種變化,CREATE FUNCTION和DROP FUNCTION語句會導致隱式提交,即使在用於用戶定義的函數時也是如此(參見Statements That Cause an Implicit Commit))。在以前,它們在用於存儲函數而不是用戶定義函數時導致隱式提交。
  4. 以前,stored routines和events信息存儲在mysql系統數據庫的proc和event表中。那些表不再使用了。相反,關於stored routines和events信息存儲在mysql系統數據庫中的 routines, events, 和parameters數據字典表中。舊錶使用MyISAM(非事務性)存儲引擎。新表使用InnoDB(事務)引擎。

以前,創建包含非法字符的stored routines會產生警告,現在是一個錯誤。

  1. 爲了將對系統表(例如,時區或日誌表)的訪問與對非系統表的訪問區分開來,服務器使用Locking system tables和 Opening system tables的線程狀態,而不是System lock 和Opening tables 的線程狀態。參見 General Thread States.
  • InnoDB更改:
  1. 永久InnoDB表空間現在包括 Serialized Dictionary Information (SDI)事務性存儲,它是序列化形式的字典對象數據。隨着前面提到的.frm和觸發器元數據文件的消失,您可能會注意到. sdi文件的出現。這些是序列化的字典信息文件。SDI事務存儲是爲尚未完全實現的正在開發的特性保留的。
  2. 一個新的命令行實用程序ibd2sdi用於從持久的InnoDB表空間中提取序列化的字典信息(SDI)。在這個版本中,SDI數據沒有出現在持久的InnoDB表空間中。ibd2sdi實用程序保留供將來使用。
  3. 對InnoDB啓動代碼進行重構,以支持對MySQL數據進行初始化更改。
  • 升級和降級影響:
  1. 要從MySQL 5.7升級到MySQL 8.0,必須執行在 Upgrading MySQL中描述的升級過程。
  2. 只支持使用邏輯降級方法(mysqldump降級)從MySQL 8.0降級到MySQL 5.7。不支持就地降級。

(Bug #80481, Bug #22811659)

 

Data Type Notes

位函數支持大於64位的參數和返回值。

  • Bit functions and operators comprise BIT_COUNT()BIT_AND()BIT_OR()BIT_XOR()&|^~<<, and >>. Prior to MySQL 8.0, bit functions and operators required BIGINT (64-bit integer) arguments and returned BIGINT values, so they had a maximum range of 64 bits. Non-BIGINT arguments were converted to BIGINT prior to performing the operation and truncation could occur. Now bit functions and operators permit binary string type arguments (BINARYVARBINARY, and the BLOB types) and return a value of like type, which enables them to take arguments and produce return values larger than 64 bits. Nonbinary string arguments are converted to BIGINT and processed as such, as before.

Permitting binary string arguments for bit functions and operators makes it easier not only to manipulate larger values, but to perform bit operations not easily done previously on certain types of data, such as UUID and IPv6 values. For examples, see Bit Functions and Operators.

An implication of this change in behavior is that bit operations on binary string arguments might produce a different result in MySQL 8.0 than in 5.7. For information about how to prepare in MySQL 5.7 for potential incompatibilities between MySQL 5.7 and 8.0, see Bit Functions and Operators, in MySQL 5.7 Reference Manual.

Doxygen Notes

源碼的內部文檔已經更新位採用Doxygen歸檔。

  • The MySQL source code has been updated to use Doxygen for the internal documentation. This is a work in progress. As new MySQL versions are distributed, the Doxygen documentation will be updated, with the latest version always available at https://dev.mysql.com/doc/index-other.html.

It is also possible to generate the Doxygen content locally from a MySQL source distribution using the instructions atGenerating MySQL Doxygen Documentation Content.

Optimizer Notes

  • 使用可變大小的記錄緩存來替換舊的固定大小的記錄緩存。
  • 支持表級別MERGE和NO_MERGE註釋。
  • 支持不可見索引。不可見索引不會被優化器使用,目的是用來測試創建某個非聚集索引帶來的影響。
  • mysql庫引入一個column_stats 表用來存儲列值統計信息。

 

  • InnoDB: The storage engine interface now enables the optimizer to provide information about the size of the record buffer to be used for scans that the optimizer estimates will read multiple rows. The buffer size can vary based on the size of the estimate. InnoDB uses this variable-size buffering capability to take advantage of row prefetching, and to reduce the overhead of latching and B-tree navigation. Previously, InnoDB used a small, fixed-size buffer.
  • The optimizer now supports table-level MERGE and NO_MERGE hints for specifying whether derived tables or views should be merged into the outer query block or materialized using an internal temporary table. Examples:

SELECT /*+ MERGE(dt) */ * FROM (SELECT * FROM t1) AS dt; SELECT /*+ NO_MERGE(dt) */ * FROM (SELECT * FROM t1) AS dt;

For more information, see Optimizer Hints. (Bug #79554, Bug #22328100)

  • MySQL now supports invisible indexes. An invisible index is not used by the optimizer at all, but is otherwise maintained normally. Indexes are visible by default. Invisible indexes make it possible to test the effect of removing an index on query performance, without making a destructive change that must be undone should the index turn out to be required. This feature applies to InnoDB tables, for indexes other than primary keys.

To control whether an index is invisible explicitly for a new index, use a VISIBLE or INVISIBLE keyword as part of the index definition for CREATE TABLECREATE INDEX, or ALTER TABLE. To alter the invisibility of an existing index, use aVISIBLE or INVISIBLE keyword with the ALTER TABLE ... ALTER INDEX operation. For more information, see Invisible Indexes.

  • The mysql system database now contains a column_stats table designed to store statistics about column values. For more information, see Optimizer Statistics.

Packaging Notes(略)

Parser Notes

  • The parser rules for SELECT and UNION were refactored to be more consistent (the same SELECT syntax applies uniformly in each such context) and reduce duplication. Several user-visible effects resulted from this work:
    • NATURAL JOIN permits an optional INNER keyword (NATURAL INNER JOIN), in compliance with standard SQL.
    • Right-deep joins without parentheses are permitted (for example, ... JOIN ... JOIN ... ON ... ON), in compliance with standard SQL.
    • STRAIGHT_JOIN now permits a USING clause, similar to other inner joins.
    • The parser accepts parentheses around query expressions. For example, (SELECT ... UNION SELECT ...) is permitted.
    • The parser better conforms to the documented permitted placement of the SQL_CACHE and SQL_NO_CACHE query modifiers.
    • Left-hand nesting of unions, previously permitted only in subqueries, is now permitted in top-level statements. For example, this statement is now accepted as valid:

(SELECT 1 UNION SELECT 1) UNION SELECT 1;

(Bug #11746363, Bug #25734)

  • The parser rules for CREATE TABLE were refactored to be context independent and improve maintainability and extensibility. Several user-visible effects resulted from this work:
    • For generated columns, including NOT NULL NULL resulted in a column that included the NOT NULL attribute, which differed from nongenerated columns. Such definitions now use the final attribute NULL, resulting in a nullable column (consistent with nongenerated columns).
    • CREATE TEMPORARY TABLE no longer permits multiple instances of TEMPORARY.
    • Previously, PARSE_GCOL_EXPR was a keyword and could not be used as a label in stored programs. It is no longer a keyword and can be used as a label.
    • Messages for some syntax errors are more precise with respect to the location of the error within the statement.

 

Performance Schema Notes

  • Incompatible Change: The Performance Schema now instruments server errors (and warnings), and exposes statistical information about them through a set of summary tables:

For more information, see Error Summary Tables

 

In consequence of the preceding changes, two server error symbols were renamed:ER_CANT_SET_ENFORCE_GTID_CONSISTENCY_ON_WITH_ONGOING_GTID_VIOLATING_TRANSACTIONS is nowER_CANT_ENFORCE_GTID_CONSISTENCY_WITH_ONGOING_GTID_VIOLATING_TX andER_SET_ENFORCE_GTID_CONSISTENCY_WARN_WITH_ONGOING_GTID_VIOLATING_TRANSACTIONS is nowER_ENFORCE_GTID_CONSISTENCY_WARN_WITH_ONGOING_GTID_VIOLATING_TX.

  • Previously, the DIGEST and DIGEST_TEXT columns in the Performance Schema events_statements_current table were populated only after statement execution ended. Now, the columns are populated just after parsing and before statement execution begins. This enables monitoring applications to access statement digest information during statement execution. (Bug #23336542)
  • Previously, Performance Schema optimizations focused on reducing the overhead involved in collecting monitoring data. Complementing that earlier work, overhead now is also reduced for Performance Schema queries that retrieve that data. This is achieved by the addition of indexes to most Performance Schema tables, which gives the optimizer access to execution plans other than full table scans. These indexes also improve performance for related objects, such as sysschema views that use those tables. For more information, see Optimizing Performance Schema Queries.
  • The size of the ROLE column of the setup_actors Performance Schema table was increased from 16 to 32 characters.

Security Notes

  • The validate_password_check_user_name system variable is now enabled by default rather than disabled. This means that when the validate_password plugin is enabled, by default it now rejects passwords that match the current session user name.
  • The client-side --ssl and --ssl-verify-server-cert options have been removed. Use --ssl-mode=REQUIRED instead of --ssl=1 or --enable-ssl. Use --ssl-mode=DISABLED instead of --ssl=0, --skip-ssl, or --disable-ssl. Use --ssl-mode=VERIFY_IDENTITY instead of --ssl-verify-server-cert options. (The server-side --ssl option remains unchanged.)

For the C API, MYSQL_OPT_SSL_ENFORCE and MYSQL_OPT_SSL_VERIFY_SERVER_CERT options for mysql_options()correspond to the client-side --ssl and --ssl-verify-server-cert options and have been removed. Use MYSQL_OPT_SSL_MODE with an option value of SSL_MODE_REQUIRED or SSL_MODE_VERIFY_IDENTITY instead.

Spatial Data Support(略)

Test Suite Notes(略)

X Plugin Notes(略)

Functionality Added or Changed

  • Incompatible Change; Partitioning: The generic partitioning handler has been removed from the MySQL server. As part of this change, mysqld no longer supports the --partition and --skip-partition options, and the server can no longer be built using -DWITH_PARTITION_STORAGE_ENGINE. partition is also no longer displayed in the output of SHOW PLUGINS, or shown in the INFORMATION_SCHEMA.PLUGINS table.

In order to support partitioning of a given table, the storage engine used for the table must now provide its own (“native”) partitioning handler. InnoDB is the only storage engine supported in MySQL 8.0 which includes a native partitioning handler. An attempt to create partitioned tables in MySQL 8.0 using any other storage engine fails. (The NDB storage engine used by MySQL NDB Cluster also provides its own partitioning handler, but is currently not supported by MySQL 8.0.)

Effects on upgrades.  The direct upgrade of a partitioned table using a storage engine other than InnoDB (such asMyISAM) from MySQL 5.7 (or earlier) to MySQL 8.0 is not supported. There are two options for upgrading such a table to be compatible with MySQL 8.0, listed here:

    • Remove the table's partitioning; you can do this without any data loss by executing an ALTER TABLE ... REMOVE PARTITIONING statement.
    • Change the storage engine used for the table to InnoDB, using ALTER TABLE ... ENGINE=INNODB; this leaves the table's partitioning in place. At least one of these operations must be performed for any partitioned non-InnoDBtable, prior to upgrading the server to MySQL 8.0. Otherwise, such a table cannot be used following the upgrade.

For information about converting MyISAM tables to InnoDB, see Converting Tables from MyISAM to InnoDB.

An analogous situation is met when importing databases from a dump file that was created in MySQL 5.7 or earlier usingmysqldump into a MySQL 8.0 server, due to the fact that table creation statements that would result in a partitioned table using a storage engine without such support fail with an error in MySQL 8.0. For this reason you must ensure that any statements in the dump file creating partitioned tables do not also specify an unsupported storage engine. You can do this either by removing any references to partitioning from CREATE TABLE statements that use a value for the STORAGE ENGINE option other than InnoDB, or by specifying the storage engine as InnoDB (or allowing InnoDB to be used by default).

For more information, see Partitioning Limitations Relating to Storage Engines.

  • Important Change; InnoDB: The following InnoDB file format configuration options were deprecated in MySQL 5.7.7 and are now removed:
    • innodb_file_format
    • innodb_file_format_check
    • innodb_file_format_max
    • innodb_large_prefix

File format configuration options were necessary for creating tables compatible with earlier versions of InnoDB in MySQL 5.1. Now that MySQL 5.1 has reached the end of its product lifecycle, these options are no longer required.

The FILE_FORMAT column was removed from the INNODB_SYS_TABLES and INNODB_SYS_TABLESPACES Information Schema tables.

  • InnoDB: The innodb_buffer_pool_debug option permits multiple buffer pool instances when the buffer pool is less than 1GB in size, ignoring the 1GB minimum buffer pool size constraint imposed on innodb_buffer_pool_instances. (Bug #24287290)
  • InnoDB: A new dynamic configuration option, innodb_deadlock_detect, may be used to disable deadlock detection. On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. (Bug #23477773)
  • InnoDB: The libinnodb_zipdecompress.a library allows external tools to use the page_zip_decompress_low() function to decompress InnoDB pages. (Bug #21405300, Bug #77664)
  • InnoDB: To address contention that could occur under some workloads, the buffer pool mutex was removed and replaced by several list and hash protecting mutexes. Also, several buffer pool related variables no longer require buffer pool mutex protection. Thanks to Yasufumi Kinoshita and Laurynas Biveinis for the patch. (Bug #20381905, Bug #75534)
  • InnoDB: InnoDB now avoids intermediate commits that would occur every 10000 rows during ALTER TABLE ALGORITHM=COPY operations. The purpose of intermediate commits was to speed up recovery in the case of an abortedALTER TABLE ALGORITHM=COPY operation. If an ALTER TABLE ALGORITHM=COPY operation is aborted, the new, uncommitted table is now dropped during DDL log recovery before the undo log is rolled back, thereby avoiding time-consuming data rollback for the uncommitted table. Undo logging is now suppressed for ALTER TABLE ALGORITHM=COPYoperations unless there is an IGNORE clause or something else that requires rollback capability.

If there is full-text index on the table being altered, full-text data is inserted into full-text auxiliary tables as the ALTER TABLE ALGORITHM=COPY operation inserts rows into the new, uncommitted table. Previously, full-text data was only processed on transaction commit. (Bug #17479594)

  • InnoDB: To reduce read-write lock contention that can result from multiple purge threads purging rows from the same table, undo records are now grouped and assigned to different purge threads by table ID.
  • InnoDB: InnoDB code now uses the C++ std::thread library for thread management.
  • InnoDB: BLOB code was refactored to provide an internal C++ interface for operations on compressed and uncompressed BLOB data.
  • InnoDB: The InnoDB memcached plugin now supports multiple get operations (fetching multiple key/value pairs in a single memcached query) and range queries. See InnoDB memcached Multiple get and Range Query Support.
  • InnoDB: The innodb_stats_sample_pages system variable was removed. innodb_stats_sample_pages was deprecated in MySQL 5.6.3 and replaced by innodb_stats_transient_sample_pages.
  • InnoDB: When encountering index tree corruption, InnoDB writes a corruption flag to the redo log, which makes the corruption flag crash safe. InnoDB also writes in-memory corruption flag data to an engine-private system table on each checkpoint. During recovery, InnoDB reads corruption flags from both locations and merges results before marking in-memory table and index objects as corrupt.
  • InnoDB: The innodb_locks_unsafe_for_binlog system variable was removed. innodb_locks_unsafe_for_binlog was deprecated in MySQL 5.6.3. The READ COMMITTED isolation level provides similar functionality.
  • InnoDB: InnoDB no longer creates .isl files (InnoDB Symbolic Link files) when creating tablespace data files outside of the MySQL data directory.

With this change, moving a remote tablespace while the server is offline by manually modifying an .isl file is not supported.

  • InnoDB: InnoDB no longer supports compressed temporary tables. When innodb_strict_mode is enabled (the default),CREATE TEMPORARY TABLE returns an error if ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE is specified. Ifinnodb_strict_mode is disabled, warnings are issued and the temporary table is created using a non-compressed row format.

With this change, all temporary tables are created in the shared temporary tablespace, ibtmp1.

The PER_TABLE_TABLESPACE and IS_COMPRESSED columns were removed from theINFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO.

  • InnoDB: The new INFORMATION_SCHEMA.INNODB_CACHED_INDEXES table reports the number of index pages cached in theInnoDB buffer pool for each index.
  • InnoDB: The innodb_checksums system variable was removed. innodb_checksums was replaced byinnodb_checksum_algorithm in MySQL 5.6.3.
  • InnoDB: InnoDB startup code was refactored.
  • InnoDB: The innodb_flush_method default value is no longer NULL. On Unix-like systems, the default value is fsync. On Windows systems, the default value is unbuffered.

On Windows, the innodb_flush_method setting no longer affects the innodb_use_native_aio setting. There are now two possible settings for innodb_flush_method on Windows, unbuffered (unbuffered I/O) and normal (buffered I/O). With this change, you can enable asynchronous I/O with buffered I/O, which is a new combination (innodb_use_native_aio=ONand innodb_flush_method=normal). The async_unbuffered setting was removed.

You can now set innodb_flush_method and innodb_change_buffering configuration options using numeric values.

  • InnoDB: The innodb_support_xa system variable, which enables support for two-phase commit in XA transactions, was removed. As of MySQL 5.7.10, InnoDB support for two-phase commit in XA transactions is always enabled.
  • InnoDB: InnoDB no longer creates an .isl file (InnoDB Symbolic Link files) when creating a file-per-table tablespace data file outside of the MySQL data directory. InnoDB now uses the redo log to locate remote tablespace data files.

Offline relocation of a file-per-table tablespace data file created outside of the MySQL data directory by modifying the.isl file is no longer supported.

  • InnoDB: The current maximum auto-increment counter value is now written to the redo log each time the value changes, and saved to an engine-private system table on each checkpoint. These changes make the current maximum auto-increment counter value persistent across server restarts. Additionally:
    • A server restart no longer cancels the effect of the AUTO_INCREMENT = N table option. If you initialize the auto-increment counter to a specific value, or if you alter the auto-increment counter value to a larger value, the new value is persisted across server restarts.
    • A server restart immediately following a ROLLBACK operation no longer results in the reuse of auto-increment values that were allocated to the rolled-back transaction.
    • If you modify an AUTO_INCREMENT column value to a value larger than the current maximum auto-increment value (in an UPDATE operation, for example), the new value is persisted, and subsequent INSERT operations allocate auto-increment values starting from the new, larger value.

For more information, see AUTO_INCREMENT Handling in InnoDB, and InnoDB AUTO_INCREMENT Counter Initialization. (Bug #199, Bug #13726455)

  • Replication: There are two improvements to how a CHANGE MASTER TO statement is written into the error log (mysqld.log):
    • Before, no commas were put between the option specifications (for example MASTER_USER = and MASTER_PASSWORD =), so users who wanted to use the statement by copy and paste had to insert the commas manually. Commas are now inserted when the statement is written to the error log.
    • When the literal “<secret>” is inserted as a placeholder for the MASTER_PASSWORD value, no quotes are used now, so users who forget to replace the literal with the real password before a copy and paste gets a syntax error immediately, instead of running into other issues.

(Bug #18194384)

  • Replication: It is now possible to restore a backup of a GTID-based replication server because you can add GTIDs togtid_purged, regardless of whether gtid_executed is empty or not. This enables you to restore backups from GTID-based replication servers without losing existing GTID information and binary logs. The GTIDs to add are those which existed in gtid_executed at the time of taking the backup. The syntax for SET GTID_PURGED has been extended so that SET GTID_PURGED ="+gtid_set" adds gtid_set to the existing gtid_purged GTID set.
  • Replication: New Performance Schema stages have been added to show the progress of row-based replication. You can use these stages to check the progress of slow operations in row-based replication. Additionally you can find out which database the changes are being applied to. This assists in troubleshooting row-based replication issues and provides more information for performance tuning. For more information see Monitoring Row-based Replication
  • JSON: This release adds an unquoting extraction operator ->>, sometimes also referred to as an inline path operator, for use with JSON documents stored in MySQL. The new operator is similar to the -> operator, but performs JSON unquoting of the value as well. For a JSON column mycol and JSON path expression mypath, the following three expressions are equivalent:

The ->> operator can be used in SQL statements wherever JSON_UNQUOTE(JSON_EXTRACT()) would be allowed. This includes (but is not limited to) SELECT lists, WHERE and HAVING clauses, and ORDER BY and GROUP BY clauses.

For more information, see Functions That Search JSON Values, and JSON Path Syntax. (Bug #78736, Bug #21980346)

  • To produce more accurate estimates, the MEMORY storage engine now calculates index statistics (records per key estimates) using floating-point rather than integer arithmetic. (Bug #23024059)
  • A new CMake option, INSTALL_STATIC_LIBRARIES, enables control over whether to install static libraries. The default isON. If set to OFF, these libraries are not installed: libmysqlclient.a, libmysqld.a, libmysqlservices.a. (Bug #22891432)
  • The internal mysql_prepare_create_table() server function has been refactored for improved code maintainability and clarity. This code revision results in the following minor changes of behavior for CREATE TABLE and ALTER TABLE:

(Bug #22884886)

  • Previously, the Performance Schema was not built for libmysqld, the embedded server. This prevented use of the SHOW STATUS and SHOW VARIABLES statements with show_compatibility_56=OFF because, with that setting, those statements take their results from Performance Schema tables. Now for libmysqld, the required Performance Schema tables are built (with no instrumentation collected), so that those SHOW statements can be supported withshow_compatibility_56=OFF. (Bug #22809694)
  • Several internal functions used by JSON_CONTAINS()JSON_SEARCH(), and other MySQL JSON functions created excessive numbers of local copies of keys, values, or both, when performing inspections of JSON objects. Such copying has been eliminated or reduced in many cases. In addition, the lifetimes of temporary objects used by some of these functions have been reduced. These changes should make these and related JSON functions perform more efficiently than previously, and with fewer resources required. (Bug #22602142)
  • If the system lz4 and openssl zlib commands are available, the lz4_decompress and zlib_decompress utilities are unneeded. Two changes enable those utilities not to be built: If the new WITH_LZ4 CMake option is set to system,lz4_decompress is not built or installed. If the WITH_ZLIB CMake option is set to system, zlib_decompress is not built or installed. (Bug #22329851)
  • Source files for the MySQL strings library have been converted from C (.c suffix) to C++ (.cc suffix). This enables stricter compilation checks and use of C++ features in the library code. (Bug #22124719)
  • Source code for the mysys library now uses C++ rather than C to take advantage of stricter compilation checks and permit use of C++ features. (Bug #21881278)
  • For improved performance and better compatibility with other platforms, my_sync() on OS X now uses fsync() rather than fcntl() with the F_FULLSYNC flag. (Bug #20742269)
  • A new CMake option, WITH_TSAN, permits enabling ThreadSanitizer for compilers that support it. (Bug #80409, Bug #23171902)
  • The global list of connections, previously protected by a single mutex, has been partitioned into eight parts, each protected by its own instance of the mutex. The result is a reduction of overhead and improved performance for connection processing. An implication of this change for monitoring purposes is that the Performance Schema now exposes eight different instances each of the LOCK_thd_list mutex, LOCK_thd_remove mutex, and COND_thd_listcondition variable.
  • MySQL now provides functions to manipulate UUID values and make them easier to work with:
    • UUID_TO_BIN() and BIN_TO_UUID() convert between UUID values in string and binary formats (represented as hexadecimal characters and VARBINARY(16), respectively). This permits conversion of string UUID values to binary values that take less storage space. UUID values converted to binary can be represented in a way that permits improved indexing efficiency.
    • IS_UUID() returns 1 or 0 to indicate whether its argument is a valid string-format UUID value.

For more information about these functions, see Miscellaneous Functions

  • The mysql_plugin utility has been removed. Alternatives include loading plugins at server startup using the --plugin-load or --plugin-load-add option, or at runtime using the INSTALL PLUGIN statement.
  • The server now relies on storage engines to clean up temporary tables left from previous server runs. InnoDB does this by discarding the temporary tablespace on restart. MyISAM and other similar storage engines still rely on scanning the temporary directory to detect leftover tables, by looking for files belonging to these engines with a certain name pattern.
  • The deprecated mysql_shutdown() C API function and corresponding COM_SHUTDOWN client/server protocol command have been removed. Instead, use mysql_query() to execute a SHUTDOWN statement.
  • The server no longer performs conversion of pre-MySQL 5.1 database names containing special characters to 5.1 format with the addition of a #mysql50# prefix. Because these conversions are no longer performed, the --fix-db-names and --fix-table-names options for mysqlcheck, the UPGRADE DATA DIRECTORY NAME clause for the ALTER DATABASE statement, and the Com_alter_db_upgrade status variable have been removed.

Upgrades are supported only from one major version to another (for example, 5.0 to 5.1, or 5.1 to 5.5), so there should be little remaining need for conversion of older 5.0 database names to current versions of MySQL. As a workaround, upgrade a MySQL 5.0 installation to MySQL 5.1 before upgrading to a more recent release.

Bugs Fixed(略)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章