MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って xxx_unicode_ci 照合順序を実装します。 照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt) を使用します。 xxx_unicode_ci 照合では、Unicode 照合アルゴリズムの一部のみがサポートされます。 一部の文字はサポートされておらず、結合マークは完全にサポートされていません。 これは主に、ベトナム語、ヨルバ語、ナバホ語などの一部のより小さな言語に影響します。 結合された文字は、文字列比較で単一の Unicode 文字を使用して書き込まれた同じ文字とは異なるとみなされ、その 2 つの文字の長さは異なるとみなされます (たとえば、CHAR_LENGTH() 関数または結果セットメタデータによって返されます)。

4.0.0 より上位の UCA バージョンに基づく Unicode 照合では、照合名にバージョンが含まれます。 例:

LOWER() および UPPER() 関数は、引数の照合順序に従って大/小文字の折りたたみを実行します。 4.0.0 より大きい Unicode バージョンでのみ大文字と小文字のバージョンを持つ文字は、引数照合で十分な UCA バージョンが使用されている場合にのみ、これらの関数によって変換されます。

UCA 9.0.0 以上に基づく照合は、9.0.0 より前の UCA バージョンに基づく照合より高速です。 また、9.0.0 より前の UCA バージョンに基づく照合で使用される PAD SPACE とは対照的に、NO PAD のパッド属性もあります。 非バイナリ文字列を比較するために、NO PAD 照合順序では、文字列の末尾のスペースは他の文字と同様に扱われます (比較での後続領域の処理 を参照)。

照合のパッド属性を決定するには、PAD_ATTRIBUTE カラムを含む INFORMATION_SCHEMA COLLATIONS テーブルを使用します。 例:

mysql> SELECT COLLATION_NAME, PAD_ATTRIBUTE
       FROM INFORMATION_SCHEMA.COLLATIONS
       WHERE CHARACTER_SET_NAME = 'utf8mb4';
+----------------------------+---------------+
| COLLATION_NAME             | PAD_ATTRIBUTE |
+----------------------------+---------------+
| utf8mb4_general_ci         | PAD SPACE     |
| utf8mb4_bin                | PAD SPACE     |
| utf8mb4_unicode_ci         | PAD SPACE     |
| utf8mb4_icelandic_ci       | PAD SPACE     |
...
| utf8mb4_0900_ai_ci         | NO PAD        |
| utf8mb4_de_pb_0900_ai_ci   | NO PAD        |
| utf8mb4_is_0900_ai_ci      | NO PAD        |
...
| utf8mb4_ja_0900_as_cs      | NO PAD        |
| utf8mb4_ja_0900_as_cs_ks   | NO PAD        |
| utf8mb4_0900_as_ci         | NO PAD        |
| utf8mb4_ru_0900_ai_ci      | NO PAD        |
| utf8mb4_ru_0900_as_cs      | NO PAD        |
| utf8mb4_zh_0900_as_cs      | NO PAD        |
| utf8mb4_0900_bin           | NO PAD        |
+----------------------------+---------------+

NO PAD 照合順序を持つ非バイナリ文字列値 (CHAR、VARCHAR および TEXT) の比較は、末尾の空白に関して他の照合順序とは異なります。 たとえば、'a'と'a 'は、同じ文字列ではなく異なる文字列として比較されます。 これは、utf8mb4 のバイナリ照合を使用して確認できます。 utf8mb4_bin の pad 属性は PAD SPACE ですが、utf8mb4_0900_bin の場合は NO PAD です。 したがって、utf8mb4_0900_bin に関連する操作では末尾にスペースが追加されず、末尾にスペースがある文字列を含む比較は、次の 2 つの照合順序で異なる場合があります:

mysql> CREATE TABLE t1 (c CHAR(10) COLLATE utf8mb4_bin);
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO t1 VALUES('a');
Query OK, 1 row affected (0.01 sec)

mysql> SELECT * FROM t1 WHERE c = 'a ';
+------+
| c    |
+------+
| a    |
+------+
1 row in set (0.00 sec)

mysql> ALTER TABLE t1 MODIFY c CHAR(10) COLLATE utf8mb4_0900_bin;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM t1 WHERE c = 'a ';
Empty set (0.00 sec)

Unicode 照合アルゴリズム (UCA) のみに基づく順序付けが言語に対して適切に機能しない場合、MySQL は言語固有の Unicode 照合を実装します。 言語固有の照合は UCA ベースであり、追加の言語調整ルールがあります。 このようなルールの例は、このセクションの後半で説明します。 特定の言語の順序付けに関する質問については、unicode.org の http://www.unicode.org/cldr/charts/30/collation/index.html に Common Locale Data Repository (CLDR) 照合チャートが用意されています。

たとえば、非言語固有の utf8mb4_0900_ai_ci および言語固有の utf8mb4_LOCALE_0900_ai_ci Unicode 照合には、それぞれ次の特性があります:

次のテーブルに示すロケールコードまたは言語名を含む照合名は、言語固有の照合です。 Unicode 文字セットには、これらの言語の照合順序を含めることができます。

クロアチア語の照合順序は、これらのクロアチア語の文字に合わせて調整されます: Č, Ć, Dž, Đ, Lj, Nj, Š, Ž。

デンマーク語の照合順序は、ノルウェー語にも使用できます。

日本語の場合、utf8mb4 文字セットには utf8mb4_ja_0900_as_cs 照合順序および utf8mb4_ja_0900_as_cs_ks 照合順序が含まれます。 両方の照合でアクセントが区別され、大/小文字が区別されます。また、utf8mb4_ja_0900_as_cs_ks はカタカナ文字をひらがな文字と区別し、utf8mb4_ja_0900_as_cs はカタカナ文字とひらががな文字をソート用に同等として扱います。 日本語照合を必要とするが、kana 感度を必要としないアプリケーションでは、ソートパフォーマンスを向上させるために utf8mb4_ja_0900_as_cs を使用できます。utf8mb4_ja_0900_as_cs ではソートに 3 つの重みレベルが使用され、utf8mb4_ja_0900_as_cs_ks では 4 つが使用されます。

アクセントを区別しない古典ラテン照合の場合、I と J は等しいと比較され、U と V は等しいと比較されます。 I と J、および U と V は、基本文字レベルと同じように比較されます。 つまり、J はアクセント付き I とみなされ、U はアクセント付き V とみなされます。

スペイン語照合は、最新のスペイン語および従来のスペイン語で使用できます。 どちらの場合も、ñ (n-tilde) は n と o の間の個別の文字です。 また、スペイン語 (繁体字) の場合、ch は c と d の間の個別の文字であり、ll は l と m の間の個別の文字です。

スペイン語の従来の照合は、アストゥリア語およびガリシア語にも使用できます。

スウェーデン語照合にはスウェーデン語ルールが含まれます。 たとえば、スウェーデン語には、ドイツ語やフランス語を使用するユーザーでは予期しないような次の関係があります。

Ü = Y < Ö

Unicode 文字セットの場合、xxx_general_ci 照合順序を使用して実行する演算は、xxx_unicode_ci 照合順序のものよりも高速です。 たとえば、utf8_general_ci 照合順序の比較は、utf8_unicode_ci の比較よりも高速ですが、精度は少し低くなります。 これは、utf8_unicode_ci で拡張などのマッピングがサポートされているためです。つまり、一方の文字が他の文字の組合せと等しいと比較される場合です。 たとえば、ßはドイツ語および他の一部の言語の ss と同等です。utf8_unicode_ci では、縮約および無視可能な文字もサポートされています。utf8_general_ci は、拡張、縮小または無視可能な文字をサポートしないレガシー照合です。 文字間で 1 対 1 の比較しかできません。

さらに詳しく説明するために、utf8_general_ci と utf8_unicode_ci の両方で次の等価が保持されています (比較または検索での影響については、セクション10.8.6「照合順序の効果の例」 を参照してください):

Ä = A
Ö = O
Ü = U

照合順序間の違いは、次の式が utf8_general_ci に当てはまるという点です。

ß = s

一方、次の式は、ドイツ語 DIN-1 順序 (辞書順序とも呼ばれます) をサポートする utf8_unicode_ci に当てはまります。

ß = ss

utf8_unicode_ci での順序付けが言語に対して適切に機能しない場合、MySQL は utf8 言語固有の照合を実装します。 たとえば、utf8_unicode_ci は、ドイツ語辞書順序とフランス語には適切に機能するので、特殊な utf8 照合順序を作成する必要はありません。

utf8_general_ci は、ßが ss ではなく s と同等であることを除き、ドイツ語とフランス語の両方にも満足しています。 これがアプリケーションで許容可能な場合は、utf8_general_ci のほうが高速なので、こちらを使用する必要があります。 これが許容できない場合 (たとえば、ドイツ語辞書順序が必要な場合) は、utf8_unicode_ci のほうがより正確なので、こちらを使用してください。

ドイツ語 DIN-2 (電話帳) 順序が必要な場合は、utf8_german2_ci 照合順序を使用してください。これは次の文字セットを等しいものと見なします。

Ä = Æ = AE
Ö = Œ = OE
Ü = UE
ß = ss

utf8_german2_ci は latin1_german2_ci に似ていますが、後者は AE と同等のÆまたは OE と同等のŒを比較しません。 utf8_general_ci で十分であるので、ドイツ語辞書順序のための latin1_german_ci に対応する utf8_german_ci はありません。

文字照合の重みは、次のように決定されます:

照合加重は、WEIGHT_STRING() 関数を使用して表示できます。 (セクション12.8「文字列関数および演算子」を参照してください。) 照合順序で重み参照テーブルが使用されているが、文字がテーブルにない場合 (たとえば、「new」 文字であるため)、照合順序決定はより複雑になります:

「文字のコード値による順序付け」と「文字のバイナリ表現による順序付け」と間には違いがあります。これは、サロゲートのために、utf16_bin でのみ表示される違いです。

utf16_bin (utf16 のバイナリ照合順序) が、「文字ごと」ではなく「バイトごと」のバイナリ比較であったとします。 その場合は、utf16_bin での文字の順序は utf8_bin での順序とは異なります。 たとえば、次の表には 2 つの珍しい文字が示されています。 最初の文字は E000-FFFF の範囲にあるので、サロゲートより大きくなりますが、補助文字より小さくなります。 2 番目の文字は補助文字です。

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

表の 2 つの文字は、0xff9d < 0x10384 であるので、コードポイント値による順序になります。 また、0xef < 0xf0 なので、utf8 値による順序になります。 ただし、0xff > 0xd8 なので、バイトごとの比較を使用する場合は、utf16 値による順序にはなりません。

したがって、MySQL の utf16_bin 照合順序は「バイトごと」にはなりません。 「コードポイントによる」順序になります。 MySQL は、utf16 での補助文字エンコーディングを認識すると、文字のコードポイント値に変換してから比較します。 したがって、utf8_bin と utf16_bin の順序付けは同じになります。 これは、UCS_BASIC 照合順序の SQL:2008 標準の要件に一致します。「UCS_BASIC は、ソートされている文字列の文字の Unicode スカラー値によって、順序付け全体が決定される照合順序です。 これは UCS 文字レパートリーに適用できます。 すべての文字レパートリーは、UCS レパートリーのサブセットなので、UCS_BASIC 照合順序は、すべての文字セットに適用できる可能性があります。 ノート 11: 文字の Unicode スカラー値は、符号なしの整数として扱われるそのコードポイントです。」

文字セットが ucs2 である場合、比較はバイトごとになりますが、いずれにしても、ucs2 文字列にはサロゲートを含めないでください。

xxx_general_mysql500_ci 照合では、元の xxx_general_ci 照合の 5.1.24 より前の順序が保持され、MySQL 5.1.24 より前に作成されたテーブルのアップグレードが許可されます (Bug #27877)。