MySQL 8.4 版本注意事項
utf16 字元集是 ucs2 字元集的延伸，可啟用補充字元的編碼
對於 BMP 字元，
utf16和ucs2具有相同的儲存特性：相同的程式碼值、相同的編碼、相同的長度。對於補充字元，
utf16具有特殊的序列，可使用 32 位元來表示字元。這稱為「代理對」機制：對於大於0xffff的數字，取 10 位元並將其加到0xd800並放入第一個 16 位元字中，再取 10 位元並將其加到0xdc00並放入下一個 16 位元字中。因此，所有補充字元都需要 32 位元，其中前 16 位元是介於0xd800和0xdbff之間的數字，而後 16 位元是介於0xdc00和0xdfff之間的數字。範例位於 Unicode 4.0 文件中的 15.5 代理對區域 一節。
因為 utf16 支援代理對而 ucs2 不支援，因此有一個僅適用於 utf16 的有效性檢查：您不能在沒有下代理對的情況下插入上代理對，反之亦然。例如
INSERT INTO t (ucs2_column) VALUES (0xd800); /* legal */
INSERT INTO t (utf16_column)VALUES (0xd800); /* illegal */對於技術上有效但並非真正 Unicode 的字元（也就是說，Unicode 認為是「未指派的程式碼點」或「私人使用」字元，甚至是像 0xffff 這樣的「非法」字元），沒有有效性檢查。例如，由於 U+F8FF 是 Apple 標誌，因此這是合法的
INSERT INTO t (utf16_column)VALUES (0xf8ff); /* legal */不能期望這些字元對所有人都有相同的意義。
由於 MySQL 必須允許最壞的情況（一個字元需要四個位元組），因此 utf16 欄位或索引的最大長度只有 ucs2 欄位或索引最大長度的一半。例如，MEMORY 資料表索引鍵的最大長度為 3072 個位元組，因此以下陳述式會建立具有 ucs2 和 utf16 欄位最長允許索引的資料表
CREATE TABLE tf (s1 VARCHAR(1536) CHARACTER SET ucs2) ENGINE=MEMORY;
CREATE INDEX i ON tf (s1);
CREATE TABLE tg (s1 VARCHAR(768) CHARACTER SET utf16) ENGINE=MEMORY;
CREATE INDEX i ON tg (s1);