一文看完MySQL 9.0新特性！

公众号-JavaEdge發表於2024-09-15
MySql

本文總結自 MySQL 8.4 以來，在 MySQL 9.0 中新增、廢棄、更改和刪除的內容。MySQL 9.0 中新增或更改的功能。

1 MySQL 9.0新特性

1 VECTOR 型別支援

MySQL 9.0 支援 VECTOR 列型別。向量是一個資料結構，它由條目列表（4 位元組浮點值）組成，可以表示為二進位制字串值或列表格式字串。VECTOR 列在宣告時需指定最大長度或條目數量（括號內），預設值為 2048，最大值為 16383。

可用以下示例，透過 CREATE TABLE 建立帶有 VECTOR 列的 InnoDB 表：

mysql> CREATE TABLE v1 (c1 VECTOR(5000));
Query OK, 0 rows affected (0.03 sec)

向量列的限制

  • VECTOR 列不能用作任何型別的鍵。這包括主鍵、外來鍵、唯一鍵和分割槽鍵。

  • 某些型別的 MySQL 函式和運算子不接受向量作為引數。這些函式包括但不限於數值函式和運算子、時間函式、全文搜尋函式、XML 函式、位函式和 JSON 函式。

    向量可以與某些但非所有字串和加密函式一起使用

  • VECTOR 不能與任何其他型別進行比較，並且只能與另一個 VECTOR 進行相等性比較

VECTOR_DIM()（也在 MySQL 9.0 中新增）返回向量的長度。提供了用於不同表示之間轉換的函式。STRING_TO_VECTOR()（別名：TO_VECTOR()）採用列表格式表示的向量並返回二進位制字串表示；VECTOR_TO_STRING()（別名：FROM_VECTOR()）執行相反的操作，如下所示：

mysql> SELECT STRING_TO_VECTOR('[2, 3, 5, 7]');
+------------------------------------------------------+
| TO_VECTOR('[2, 3, 5, 7]')                            |
+------------------------------------------------------+
| 0x00000040000040400000A0400000E040                   |
+------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT VECTOR_TO_STRING(0x00000040000040400000A0400000E040);
+------------------------------------------------------+
| VECTOR_TO_STRING(0x00000040000040400000A0400000E040) |
+------------------------------------------------------+
| [2.00000e+00,3.00000e+00,5.00000e+00,7.00000e+00]    |
+------------------------------------------------------+
1 row in set (0.00 sec)

2 內聯和隱式外來鍵約束

MySQL 現在強制執行內聯外來鍵規範，這在以前版本中被解析器接受但忽略。MySQL 9.0 還接受對父表主鍵列的隱式引用。

考慮以下透過該語句建立的父表 person：

CREATE TABLE person (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    name CHAR(60) NOT NULL
);

若要建立具有 person 外來鍵 owner 的表 shirt，MySQL 現在根據標準接受並正確處理以下任何一種 CREATE TABLE 語句：

CREATE TABLE shirt (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    style ENUM('tee', 'polo', 'dress') NOT NULL,
    color ENUM('red', 'blue', 'yellow', 'white', 'black') NOT NULL,
    owner SMALLINT UNSIGNED NOT NULL,
    
    FOREIGN KEY (owner) REFERENCES person (id)
);

CREATE TABLE shirt (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    style ENUM('tee', 'polo', 'dress') NOT NULL,
    color ENUM('red', 'blue', 'yellow', 'white', 'black') NOT NULL,
    owner SMALLINT UNSIGNED NOT NULL,
    
    FOREIGN KEY (owner) REFERENCES person
);

CREATE TABLE shirt (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    style ENUM('tee', 'polo', 'dress') NOT NULL,
    color ENUM('red', 'blue', 'yellow', 'white', 'black') NOT NULL,
    owner SMALLINT UNSIGNED NOT NULL REFERENCES person (id)
);

CREATE TABLE shirt (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    style ENUM('tee', 'polo', 'dress') NOT NULL,
    color ENUM('red', 'blue', 'yellow', 'white', 'black') NOT NULL,
    owner SMALLINT UNSIGNED NOT NULL REFERENCES person
);

以前版本的 MySQL 中，只有上述顯示的第一個語句會建立外來鍵。

3 將 EXPLAIN ANALYZE 的 JSON 輸出儲存到變數中

現在支援將 EXPLAIN ANALYZE 的 JSON 輸出儲存到使用者變數中，語法如下所示：

EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt

隨後可以將該變數作為 MySQL JSON 函式的 JSON 引數使用。INTO 子句僅支援 FORMAT=JSON，且必須顯式指定 FORMAT。此形式的 EXPLAIN ANALYZE 還支援可選的 FOR SCHEMA 或 FOR DATABASE 子句。

注意：僅當 explain_json_format_version 伺服器系統變數設定為 2 時，此功能才可用；否則，嘗試使用它將引發 ER_EXPLAIN_ANALYZE_JSON_FORMAT_VERSION_NOT_SUPPORTED 錯誤（EXPLAIN ANALYZE 在 explain_json_format_version=1 的情況下不支援 FORMAT=JSON）。

4 準備語句中的事件 DDL

從 MySQL 9.0.0 開始，以下語句可以進行準備：

  • CREATE EVENT
  • ALTER EVENT
  • DROP EVENT

這些語句不支援位置引數（? 佔位符）；必須使用字串字面值、系統變數和使用者變數的某種組合來組裝準備語句的文字。一種實現可重用性的方法是，在儲存過程的主體中組裝例如 CREATE EVENT 語句的文字，並將該語句的任何變數部分作為 IN 引數傳遞給儲存過程；使用 PREPARE 準備組裝的文字；使用所需的引數值呼叫過程。

5 效能模式系統變數表

MySQL 9.0 為效能模式新增了兩個表，這些表提供有關伺服器系統變數的資訊。列表如下：

  • variables_metadata 表提供了有關係統變數的一般資訊。此資訊包括 MySQL 伺服器識別的每個系統變數的名稱、範圍、型別、範圍（如果適用）和描述。

    此表中的兩列（MIN_VALUE 和 MAX_VALUE）旨在替換 variables_info 表中已廢棄的列。

  • global_variable_attributes 表提供有關伺服器分配給全域性系統變數的屬性-值對的資訊。

6 EXPLAIN FORMAT=JSON 的增強功能

EXPLAIN FORMAT=JSON 的輸出現在包括有關連線列的資訊。

7 包含 LIMIT 1 的相關子查詢

以前，為了有資格轉換為帶派生表的外部左連線，子查詢不能包含 LIMIT 子句。在 MySQL 9.0 中，此限制略微放寬，使得包含 LIMIT 1 的子查詢現在可以以這種方式進行轉換。

LIMIT 子句必須僅使用字面值 1。如果 LIMIT 子句包含其他值，或者使用佔位符 (?) 或變數，則無法使用子查詢到派生表的轉換進行最佳化。

以下是在 MySQL 9.0 中廢棄的功能：

2 MySQL 9.0 中廢棄的功能

以下功能在 MySQL 9.0 中被廢棄，可能會在未來的版本中被移除。對於顯示的替代方案，應用程式應更新以使用它們。
對於使用在 MySQL 9.0 中被廢棄、在後續版本中移除的功能的應用程式，當從 MySQL 9.0 源複製到執行後續版本的副本時，語句可能會失敗，或者源和副本上的效果可能不同。為了避免這些問題，使用在 9.0 中被廢棄功能的應用程式應進行修訂，以避免使用它們，並在可能的情況下使用替代方案。

效能模式 variables_info 表列

效能模式的 variables_info 表中的 MIN_VALUE 和 MAX_VALUE 列現在被廢棄，並可能在未來的 MySQL 版本中被移除。相反，請使用 variables_metadata 表的列，這些列具有相同的名稱。

更新事務性和非事務性表的事務

MySQL 9.0 廢棄了同時更新事務性表和非事務性或非組合表的事務。這樣的事務現在會在客戶端和錯誤日誌中寫入一個廢棄警告。只有 InnoDB 和 BLACKHOLE 儲存引擎是事務性和組合性的（NDBCLUSTER 是事務性的但不是組合性的）。這意味著只有以下儲存引擎的組合不會引發廢棄警告：

  • InnoDB 和 BLACKHOLE
  • MyISAM 和 Merge
  • performance_schema 和任何其他儲存引擎
  • TempTable 和任何其他儲存引擎

3 MySQL 9.0 中移除的功能

以下專案已過時，並在 MySQL 9.0 中被移除。對於顯示的替代方案，應用程式應更新以使用它們。
對於在 MySQL 8.4 中使用在 MySQL 9.0 中移除的功能的應用程式，當從 MySQL 8.4 源複製到 MySQL 9.0 副本時，語句可能會失敗，或者源和副本上的效果可能不同。為了避免這些問題，使用在 MySQL 9.0 中移除功能的應用程式應進行修訂，以避免使用它們，並在可能的情況下使用替代方案。

mysql_native_password 外掛

MySQL 8.0 中被廢棄的 mysql_native_password 認證外掛已被移除。伺服器現在拒絕來自沒有 CLIENT_PLUGIN_AUTH 能力的舊客戶端程式的 mysql_native 認證請求。
由於這個更改，以下伺服器選項和變數也已移除：

  • --mysql-native-password 伺服器選項
  • --mysql-native-password-proxy-users 伺服器選項
  • default_authentication_plugin 伺服器系統變數

為了向後相容，mysql_native_password 在客戶端仍然可用，這樣 MySQL 9.0 客戶端程式可以連線到早期版本的 MySQL 伺服器。在 MySQL 9.0 中，以前版本的客戶端程式內建的 MySQL 本地認證外掛已轉換為在執行時必須載入的外掛。

關注我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

  • 中央/分銷預訂系統效能最佳化
  • 活動&券等營銷中臺建設
  • 交易平臺及資料中臺等架構和開發設計
  • 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
  • LLM Agent應用開發
  • 區塊鏈應用開發
  • 大資料開發挖掘經驗
  • 推薦系統專案

目前主攻市級軟體專案設計、構建服務全社會的應用系統。

參考：

  • 程式設計嚴選網

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章