Aurora MySQL 的預先檢查描述參考

預先檢查層級：錯誤

結構描述的 mysql check table x for upgrade命令所報告的問題

開始升級至 Aurora MySQL 第 3 版之前， check table for upgrade 會在資料庫執行個體mysql結構描述中的每個資料表上執行。check table for upgrade 命令會檢查資料表是否有任何在升級至較新版本的 MySQL 期間可能發生的潛在問題。在嘗試升級之前執行此命令有助於事先識別和解決任何不相容，使實際的升級程序更順暢。

此命令會對每個資料表執行各種檢查，如下所示：

如需詳細資訊，請參閱 MySQL 文件中的 CHECK TABLE 陳述式。

輸出範例：

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

此預先檢查的輸出取決於遇到的錯誤，以及遇到的時間，因為 會check table for upgrade執行多個檢查。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

預先檢查層級：錯誤

資料表空間資料檔案路徑中的循環目錄參考

從 MySQL 8.0.17 開始， CREATE TABLESPACE ... ADD DATAFILE子句不再允許循環目錄參考。為避免升級問題，請先從資料表空間資料檔案路徑移除任何循環目錄參考，再升級至 Aurora MySQL 第 3 版。

輸出範例：

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

如果您收到此錯誤，請使用file-per-table資料表。對所有資料表空間和資料表定義使用預設檔案路徑。

重建後，預先檢查會通過，允許升級繼續進行。

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

無法具有預設值的資料欄

在 MySQL 8.0.13 之前，BLOB、GEOMETRY、 TEXT和 JSON資料欄不能有預設值。在升級至 Aurora MySQL 第 3 版之前，移除這些資料欄上的任何預設子句。如需這些資料類型預設處理方式變更的詳細資訊，請參閱 MySQL 文件中的資料類型預設值。

輸出範例：

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

預先檢查會傳回錯誤，因為test.test_blob_default資料表中的資料geo_col欄使用具有指定預設值的 BLOB、GEOMETRY、 TEXT或 JSON資料類型。

查看資料表定義，我們可以看到資料geo_col欄定義為 geo_col geometry NOT NULL default ''。

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

移除此預設子句以允許預先檢查通過。

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

預先檢查通過，您可以重試升級。

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

定義中已棄用關鍵字的使用

MySQL 8.0 已移除查詢快取。因此，某些查詢快取特定的 SQL 語法已移除。如果您的任何資料庫物件包含 QUERY CACHE、 SQL_CACHE或 SQL_NO_CACHE關鍵字，則會傳回預先檢查錯誤。若要解決此問題，請重新建立這些物件，移除提及的關鍵字。

輸出範例：

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

預先檢查會報告test.no_query_cache_check預存程序正在使用其中一個已移除的關鍵字。查看程序定義，我們可以看到它使用 SQL_NO_CACHE。

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

移除 關鍵字。

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

移除關鍵字後，預先檢查會成功完成。

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

InnoDB 辨識屬於不同引擎的資料表

與 schemaInconsistencyCheck 類似，此預先檢查會驗證 MySQL 中的資料表中繼資料是否一致，然後再繼續升級。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

輸出範例：

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

預先檢查層級：錯誤

ENUM 和 SET欄定義包含超過 255 個字元的元素

資料表和預存程序不得包含超過 255 個字元或 1020 個位元組的 ENUM 或 SET資料欄元素。在 MySQL 8.0 之前，合併長度上限為 64K，但 8.0 會將個別元素限制為 255 個字元或 1020 個位元組 （支援多位元組）。如果您收到 的預先檢查失敗enumSetElementLengthCheck，請在重試升級之前修改任何超過這些新限制的元素。

輸出範例：

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

預先檢查會報告錯誤，因為test.large_set資料表s中的 欄包含大於 255 個字元的SET元素。

減少此欄SET的大小後，預先檢查會通過，允許升級繼續進行。

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

外部金鑰限制名稱超過 64 個字元

在 MySQL 中，識別符的長度限制為 64 個字元，如 MySQL 文件所述。由於發現外部金鑰長度可能等於或超過此值的問題，導致升級失敗，因此已實作此預先檢查。如果此預先檢查發生錯誤，您應該更改或重新命名限制條件，使其在重試升級之前少於 64 個字元。

輸出範例：

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

資料庫中的所有觸發條件名稱必須是唯一的。

由於資料字典實作的變更，MySQL 8.0 不支援資料庫中區分大小寫的觸發條件。此預先檢查會驗證您的資料庫叢集沒有一或多個包含重複觸發條件的資料庫。如需詳細資訊，請參閱 MySQL 文件中的識別符區分大小寫。

輸出範例：

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

預先檢查會報告錯誤，指出資料庫叢集有兩個具有相同名稱的觸發條件，但使用不同的案例： test.before_insert_product和 test.before_insert_PRODUCT。

升級之前，請重新命名觸發條件或捨棄，然後使用新名稱重新建立觸發條件。

重新命名為 test.before_insert_PRODUCT 後test.before_insert_product_2，預先檢查會成功。

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

的定義器資料欄mysql.event不能為 null 或空白。

DEFINER 屬性指定擁有預存物件定義的 MySQL 帳戶，例如觸發、預存程序或事件。此屬性在您想要控制預存物件執行所在的安全內容的情況下特別有用。建立儲存的物件時，如果DEFINER未指定 ，則預設為建立物件的使用者。

升級至 MySQL 8.0 時，您無法在 MySQL 資料字典中有任何具有 null或空白定義器的儲存物件。如果您有這類預存物件，則會引發預先檢查錯誤。您必須先修正此問題，才能繼續升級。

錯誤範例：

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

預先檢查會傳回test.get_version事件的錯誤，因為它具有null定義器。

若要解決此問題，您可以檢查事件定義。如您所見，定義器為 null或空白。

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

捨棄或重新建立具有有效定義器的事件。

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

現在，預先檢查通過了。

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

預先檢查層級：錯誤

InnoDB 資料字典和實際資料表定義之間的資料欄定義不相符

與 schemaInconsistencyCheck 類似，此預先檢查會先驗證 MySQL 中的資料表中繼資料是否一致，再繼續升級。在此情況下，預先檢查會驗證 InnoDB 資料字典和 MySQL 資料表定義之間的資料欄定義是否相符。如果偵測到不相符，則升級不會繼續。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

輸出範例：

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

預先檢查會報告test.mismatchTable資料表中資料id欄的中繼資料不相符。具體而言，MySQL 中繼資料的欄名稱為 iD，而 InnoDB 的欄名稱則為 id。

預先檢查層級：錯誤

的定義器資料欄information_schema.triggers不能為 null或空白。

預先檢查會驗證您的資料庫沒有使用 null或空白定義器定義的觸發條件。如需預存物件定義器需求的詳細資訊，請參閱 getEventsWithNullDefiner。

輸出範例：

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

預先檢查會傳回錯誤，因為test結構描述中的example_trigger觸發具有null定義器。若要修正此問題，請使用有效的使用者重新建立觸發條件，或捨棄觸發條件來修正定義程式。如需詳細資訊，請參閱 getEventsWithNullDefiner 中的範例。

預先檢查層級：錯誤

lower_case_table_names 參數設定為 時，所有資料庫或資料表名稱都必須是小寫1。

在 MySQL 8.0 之前，資料庫名稱、資料表名稱和其他物件會對應至資料目錄中的檔案，例如檔案型中繼資料 (.frm)。lower_case_table_names 系統變數可讓使用者控制伺服器如何處理資料庫物件的識別符區分大小寫，以及儲存這類中繼資料物件。重新啟動後，可以在已初始化的伺服器上變更此參數。

不過，在 MySQL 8.0 中，雖然此參數仍然控制伺服器如何處理識別符大小寫區分性，但在資料字典初始化後就無法變更。升級或建立 MySQL 8.0 資料庫時，資料字典lower_case_table_names第一次在 MySQL 上啟動時所設定的值會用於該資料庫的生命週期。此限制是實作原子資料字典實作的一部分，其中資料庫物件會從檔案型中繼資料遷移到結構描述中的內部 InnoDB mysql 資料表。

如需詳細資訊，請參閱 MySQL 文件中的資料字典變更。

為了避免在升級期間將檔案型中繼資料更新為新的原子資料字典時發生問題，此預先檢查會驗證 何時lower_case_table_names = 1將所有資料表以小寫儲存在磁碟上。如果沒有，則會傳回預先檢查錯誤，而且您必須先更正中繼資料，才能繼續升級。

輸出範例：

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

因為資料表test.TEST包含大寫字母，但lower_case_table_names設定為 ，所以傳回錯誤1。

若要解決此問題，您可以重新命名資料表以使用小寫，或修改資料庫叢集上的 lower_case_table_names 參數，然後再開始升級。

預先檢查層級：錯誤

已移除GROUP BY ASC/DESC語法的使用

從 MySQL 8.0.13 DESC 開始，已移除 GROUP BY子句的已棄用ASC或語法。依賴GROUP BY排序的查詢現在可能會產生不同的結果。若要取得特定的排序順序，請改用 ORDER BY子句。如果資料庫中有任何物件使用此語法，您必須在重試升級之前，使用 ORDER BY子句重新建立物件。如需詳細資訊，請參閱 MySQL 文件中的 SQL 變更。

輸出範例：

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

預先檢查層級：錯誤

檢查常式中使用的已棄用.<table>語法。

在 MySQL 8.0 中，常式無法再包含已取代的識別符語法 (\".<table>\")。如果任何儲存的常式或觸發條件包含這類識別符，則升級會失敗。例如，不再允許下列.dot_table參考：

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

重新建立常式和觸發程序以使用正確的識別符語法和逸出之後，預先檢查會通過，而且升級可以繼續進行。如需識別符的詳細資訊，請參閱 MySQL 文件中的結構描述物件名稱。

輸出範例：

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

預先檢查會傳回test資料庫中incorrect_procedure常式的錯誤，因為它包含已棄用的語法。

修正常式後，預先檢查會成功，您可以重試升級。

預先檢查層級：錯誤

檢查索引是否太大而無法在高於 5.7 的 MySQL 版本上運作

對於精簡或備援資料列格式，不應能夠建立字首大於 767 位元組的索引。不過，在 MySQL 5.7.35 版之前，這是可能的。如需詳細資訊，請參閱 MySQL 5.7.35 版本備註。

升級到 MySQL 8.0 後，任何受此錯誤影響的索引都將無法存取。此預先檢查會識別必須在允許升級繼續之前重建的違規索引。

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

預先檢查會傳回錯誤，因為test.table_with_large_idx資料表包含資料表上的索引，其使用大於 767 個位元組的精簡或備援資料列格式。升級到 MySQL 8.0 後，這些資料表將變得無法存取。在繼續升級之前，請執行下列其中一項操作：

在這裡，我們重建資料表以解決預先檢查失敗。重建資料表之前，請確定 innodb_file_format 設定為 Barracuda，且 innodb_default_row_format 設定為 dynamic。這些是 MySQL 5.7 中的預設值。如需詳細資訊，請參閱 MySQL 文件中的 InnoDB 資料列格式和 InnoDB 檔案格式管理。

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

重建資料表後，預先檢查會通過，而且升級可以繼續。

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

檢查 MySQL 5.7 中使用的無效資料表和結構描述名稱

遷移至 MySQL 8.0 中的新資料字典時，您的資料庫執行個體不能包含以 開頭的結構描述或資料表。 #mysql50#如果有任何這類物件存在，升級會失敗。若要解決此問題，請針對傳回的結構描述和資料表執行 mysqlcheck。

輸出範例：

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

預先檢查會報告結構描述#mysql50#fix_db_names的名稱無效。

修正結構描述名稱後，預先檢查會通過，允許升級繼續進行。

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

檢查 5.7 中的孤立常式

遷移至 MySQL 8.0 中的新資料字典時，如果資料庫中有任何存放程序不再存在結構描述，升級會失敗。此預先檢查會驗證資料庫執行個體上預存程序中參考的所有結構描述是否仍然存在。若要允許繼續升級，請捨棄這些預存程序。

輸出範例：

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

預先檢查會報告dropped_db資料庫中的get_version預存程序是孤立的。

若要清除此程序，您可以重新建立缺少的結構描述。

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

重新建立結構描述之後，您可以捨棄 程序，以允許升級繼續進行。

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

結構描述中的資料表名稱與 MySQL mysql 8.0 中的新資料表衝突

MySQL 8.0 中引入的新原子資料字典會將所有中繼資料存放在結構描述中的一組內部 InnoDB mysql 資料表中。在升級期間，會在mysql結構描述中建立新的內部資料字典資料表。為了避免命名衝突，這會導致升級失敗，預先檢查會檢查mysql結構描述中的所有資料表名稱，以確保沒有任何新的資料表名稱已在使用中。如果是，則會傳回錯誤，而且不允許繼續升級。

輸出範例：

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

因為結構描述tablespaces中有名為 mysql 的資料表，所以傳回錯誤。這是 MySQL 8.0 中新的內部資料字典資料表名稱之一。您必須在升級之前使用 RENAME TABLE命令重新命名或移除任何這類資料表。

預先檢查層級：錯誤

使用具有非原生分割之引擎的分割資料表

根據 MySQL 8.0 文件，兩個儲存引擎目前提供原生分割支援：InnoDB 和 NDB。其中，Aurora MySQL 第 3 版僅支援 InnoDB，與 MySQL 8.0 相容。使用任何其他儲存引擎在 MySQL 8.0 中建立分割資料表的任何嘗試都會失敗。此預先檢查會在資料庫叢集中尋找使用非原生分割的資料表。如果傳回任何 ，您必須移除分割或將儲存引擎轉換為 InnoDB。

輸出範例：

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

在這裡，MyISAM 資料表正在使用分割，這需要 動作才能繼續升級。

預先檢查層級：錯誤

舊時間類型的使用

「舊暫時」是指在 MySQL 5.5 版和更低版本中建立的暫時類型資料欄 （例如 TIMESTAMP和 DATETIME)。在 MySQL 8.0 中，會移除對這些舊時間資料類型的支援，這表示如果資料庫包含這些舊時間類型，就無法從 MySQL 5.7 就地升級至 8.0。若要修正此問題，您必須先重建任何包含這類舊時間日期類型的資料表，才能繼續升級。

如需有關在 MySQL 5.7 中棄用舊暫時資料類型的詳細資訊，請參閱此部落格。如需在 MySQL 8.0 中移除舊暫時資料類型的詳細資訊，請參閱此部落格。

輸出範例：

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

會針對資料表 timestamp_column中的資料欄 報告錯誤test.55_temporal_table，因為它使用不再支援的舊暫存磁碟儲存格式。

若要解決此問題並允許繼續升級，請重建資料表，將舊的暫存磁碟儲存格式轉換為 MySQL 5.6 中引入的新格式。如需詳細資訊和先決條件，請參閱 MySQL 文件中的在 3 位元組和 4 位元組 Unicode 字元集之間轉換。

執行下列命令來重建此預先檢查中提到的資料表，會將舊時間類型轉換為較新的格式，精確度為分數秒。

ALTER TABLE ... ENGINE=InnoDB;

如需重建資料表的詳細資訊，請參閱 MySQL 文件中的 ALTER TABLE 陳述式。

在重建有問題的資料表並重新啟動升級之後，相容性檢查會通過，讓升級繼續進行。

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

在共用資料表空間中使用分割資料表

從 MySQL 8.0.13 開始，已移除在共用資料表空間中放置資料表分割區的支援。升級之前，請將任何這類資料表從共用資料表空間移至file-per-table空間。

輸出範例：

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

預先檢查失敗，因為p1來自資料表的分割區test.partInnoDBTable位於系統資料表空間中。

若要解決此問題，請重建test.partInnodbTable資料表，將違規分割區放在file-per-table空間p1中。

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

執行此操作後，預先檢查會通過。

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

從最新 MySQL 版本中移除的函數使用

在 MySQL 8.0 中，已移除許多內建函數。此預先檢查會檢查您的資料庫是否有可能使用這些函數的物件。如果找到它們，則會傳回錯誤。您必須在重試升級之前解決問題。

移除的大多數函數都是空間函數，已被同等ST_*函數取代。在這些情況下，您可以修改資料庫物件以使用新的程序命名。如需詳細資訊，請參閱 MySQL 文件中的 Features Removed in MySQL 8.0 (MySQL 8.0 中移除的功能)。

輸出範例：

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

預先檢查會報告test.GetLocationsInPolygon預存程序正在使用兩個已移除的函數：POLYGONFROMTEXT 和 POINTFROMTEXT。它也建議您使用新的 ST_POLYGONFROMTEXT 和 ST_POINTFROMTEXT 取代。使用建議重新建立程序後，預先檢查會成功完成。

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

MySQL 語法檢查類似常式的物件

MySQL 8.0 引進先前未保留的預留關鍵字。升級預先檢查程式會評估資料庫物件名稱及其定義和內文中預留關鍵字的使用情況。如果它偵測到資料庫物件中使用的預留關鍵字，例如預存程序、函數、事件和觸發，則升級會失敗，並發佈錯誤至 upgrade-prechecks.log 檔案。若要解決此問題，您必須先更新這些物件定義，並在升級之前以單引號 (') 括住任何這類參考。如需有關在 MySQL 中逸出保留字的詳細資訊，請參閱 MySQL 文件中的字串常值。

或者，您可以將名稱變更為不同的名稱，這可能需要應用程式變更。

輸出範例：

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
         "level": "Error",
         "dbObject": "test.select_res_word",
         "description": "at line 2,18: unexpected token 'except'",
         "dbObjectType": "Routine"
      }
  ]
}

若要修正此問題，請檢查常式定義。

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

程序使用名為 的資料表except，這是 MySQL 8.0 中的新關鍵字。透過逸出字串常值來重新建立程序。

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

預先檢查現在通過。

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檔案移除或損毀所造成的結構描述不一致

如前所述，MySQL 8.0 引入了原子資料字典，該字典會將所有中繼資料存放在結構描述中的一組內部 InnoDB mysql 資料表中。這個新架構提供交易、ACID 合規的方式來管理資料庫中繼資料，從舊的檔案型方法解決「原子 DDL」問題。在 MySQL 8.0 之前，如果 DDL 操作意外中斷，結構描述物件可能會變得孤立。在升級期間將檔案型中繼資料遷移至新的原子資料字典資料表，可確保資料庫執行個體中沒有這類孤立結構描述物件。如果遇到任何孤立的物件，升級會失敗。

為了協助在啟動升級之前偵測這些孤立物件，會執行schemaInconsistencyCheck預先檢查，以確保所有資料字典中繼資料物件都同步。如果偵測到任何孤立的中繼資料物件，則不會繼續升級。若要繼續升級，請清除這些孤立的中繼資料物件。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

輸出範例：

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

預先檢查會報告test.schemaInconsistencyCheck_failure資料表的中繼資料不一致。在此情況下，資料表存在於 InnoDB 儲存引擎中繼資料 (information_schema.INNODB_SYS_TABLES) 中，但不存在於 MySQL 中繼資料 () 中information_schema.TABLES。

預先檢查層級：錯誤

檢查與 Aurora DDL 復原功能相關的成品

作為 Aurora MySQL 中資料定義語言 (DDL) 復原實作的一部分，傳輸中 DDL 陳述式的中繼資料會保留在結構描述中的 ddl_log_md_table和 mysql ddl_log_table資料表中。第 3 版以後不支援 Aurora 的 DDL 復原實作，因為此功能是 MySQL 8.0 中新原子資料字典實作的一部分。如果您在相容性檢查期間執行任何 DDL 陳述式，此預先檢查可能會失敗。我們建議您在沒有 DDL 陳述式執行時嘗試升級。

如果此預先檢查失敗，而沒有任何執行中的 DDL 陳述式，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

如果有任何 DDL 陳述式正在執行，預先檢查輸出會列印下列訊息：

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

輸出範例：

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

由於與相容性檢查同時執行的傳輸中 DDL，預先檢查傳回錯誤。建議您在未執行任何 DDLs的情況下重試升級。

預先檢查層級：錯誤

檢查mysql.rds_upgrade_prechecks資料表是否存在

這是 RDS 服務執行的僅限內部預先檢查。升級時會自動處理任何錯誤，並且可以安全地忽略。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查與 Aurora 快速 DDL 功能相關的成品

快速 DDL 最佳化是在 Aurora MySQL 第 2 版的實驗室模式中推出，以提高某些 DDL 操作的效率。在 Aurora MySQL 第 3 版中，實驗室模式已移除，快速 DDL 實作已由名為 Instant DDL 的 MySQL 8.0 功能取代。

升級至 Aurora MySQL 第 3 版之前，任何在實驗室模式中使用快速 DDL 的資料表都必須透過執行 OPTIMIZE TABLE或 ALTER TABLE ... ENGINE=InnoDB命令來重建，以確保與 Aurora MySQL 第 3 版的相容性。

此預先檢查會傳回任何此類資料表的清單。重建傳回的資料表之後，您可以重試升級。

輸出範例：

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

預先檢查會報告資料表test.test有待定的快速 DDL 操作。

若要允許繼續升級，您可以重建資料表，然後重試升級。

mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)

重建資料表後，預先檢查會成功。

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

具有懸置FULLTEXT索引參考的資料表

在 MySQL 5.6.26 之前，在捨棄全文搜尋索引之後，隱藏的 FTS_DOC_ID和 FTS_DOC_ID_INDEX資料欄可能會變得孤立。如需詳細資訊，請參閱錯誤編號 76012。

如果您在發生這種情況的舊版 MySQL 上建立任何資料表，可能會導致升級至 Aurora MySQL 第 3 版失敗。此預先檢查會驗證資料庫叢集上沒有這類孤立或「懸置」的全文索引，然後再升級至 MySQL 8.0。如果此預先檢查失敗，請重建包含此類懸置全文索引的任何資料表。

輸出範例：

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_fts_index",
        "description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
      }
  ]
},

預先檢查會報告test.table_with_fts_index資料表的錯誤，因為它包含懸置的全文索引。若要允許繼續升級，請重建資料表以清除全文索引輔助資料表。使用 OPTIMIZE TABLE test.table_with_fts_index 或 ALTER TABLE test.table_with_fts_index, ENGINE=INNODB。

重建資料表後，預先檢查會通過。

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

檢查與ibd檔案路徑相關的不一致

此預先檢查僅適用於 Aurora MySQL 3.03.0 版及更低版本。如果此預先檢查發生錯誤，請升級至 Aurora MySQL 3.04 版或更新版本。

輸出範例：

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查空格 ID 為零的全文索引

在 MySQL 中，當您將全文索引新增至 InnoDB 資料表時，會建立多個輔助索引資料表空間。由於在 5.6.20 版中修正的舊版 MySQL 發生錯誤，這些輔助索引資料表可能在系統資料表空間中建立，而不是在自己的 InnoDB 資料表空間中建立。

如果有任何這類輔助資料表空間存在，升級將會失敗。重新建立預先檢查錯誤中提到的全文索引，然後重試升級。

輸出範例：

{
  "id": "auroraUpgradeCheckForFtsSpaceIdZero",
  "title": "Check for fulltext index with space id as zero",
  "status": "OK",
  "description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.fts_space_zero_check",
        "description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
      }
  ]
},

預先檢查會報告test.fts_space_zero_check資料表的錯誤，因為它在系統資料表空間中有輔助全文搜尋 (FTS) 資料表。

在您捨棄並重新建立與此資料表相關聯的 FTS 索引後，預先檢查會成功。

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

預先檢查層級：錯誤

檢查 XA 交易是否處於預備狀態

執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須進行乾淨的關機。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。由於交易復原是必要的，因此如果您的資料庫有任何 XA 交易處於預備狀態，它可以封鎖清除的關機，使其無法繼續。因此，如果偵測到任何準備好的 XA 交易，在您採取動作遞交或轉返之前，升級將無法繼續。

如需使用 尋找處於預備狀態的 XA 交易的詳細資訊XA RECOVER，請參閱 MySQL 文件中的 XA 交易 SQL 陳述式。如需 XA 交易狀態的詳細資訊，請參閱 MySQL 文件中的 XA 交易狀態。

輸出範例：

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
      }
  ]
}

此預先檢查會報告錯誤，因為有交易處於預備狀態，應遞交或復原。

登入資料庫後，您可以檢查 information_schema.innodb_trx 資料表和XA RECOVER輸出以取得詳細資訊。

mysql> select trx_started,
    trx_mysql_thread_id,
    trx_id,trx_state,
    trx_operation_state,
    trx_rows_modified,
    trx_rows_locked 
from 
    information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started         | trx_mysql_thread_id | trx_id  | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 |                   0 | 2849470 | RUNNING   | NULL                |                 1 |               0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)

mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        1 |            6 |            0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)

在這種情況下，我們會轉返準備好的交易。

mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)

在復原 XA 交易之後，預先檢查會成功。

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查目前執行個體類別是否支援升級

目前不支援從寫入器資料庫執行個體類別為 db.r6i.32xlarge 的 Aurora MySQL 2.12.0 或 2.12.1 版執行就地升級。在這種情況下，預先檢查會傳回錯誤。若要允許繼續升級，您可以將資料庫執行個體類別變更為 db.r6i.24xlarge 或更小。或者，您可以升級至 Aurora MySQL 2.12.2 版或更新版本，其中 db.r6i.32xlarge 支援就地升級至 Aurora MySQL 第 3 版。

輸出範例：

{
  "id": "auroraUpgradeCheckForInstanceLimit",
  "title": "Checks if upgrade is supported on the current instance class",
  "status": "OK",
  "description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
      }
  ]
},

預先檢查會傳回錯誤，因為寫入器資料庫執行個體正在使用 db.r6i.32xlarge 執行個體類別，且在 Aurora MySQL 2.12.1 版上執行。

預先檢查層級：錯誤

檢查 8.0 內部使用者

此預先檢查僅適用於 Aurora MySQL 3.03.0 版及更低版本。如果此預先檢查發生錯誤，請升級至 Aurora MySQL 3.04 版或更新版本。

輸出範例：

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查 RDS 主要使用者是否存在

MySQL 8 已新增支援角色和動態權限的新權限模型，讓權限管理更容易且更精細。作為此變更的一部分，Aurora MySQL 引進了新的 rds_superuser_role，該 會在從 Aurora MySQL 第 2 版升級至第 3 版時自動授予資料庫的主要使用者。

如需 Aurora MySQL 中指派給主要使用者的角色和權限的詳細資訊，請參閱 主要使用者帳戶權限。如需 Aurora MySQL 第 3 版中角色型權限模型的詳細資訊，請參閱 角色型權限模型。

此預先檢查會驗證主要使用者是否存在於資料庫中。如果主要使用者不存在，預先檢查會失敗。若要允許繼續升級，請重設主要使用者密碼或手動建立使用者，以重新建立主要使用者。然後重試升級。如需重設主要使用者密碼的詳細資訊，請參閱 變更資料庫主要使用者的密碼。

輸出範例：

{
  "id": "auroraUpgradeCheckForMasterUser",
  "title": "Check if master user exists",
  "status": "OK",
  "description": "Throws error if master user has been dropped!",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
      }
  ]
}

重設主要使用者密碼後，預先檢查將會通過，而且您可以重試升級。

下列範例使用 AWS CLI 重設密碼。密碼變更會立即套用。

aws rds modify-db-cluster \
    --db-cluster-identifier my-db-cluster \
    --master-user-password my-new-password

然後，預先檢查成功。

{
  "id": "auroraUpgradeCheckForMasterUser",
  title": "Check if master user exists",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查字首索引上的幾何資料欄

從 MySQL 8.0.12 開始，您無法再使用 GEOMETRY 資料類型在資料欄上建立字首索引。如需詳細資訊，請參閱 WL#11808。

如果有任何這類索引存在，您的升級將會失敗。若要解決此問題，請在預先檢查失敗時提及的資料表上捨棄字首GEOMETRY索引。

輸出範例：

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.geom_index_prefix",
        "description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
      }
  ]
}

預先檢查會報告錯誤，因為test.geom_index_prefix資料表包含欄上有字首 的索引GEOMETRY。

捨棄此索引後，預先檢查會成功。

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查預存程序中與特殊字元相關的不一致

在 MySQL 8.0 之前，資料庫名稱、資料表名稱和其他與資料目錄中的檔案對應的物件，也就是檔案型中繼資料。在升級至 MySQL 8.0 mysql 的過程中，所有資料庫物件都會遷移至存放在結構描述中的新內部資料字典資料表，以支援新實作的原子資料字典。在遷移預存程序的過程中，會驗證每個程序的程序定義和內文，因為它會擷取到新的資料字典中。

在 MySQL 8 之前，在某些情況下，可以建立預存常式，或直接插入mysql.proc資料表中包含特殊字元的程序。例如，您可以建立預存程序，其中包含不合規、不中斷空間字元 的註解\xa0。如果遇到任何此類程序，升級會失敗。

此預先檢查會驗證預存程序的內文和定義不包含任何這類字元。若要允許繼續升級，請重新建立這些預存程序，不要有任何隱藏或特殊字元。

輸出範例：

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "description": "Following procedure(s) has special characters inconsistency.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "information_schema.routines",
        "description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
      }
  ]
}

預先檢查會報告資料庫叢集get_version_proc在test資料庫中包含名為 的程序，其中包含程序內文中的特殊字元。

捨棄並重新建立預存程序後，預先檢查會成功，讓升級繼續進行。

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "detectedProblems": []
},

預先檢查層級：錯誤

檢查sys結構描述的物件類型不符

sys 結構描述是 MySQL 資料庫中的一組物件和檢視，可協助使用者疑難排解、最佳化和監控其資料庫執行個體。從 Aurora MySQL 第 2 版升級至第 sys 3 版時，結構描述檢視會重新建立並更新為新的 Aurora MySQL 第 3 版定義。

在升級過程中，如果sys結構描述中的任何物件是使用儲存引擎 (sys_config/BASE TABLE在 INFORMATION_SCHEMA.TABLES 中) 而非檢視來定義，則升級將會失敗。您可以在 資料表中找到這類information_schema.tables資料表。這不是預期的行為，但在某些情況下，可能會因使用者錯誤而發生。

此預先檢查會驗證所有sys結構描述物件，以確保它們使用正確的資料表定義，並且不會將檢視錯誤地定義為 InnoDB 或 MyISAM 資料表。若要解決問題，請重新命名或捨棄任何傳回的物件，以手動修正這些物件。然後重試升級。

輸出範例：

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "description": "Database contains objects with type mismatch for sys schema.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "sys.waits_global_by_latency",
        "description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
      }
  ]
}

預先檢查報告sys結構描述中的 sys.waits_global_by_latency 檢視的類型不符，導致無法繼續升級。

登入資料庫執行個體後，您可以看到此物件在應該是檢視時定義為 InnoDB 資料表。

mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
       Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
  `events` varchar(128) DEFAULT NULL,
  `total` bigint(20) unsigned DEFAULT NULL,
  `total_latency` text,
  `avg_latency` text,
  `max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

若要解決此問題，我們可以捨棄並重新建立具有正確定義的檢視，或重新命名檢視。在升級過程中，系統會自動使用正確的資料表定義建立它。

mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)

執行此操作後，預先檢查會通過。

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查檢視中資料欄名稱的上限

MySQL 中資料欄名稱的允許長度上限為 64 個字元。在 MySQL 8.0 之前，在某些情況下，可以建立資料欄名稱大於 64 個字元的檢視。如果您的資料庫執行個體上存在任何此類檢視，則會傳回預先檢查錯誤，且升級將會失敗。若要允許繼續升級，您必須重新建立有問題的檢視，確保其資料欄長度小於 64 個字元。然後重試升級。

輸出範例：

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "description": "Following view(s) has column(s) with length greater than 64.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
        "description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
      }
  ]
}

預先檢查會報告test.colname_view_test檢視包含的資料欄col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad超過允許的資料欄長度上限 64 個字元。

查看檢視定義，我們可以看到違規的資料欄。

mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field                                                            | Type        | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1                                                             | varchar(20) | YES  |     | NULL    |       |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11)     | YES  |     | NULL    |       |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

若要允許繼續升級，請重新建立檢視，確保資料欄長度不超過 64 個字元。

mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)

mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)

mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1       | varchar(20) | YES  |     | NULL    |       |
| col2_nopad | int(11)     | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

執行此操作後，預先檢查會成功。

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查在小型資料欄上定義字首長度大於 255 位元組之索引的資料表

在 MySQL 中使用二進位資料類型在資料欄上建立索引時，您必須在索引定義中新增字首長度。在 MySQL 8.0 之前，在某些情況下，您可以指定大於此類資料類型允許大小上限的字首長度。例如 TINYTEXT和 TINYBLOB欄，其中允許的資料大小上限為 255 個位元組，但允許大於此值的索引字首。如需詳細資訊，請參閱 MySQL 文件中的 InnoDB 限制。

如果此預先檢查失敗，請捨棄違規的索引，或將索引的 TINYTEXT和 TINYBLOB資料欄的字首長度減少到少於 255 個位元組。然後重試升級。

輸出範例：

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.tintxt_prefixed_index.col1",
        "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
      }
  ]
}

預先檢查會報告test.tintxt_prefixed_index資料表的錯誤，因為其索引PRIMARY的字首在 TINYTEXT 或 TINYBLOB 資料欄上大於 255 個位元組。

查看此資料表的定義，我們可以看到主索引鍵在資料TINYTEXT欄 上有 65 的字首col1。因為資料表是使用utf8mb4字元集來定義，每個字元可存放 4 個位元組，所以字首超過 255 個位元組的限制。

mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
       Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
  `col1` tinytext NOT NULL,
  `col2` tinytext,
  `col_id` tinytext,
  PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)

使用utf8mb4字元集將索引字首修改為 63 將允許繼續升級。

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD  PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

執行此操作後，預先檢查會成功。

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：錯誤

檢查mysql.host資料表缺少 InnoDB 中繼資料不一致

這是 RDS 服務執行的僅限內部預先檢查。升級時會自動處理任何錯誤，並且可以安全地忽略。

如果您在此預先檢查中遇到任何錯誤，請向 AWS Support 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。

預先檢查層級：錯誤

檢查 utf8mb3 資料欄註解是否無效

此預先檢查會識別包含資料欄註解的資料表，其中包含無效的 utf8mb3 字元編碼。在 MySQL 8.0 中，更嚴格的驗證會套用至中繼資料中的字元編碼，包括資料欄註解。如果任何資料欄註解包含 utf8mb3 字元集中無效的字元，升級將會失敗。

此問題最常見的原因是資料欄註解中存在非 BMP （基本多語言平面） 字元。非 BMP 字元需要 4 位元組 UTF-8 編碼 (utf8mb4)，但 utf8mb3 僅支援 3 位元組序列，無法代表這些字元。

若要解決此問題，您必須在嘗試升級之前修改資料欄註解，以移除或取代任何非 BMP 字元。您可以使用 ALTER TABLE陳述式來更新欄註解。

輸出範例：

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.t2",
        "description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
      }
  ]
}

預先檢查會報告test.t2資料表在一或多個資料欄註解中包含無效的 utf8mb3 字元，特別是因為存在非 BMP 字元。

若要解決此問題，您可以識別有問題的資料欄並更新其註解。首先，檢查資料表結構以使用註解識別資料欄：

mysql> SHOW CREATE TABLE test.t2\G

使用有問題的註解識別資料欄後，請使用 ALTER TABLE陳述式更新資料欄。例如：

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';

或者，您可以完全移除註解：

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';

更新所有有問題的欄位註解後，預先檢查將會通過，而且升級可以繼續：

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：警告

新的預設身分驗證外掛程式考量事項

在 MySQL 8.0 中，引進了caching_sha2_password身分驗證外掛程式，提供比已棄用mysql_native_password外掛程式更安全的密碼加密和更好的效能。對於 Aurora MySQL 第 3 版，用於資料庫使用者的預設身分驗證外掛程式是mysql_native_password外掛程式。

此預先檢查會警告將會移除此外掛程式，並在未來的主要版本版本中變更預設值。在此變更之前，請考慮評估應用程式用戶端和使用者的相容性。

如需詳細資訊，請參閱 MySQL 文件中的 caching_sha2_password 相容性問題和解決方案。

輸出範例：

{
  "id": "defaultAuthenticationPlugin",
  "title": "New default authentication plugin considerations",
  "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},

預先檢查層級：警告

使用過時的MAXDBsql_mode旗標

在 MySQL 8.0 中，移除了一些已棄用的 sql_mode 系統變數選項https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html，其中一個是 MAXDB。此預先檢查會檢查所有目前連線的工作階段，以及常式和觸發條件，以確保沒有任何 sql_mode 設定為任何包含 的組合MAXDB。

輸出範例：

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.maxdb_stored_routine",
        "description": "PROCEDURE uses obsolete MAXDB sql_mode",
        "dbObjectType": "Routine"
      }
  ]
}

預先檢查會報告test.maxdb_stored_routine常式包含不支援sql_mode的選項。

登入資料庫後，您可以在sql_mode包含 的常式定義中看到 MAXDB。

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

若要解決此問題，請在用戶端sql_mode上設定正確的 之後重新建立程序。

在沒有不支援的 的情況下重新建立程序sql_mode。

mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
    -> SQL SECURITY DEFINER
    -> BEGIN
    ->     SELECT * FROM test;
    -> END$$
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

預先檢查成功。

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "detectedProblems": []
}

預先檢查層級：警告

檢查物件名稱中是否已棄用單一美元符號

從 MySQL 8.0.32 開始，使用貨幣符號 ($) 做為未引用識別符的第一個字元已棄用。如果您有包含 $做為第一個字元的任何結構描述、資料表、檢視、資料欄或常式，此預先檢查會傳回警告。雖然此警告不會阻止升級繼續進行，但我們建議您儘快採取動作來解決此問題。從 MySQL 8.4，任何這類識別符都會傳回語法錯誤，而不是警告。

輸出範例：

{
  "id": "mysqlDollarSignNameCheck",
  "title": "Check for deprecated usage of single dollar signs in object names",
  "status": "OK",
  "description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.$deprecated_syntx",
        "description": " name starts with $ sign."
      }
  ]
},

預先檢查會報告警告，因為test結構描述中的$deprecated_syntx資料表包含 $做為第一個字元。

預先檢查層級：警告

使用名稱與新預留關鍵字衝突的資料庫物件

此檢查類似於 routineSyntaxCheck，因為它會檢查名稱與新預留關鍵字衝突的資料庫物件使用情況。雖然它們不會封鎖升級，但您需要仔細評估警告。

輸出範例：

使用上一個範例搭配名為 的資料表except，預先檢查會傳回警告：

{
  "id": "reservedKeywordsCheck",
  "title": "Usage of db objects with names conflicting with new reserved keywords",
  "status": "OK",
  "description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.except",
        "description": "Table name",
        "dbObjectType": "Table"
      }
  ]
}

此警告可讓您知道可能有一些應用程式查詢需要檢閱。如果您的應用程式查詢未正確逸出字串常值，則升級到 MySQL 8.0 後可能會發生錯誤。檢閱您的應用程式，以確認、測試第 3 版上執行之 Aurora MySQL 資料庫叢集的複製或快照。

升級後將失敗的非逸出應用程式查詢範例：

SELECT * FROM escape;

升級後會成功的正確逸出應用程式查詢範例：

SELECT * FROM 'escape';

預先檢查層級：警告

utf8mb3 字元集的使用

在 MySQL 8.0 中，utf8mb3字元集已棄用，並將在未來 MySQL 主要版本中移除。如果偵測到使用此字元集的任何資料庫物件，則會實作此預先檢查以引發警告。雖然這不會阻止升級繼續進行，但強烈建議您考慮將資料表遷移到utf8mb4字元集，這是 MySQL 8.0 的預設值。如需 utf8mb3 和 utf8mb4 的詳細資訊，請參閱 MySQL 文件中的在 3 位元組和 4 位元組 Unicode 字元集之間轉換。

輸出範例：

{
  "id": "utf8mb3",
  "title": "Usage of utf8mb3 charset",
  "status": "OK",
  "description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.t1.col1",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      },
      {
        "level": "Warning",
        "dbObject": "test.t1.col2",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      }
  ]
}

若要解決此問題，您可以重建參考的物件和資料表。如需詳細資訊和先決條件，請參閱 MySQL 文件中的在 3 位元組和 4 位元組 Unicode 字元集之間轉換。

預先檢查層級：警告

零日期、日期時間和時間戳記值

MySQL 現在會對日期、日期時間和時間戳記資料欄使用零值強制執行更嚴格的規則。我們建議您使用 NO_ZERO_IN_DATE和 NO_ZERO_DATE SQL 模式搭配 strict 模式，因為它們將在未來 MySQL 版本中與 strict 模式合併。

如果執行預先檢查時任何資料庫連線sql_mode的設定不包含這些模式，則預先檢查中會引發警告。使用者仍然可以插入包含零值的日期、日期時間和時間戳記值。不過，我們強烈建議將任何零值取代為有效值，因為其行為可能會在未來變更，而且可能無法正常運作。由於這是警告，因此不會封鎖升級，但建議您開始規劃採取行動。

輸出範例：

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
  ]
}

預先檢查層級：警告

檢查叢集的復原區段歷史記錄清單長度是否很高

如 auroraUpgradeCheckForIncompleteXATransactions 所述，在執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須經過乾淨的關閉。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。

如果您的資料庫叢集具有高復原區段歷史記錄清單長度 (HLL)，可能會延長 InnoDB 完成復原日誌記錄清除所需的時間，導致主要版本升級程序期間延長停機時間。如果預先檢查偵測到資料庫叢集上的 HLL 很高，則會引發警告。雖然這不會阻止您的升級繼續進行，但我們建議您密切監控資料庫叢集上的 HLL。將其保持在低層級可減少主要版本升級期間所需的停機時間。如需監控 HLL 的詳細資訊，請參閱 InnoDB 歷史記錄清單長度顯著增加。

輸出範例：

{
  "id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
  "title": "Checks if the rollback segment history length for the cluster is high",
  "status": "OK",
  "description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_metrics",
        "description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
      }
  ]
}

預先檢查會傳回警告，因為它偵測到資料庫叢集 (82989114) 上的 InnoDB 復原 HLL 很高。雖然升級會繼續進行，但視要清除的復原數量而定，它可以延長升級程序所需的停機時間。

我們建議您在生產環境中執行升級之前，先調查資料庫叢集上開啟的交易，以確保您的 HLL 保持在可管理的大小。

預先檢查層級：警告

檢查是否有許多未遞交的資料列修改

如 auroraUpgradeCheckForIncompleteXATransactions 中所述，在執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須經過乾淨的關閉。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。

如果您的資料庫叢集有已修改大量資料列的交易，則可能會延長 InnoDB 在清除關機程序中完成此交易轉返所需的時間。如果預先檢查找到長時間執行的交易，且資料庫叢集上有大量修改的資料列，則會引發警告。雖然這不會阻止您的升級繼續進行，但我們建議您密切監控資料庫叢集上作用中交易的大小。將其保持在低層級可減少主要版本升級期間所需的停機時間。

輸出範例：

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_trx",
        "description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
      }
  ]
},

預先檢查會報告資料庫叢集包含具有 11，000，000 個未遞交資料列變更的交易，這些變更需要在清除關機程序期間復原。升級會繼續進行，但為了減少升級程序期間的停機時間，建議您在生產叢集上執行升級之前監控並調查此問題。

若要檢視寫入器資料庫執行個體上的作用中交易，您可以使用 information_schema.innodb_trx 資料表。下列寫入器資料庫執行個體的查詢會顯示資料庫叢集的目前交易、執行時間、狀態和修改的資料列。

# Example of uncommitted transaction
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 |                         1592 |                          20041 | 52866130 | RUNNING   |      11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)

# Example of transaction rolling back
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state    | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 |                         1719 |                          20041 | 52866130 | ROLLING BACK |      10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)

在遞交或復原交易之後，預先檢查不會再傳回警告。在轉返任何大型交易之前，請參閱 MySQL 文件和您的應用程式團隊，因為轉返可能需要一些時間才能完成，具體取決於交易大小。

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "detectedProblems": []
},

如需有關最佳化 InnoDB 交易管理，以及在 MySQL 資料庫執行個體上執行和復原大型交易的潛在影響的詳細資訊，請參閱 MySQL 文件中的最佳化 InnoDB 交易管理。

預先檢查層級：通知

使用過時的sql_mode旗標

除了 之外MAXDB，還移除了許多其他sql_mode選項：DB2、MSSQL、MYSQL323、MYSQL40ORACLE、、POSTGRESQLNO_FIELD_OPTIONS、 NO_KEY_OPTIONS和 NO_TABLE_OPTIONS。從 MySQL 8.0 開始，這些值都無法指派給sql_mode系統變數。如果此預先檢查使用這些sql_mode設定尋找任何開啟的工作階段，請確定已更新資料庫執行個體和資料庫叢集參數群組，以及用戶端應用程式和組態以停用它們。- 如需詳細資訊，請參閱 MySQL 文件。

輸出範例：

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

若要解決任何這些預先檢查失敗，請參閱 maxdbFlagCheck。

預先檢查層級：錯誤、警告或通知

check table x for upgrade命令報告的問題

開始升級至 Aurora MySQL 第 3 版之前， check table for upgrade 會在資料庫叢集的使用者結構描述中的每個資料表上執行。此預先檢查與 checkTableMysqlSchema 不同。

此check table for upgrade命令會檢查資料表是否有任何在升級至較新版本的 MySQL 期間可能發生的潛在問題。在嘗試升級之前執行此命令有助於事先識別和解決任何不相容，使實際的升級程序更順暢。

此命令會對每個資料表執行各種檢查，如下所示：

與其他預先檢查不同，它可能會根據check table輸出傳回錯誤、警告或通知。如果此預先檢查傳回任何資料表，請在啟動升級之前仔細檢閱它們，以及傳回程式碼和訊息。如需詳細資訊，請參閱 MySQL 文件中的 CHECK TABLE 陳述式。

我們在這裡提供錯誤範例和警告範例。

錯誤範例：

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.parent",
        "description": "Table 'test.parent' doesn't exist"
      }
  ]
},

預先檢查會報告test.parent資料表不存在的錯誤。

寫入器資料庫執行個體mysql-error.log的檔案顯示有外部金鑰錯誤。

2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

登入寫入器資料庫執行個體並執行 show engine innodb status\G以取得外部金鑰錯誤的詳細資訊。

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.

LATEST FOREIGN KEY ERROR 訊息報告test.child資料表中參考test.parent資料表的fk_pname外部索引鍵限制條件缺少索引或資料類型不相符。有關外部金鑰限制條件的 MySQL 文件指出外部金鑰中參考的資料欄必須具有相關聯的索引，且父/子資料欄必須使用相同的資料類型。

若要驗證這是否與缺少索引或資料類型不符有關，請登入資料庫，並暫時停用工作階段變數 foreign_key_checks 來檢查資料表定義。這麼做之後，我們可以看到有問題的子限制條件 (fk_pname) 使用 p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL 來參考父資料表 name varchar(20) NOT NULL。父資料表使用 DEFAULT CHARSET=utf8，但子資料表的資料p_name欄使用 latin1，因此擲回資料類型不相符錯誤。

mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)

mysql> show create table parent\G
*************************** 1. row ***************************
       Table: parent
Create Table: CREATE TABLE `parent` (
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

若要解決此問題，我們可以將子資料表變更為使用與父系相同的字元集，或將父系變更為使用與子系資料表相同的字元集。在這裡，由於子資料表在p_name資料欄定義latin1中明確使用 ，因此我們執行 ALTER TABLE 將字元集修改為 utf8。

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)

執行此操作後，預先檢查會通過，而且升級可以繼續。

警告範例：

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.orders",
        "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
      }
  ]
}

預先檢查會報告test.orders資料表上delete_audit_trigg觸發條件的警告，因為它沒有 CREATED 屬性。根據 MySQL 文件中的檢查版本相容性，此訊息是資訊性的，並針對在 MySQL 5.7.2 之前建立的觸發程序進行列印。

由於這是警告，因此不會封鎖升級以繼續。不過，如果您想要解決問題，您可以重新建立有問題的觸發程序，而且預先檢查會成功，沒有警告。

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},