MySQL 9.0 發行說明
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);