Unicode Character Sets CREATE TABLE t (s1 VARCHAR(5) CHARACTER SET utf32 COLLATE utf32_unicode_ci); INSERT INTO t VALUES (0xfffd); /* REPLACEMENT CHARACTER */ INSERT INTO t VALUES (0x010412); /* DESERET CAPITAL LETTER BEE */ INSERT INTO t VALUES (0x010413); /* DESERET CAPITAL LETTER TEE */ SELECT COUNT(DISTINCT s1) FROM t; /* The four characters in the INSERT string are 00000041 # LATIN CAPITAL LETTER A 0001218F # CUNEIFORM SIGN KAB 000121A7 # CUNEIFORM SIGN KISH 00000042 # LATIN CAPITAL LETTER B */ CREATE TABLE t (s1 CHAR(4) CHARACTER SET utf32 COLLATE utf32_unicode_ci); INSERT INTO t VALUES (0x000000410001218f000121a700000042); SELECT HEX(WEIGHT_STRING(s1)) FROM t; The result is 2 because in the MySQL  xxx _unicode_ci  collations, the replacement character has a weight of  0x0dc6 , whereas Deseret Bee and Deseret Tee both have a weight of  0xfffd . (Were the utf32_general_ci  collation used instead, the result is 1 because all three characters have a weight of 0xfffd  in that collation.) An example with cuneiform characters and  WEIGHT_STRING() : The result is: 0E33 FFFD FFFD 0E4A 0E33  and  0E4A  are primary weights as in UCA 4.0.0.  FFFD  is the weight for KAB and also for KISH. The rule that all supplementary characters are equal to each other is nonoptimal but is not expected to cause trouble. These characters are very rare, so it is very rare that a multi-character string consists entirely of supplementary characters. In Japan, since the supplementary characters are obscure Kanji ideographs, the typical user does not care what order they are in, anyway. If you really want rows sorted by the MySQL rule and secondarily by code point value, it is easy: ORDER BY s1 COLLATE utf32_unicode_ci, s1 COLLATE utf32_bin There is a difference between “ordering by the character’s code value”  and “ordering by the character’s binary representation,”  a difference that appears only with  utf16_bin , because of surrogates. Suppose that  utf16_bin  (the binary collation for  utf16 ) was a binary comparison “byte by byte”  rather than “character by character.”  If that were so, the order of characters in  utf16_bin  would differ from the order in  utf8_bin . For example, the following chart shows two rare characters. The first character is in the range  E000 - FFFF , so it is greater than a surrogate but less than a supplementary. The second character is a supplementary. 1976 •For supplementary characters based on UCA versions higher than 4.0.0 (for example, xxx _unicode_520_ci ), supplementary characters do not necessarily all have the same collating weight. Some have explicit weights from the UCA  allkeys.txt  file. Others have weights calculated from this algorithm: aaaa= base + (code >> 15); bbbb= (code & 0x7FFF) | 0x8000; Code point Character utf8 utf16 ---------- --------- ---- ----- 0FF9D HALFWIDTH KATAKANA LETTER N EF BE 9D FF 9D 10384 UGARITIC LETTER DELTA F0 90 8E 84 D8 00 DF 84