MySQLサーバにはサーバキャラクタセットとサーバ照合順序があります。サーバキャラクタセットとサーバ照合順序は、サーバ起動時に設定でき、ランタイムで変更できます。

サーバのキャラクタセットと照合順序は、mysqldの起動時に使用するオプションに依存します。--character-set-serverをキャラクタセットに対して使用でき、--collation-serverを照合順序に対して追加することもできます。キャラクタセットを指定しないのは、--character-set-server=latin1を指定した場合と同じです。キャラクタセット（例えばlatin1)のみを指定して照合順序を指定しないのは、--character-set-server=latin1 --collation-server=latin1_swedish_ciを指定した場合と同じです。これはlatin1_swedish_ciがlatin1のデフォルト照合順序であるためです。したがって、以下の 3 つのコマンドを実行すると、いずれも同じ結果になります。

shell> mysqld
shell> mysqld --character-set-server=latin1
shell> mysqld --character-set-server=latin1 \
           --collation-server=latin1_swedish_ci

設定を変更する手段の 1 つは再コンパイルです。ソースからのビルド時にデフォルトのサーバキャラクタセットと照合順序を変更するには、--with-charsetと--with-collationをconfigureの引数として使用してください。例：

shell> ./configure --with-charset=latin1

または

shell> ./configure --with-charset=latin1 \
           --with-collation=latin1_german1_ci

mysqldとconfigureでは、キャラクタセットと照合順序の組み合わせが有効かどうかチェックされます。組み合わせが有効でない場合、各プログラムによってエラーメッセージが表示され、強制終了されます。

最新のサーバキャラクタセットと照合順序は、character_set_serverおよびcollation_serverのシステム変数値で決定されます。これらの変数はランタイムで変更可能です。

各データベースにはデータベースキャラクタセットとデータベース照合順序があります。CREATE DATABASEおよびALTER DATABASEステートメントには、データベースのキャラクタセットと照合順序を指定するためのオプション節があります。

CREATE DATABASE db_name
    [[DEFAULT] CHARACTER SET charset_name]
    [[DEFAULT] COLLATE collation_name]

ALTER DATABASE db_name
    [[DEFAULT] CHARACTER SET charset_name]
    [[DEFAULT] COLLATE collation_name]

SCHEMAというキーワードはDATABASEの代わりに使用できます。

すべてのデータベースオプションは、データベースディレクトリ内のdb.optというテキストファイルに保存されます。

CHARACTER SETおよびCOLLATE節で、キャラクタセットと照合順序が異なる複数のデータベースを同一のMySQLサーバ上に作成することができます。

例：

CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci;

MySQL では、データベースキャラクタセットとデータベース照合順序が次のように選択されます。

テーブルのキャラクタセットと照合順序がCREATE TABLEステートメントに指定されていない場合、データベースのキャラクタセットと照合順序はデフォルト値として使用されます。これらに他の用途はありません。

デフォルトのデータベースに対するキャラクタセットと照合順序は、character_set_databaseおよびcollation_databaseのシステム変数値によって決定されます。デフォルトのデータベースが変わるたびに、サーバはこれらの変数を設定します。デフォルトのデータベースがない場合、変数は、character_set_serverおよびcollation_serverといったサーバレベルのシステム変数と同値になります。

各テーブルにはテーブルキャラクタセットとテーブル照合順序があります。CREATE TABLEおよびALTER TABLEステートメントには、テーブルのキャラクタセットと照合順序を指定するためのオプション節があります。

CREATE TABLE tbl_name (column_list)
    [[DEFAULT] CHARACTER SET charset_name] [COLLATE collation_name]]

ALTER TABLE tbl_name
    [[DEFAULT] CHARACTER SET charset_name] [COLLATE collation_name]

例：

CREATE TABLE t1 ( ... ) CHARACTER SET latin1 COLLATE latin1_danish_ci;

MySQL では、テーブルキャラクタセットとテーブル照合順序が次のように選択されます。

カラムのキャラクタセットと照合順序が個別のカラム定義に指定されていない場合、テーブルのキャラクタセットと照合順序はデフォルト値として使用されます。テーブルのキャラクタセットと照合順序は MySQL 拡張であり、同等の機能は標準 SQL に存在しません。

各「文字」（CHAR、VARCHARまたはTEXT型)にはカラムキャラクタセットとカラム照合順序があります。カラム定義構文には、カラムキャラクタセットとカラム照合順序を指定するためのオプション節があります。

col_name {CHAR | VARCHAR | TEXT} (col_length)
    [CHARACTER SET charset_name] [COLLATE collation_name]

例：

CREATE TABLE Table1
(
    column1 VARCHAR(5) CHARACTER SET latin1 COLLATE latin1_german1_ci
);

MySQL では、カラムキャラクタセットとカラム照合順序が次のように選択されます。

CHARACTER SETおよびCOLLATE節は標準SQLです。

各文字列リテラルにはキャラクタセットと照合順序があります。

文字列リテラルでは、オプションとしてキャラクタセットイントロデューサとCOLLATE節を指定することができます。

[_charset_name]'string' [COLLATE collation_name]

例：

SELECT 'string';
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

単純なステートメントSELECT 'string'に対して、文字列にはcharacter_set_connectionおよびcollation_connectionシステム変数で定義されたキャラクタセットと照合順序が存在します。

_charset_nameは形式上イントロデューサと呼ばれています。指定すると、「キャラクタセットXの文字列が後続する」ことがパーサに通知されます。上記はユーザの混乱を招いていたため、ここで強調しておきますが、イントロデューサは変換の原因にはならず、文字列の値が変更されないことを示すにすぎません。標準的な16進リテラルおよび数値16進リテラルの表記（x'literal'および0xnnnn)の前でも、イントロデューサは有効です。

例：

SELECT _latin1 x'AABBCC';
SELECT _latin1 0xAABBCC;

MySQLでは、リテラルのキャラクタセットおよび照合順序が次のように決定されます。

例：

キャラクタセットイントロデューサとCOLLATE節は、標準SQLの指定に基づいて提供されています。

イントロデューサは後続の文字列に対してキャラクタセットを指定しますが、現在のところ、その文字列におけるパーサのエスケーププロセス内容までは変更しません。エスケープは常に、character_set_connectionに指定されたキャラクタセットに従ってパーサが実行します。

以下の例は、イントロデューサが存在してもcharacter_set_connectionによるエスケーププロセスが生じる場合についてです。例ではSET NAMES(character_set_connectionを変更する項9.4. 「接続のキャラクタセットおよび照合順序」), を用いてHEX() ファンクションを使い結果文字列を表示させることで、正確文字列の内容を確認することができます。.

例１：

mysql> SET NAMES latin1;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT HEX('a\n'), HEX(_sjis'a\n');
+------------+-----------------+
| HEX('a\n') | HEX(_sjis'a\n') |
+------------+-----------------+
| E00A       | E00A            | 
+------------+-----------------+
1 row in set (0.00 sec)

ここでは ‘a’ (16進E0) の後に‘\n’ニューラインのエスケープシーケンスが続きます。エスケープシーケンスはcharacter_set_connectionlatin1 の値を使い、新しいリテラルニューラインを作成します。（16進 0A)。これは2番目の文字列にも起こります。つまり、_sjisのイントロデューサはパーサのエスケーププロセスに影響を及ぼしません。

例2：

mysql> SET NAMES sjis;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT HEX('a\n'), HEX(_latin1'a\n');
+------------+-------------------+
| HEX('a\n') | HEX(_latin1'a\n') |
+------------+-------------------+
| E05C6E     | E05C6E            | 
+------------+-------------------+
1 row in set (0.04 sec)

ここでは character_set_connection は sjisになります。このキャラクタセットは次のシーケンス‘a’ と‘\’ (hex values 05 and 5C)がつづく、 有効なマルチバイトキャラクタです。よって、文字列の最初の2バイトは1つのsjis キャラクタとして実行され、‘\’ はエスケープキャラクタとし実行されない。次の‘n’ (16進値6E) はエスケープシーケンスの一部として実行されません。これは第2文字列にとっても同様に、_latin1のイントロデューサはエスケーププロセッシングに影響しません。

標準SQL ではNCHARまたはNATIONAL CHARが、事前定義キャラクタセットがCHARカラムで使用されるように指定する方法のひとつとして使われています。MySQLでは5.1utf8事前定義キャラクタセットとして使用されます。例えば、以下のデータタイプ宣言は等価です：

CHAR(10) CHARACTER SET utf8
NATIONAL CHARACTER(10)
NCHAR(10)

これらと同じように：

VARCHAR(10) CHARACTER SET utf8
NATIONAL VARCHAR(10)
NCHAR VARCHAR(10)
NATIONAL CHARACTER VARYING(10)
NATIONAL CHAR VARYING(10)

N'literal'を使用して、各国キャラクタセットの文字列を 作成することができます。以下の二つのステートメントは等価です

SELECT N'some text';
SELECT _utf8'some text';

バージョン4.1以前のMySQLにキャラクタセットをアップグレードするには、5.1 MySQL 3.23, 4.0, 4.1 リファレンスマニュアルを参照してください。.

MySQL でデフォルトのキャラクタセットと照合順序の値がどのように決定されるかを、以下の例で示します。

例1テーブルとカラム定義

CREATE TABLE t1
(
    c1 CHAR(10) CHARACTER SET latin1 COLLATE latin1_german1_ci
) DEFAULT CHARACTER SET latin2 COLLATE latin2_bin;

ここではlatin1キャラクタセットとlatin1_german1_ci照合順序がカラムに指定されています。定義は明示的なので、直接的といえます。なお、latin1カラムの保存先がlatin2テーブルになっていることに問題はありません。

例2テーブルとカラム定義

CREATE TABLE t1
(
    c1 CHAR(10) CHARACTER SET latin1
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

ここでは、latin1 キャラクタセットとデフォルトしょうごうじゅんじょがカラムに指定されています。自然な指定に目増すが、デフォルト照合順序はテーブルレベルから取り込まれません。latin1 のデフォルト照合順序は常にlatin1_swedish_ciです。したがって、カラムc1にはlatin1_swedish_ci の照合順序ではなく、latin1_danish_ciの照合順序が設定されます。

例3テーブルとカラム定義

CREATE TABLE t1
(
    c1 CHAR(10)
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

ここでは、デフォルトキャラクタセットとデフォルト照合順序がカラムに指定されています。この場合に MySQL では、テーブルレベルまで検索してカラムのキャラクタセットと照合順序が決定されます。したがって、カラム c1 のキャラクタセットはlatin1、照合順序はlatin1_danish_ciとなります。.

例4データベース、テーブル＋カラム定義

CREATE DATABASE d1
    DEFAULT CHARACTER SET latin2 COLLATE latin2_czech_ci;
USE d1;
CREATE TABLE t1
(
    c1 CHAR(10)
);

キャラクタセットと照合順序を指定せずにカラムを作成します。テーブルレベルのキャラクタセットと照合順序も指定しません。この場合に MySQLでは、データベースレベルまでさかのぼって処理が決定されます。（データベースの設定はテーブルの設定になり、そしてカラムの設定になります。）したがって、カラム c1 のキャラクタセットはlatin1、照合順序はlatin1_czech_ciとなります。

MaxDB 互換性に関し、以下の二つのステートメントは同じです。

CREATE TABLE t1 (f1 CHAR(N) UNICODE);
CREATE TABLE t1 (f1 CHAR(N) CHARACTER SET ucs2);

COLLATE 節では、比較に対するデフォルト照合順序が何であれ、無効にすることができます。SQLステートメントのさまざまな個所でCOLLATE を使用することができます。以下に例を示します。

COLLATE節は優先順位が高いため(||よりも高い)、下記の２つの式は等価となります。

x || y COLLATE z
x || (y COLLATE z)

BINARYオペレータは2進性の文字列に続く文字列を送信します。キャラクタ毎よりも、バイト毎の比較を強制的に行う簡単な方法です。BINARYは後続のスペースにも重要な意味を持たせます。

mysql> SELECT 'a' = 'A';
        -> 1
mysql> SELECT BINARY 'a' = 'A';
        -> 0
mysql> SELECT 'a' = 'a ';
        -> 1
mysql> SELECT BINARY 'a' = 'a ';
        -> 0

BINARY strはCAST(str AS BINARY)の略でもあります。

キャラクタカラム定義のBINARY性質は別の効果があります。BINARY性質で定義されたキャラクタカラムはカラムのキャラクタセットの二進節を割り当てられます。全てのキャラクタセットに二進節があります。例えば、latin1 キャラクタセットの二進節はlatin1_binです。よってデフォルトキャラクタセットがlatin1の場合、下記の2カラムの定義は等価になります。

CHAR(10) BINARY
CHAR(10) CHARACTER SET latin1 COLLATE latin1_bin

BINARYのカラム性質としての効果はMySQL4.1．の時のそれと効果に違いがあります。以前、BINARYは結果二進文字列として扱われたカラムになりました。二進文字列は、キャラクタセットや照合順序のないバイトの列で、二進照合順序のある非二審キャラクタ文字列とは違います。両文字列にとって、比較は文字列のユニットの数値をもって行われます。しかし非二審文字列にとってはユニットはキャラクタであり、キャラクタセットの中にはマルチバイトキャラクタを許容しているものもあります。 項10.4.2. 「BINARY と VARBINARY タイプ」.

CHARACTER SET binaryのCHAR、VARCHARあるいはTEXTカラム定義での使用は二進性のデータタイプとしてカラムを扱うことになります。例えば、下記の定義は等価です

CHAR(10) CHARACTER SET binary
BINARY(10)

VARCHAR(10) CHARACTER SET binary
VARBINARY(10)

TEXT CHARACTER SET binary
BLOB

大多数のクエリでは、MySQL がどの照合順序により比較演算を行うかは明確になっています。たとえば以下の場合、照合順序がカラムx のカラム照合順序'' になることは明らかです。

SELECT x FROM T ORDER BY x;
SELECT x FROM T WHERE x = x;
SELECT DISTINCT x FROM T;

ただし、複数のオペランドが使用されていると、あいまいになることがあります。例：

SELECT x FROM T WHERE x = 'Y';

xの照合順序と文字列リテラル'Y'の照合順序のどちらがこのクエリで使用されるのでしょうか

標準 SQL では、「''強制可能''」ルールと呼ばれていた方法で上記の問題を解決しました。これについては、以下の発想が基本となっていますxと'Y' の両方に照合順序があるので、どちらの照合順序を優先するかを判断しなければならない。複雑な問題だが、これらのルールでほとんどの状況に対応できる。

先行する優先順位の値は現MySQLのものである。5.1

これらのルールによって、あいまいさは次のように解消されます。

例：

COERCIBILITY()ファンクションで文字列表現の優先順位が決定できます。

mysql> SELECT COERCIBILITY('A' COLLATE latin1_swedish_ci);
        -> 0
mysql> SELECT COERCIBILITY(VERSION());
        -> 3
mysql> SELECT COERCIBILITY('A');
        -> 4

詳しくはこちらをを参照してください。項11.10.3. 「情報関数」

各キャラクタセットには 1 つ以上の照合順序があり、各照合順序は 1 つのキャラクタセットに関連付けられていることを思い出してください。したがって、次のステートメントはエラーになります。latin2_bin照合順序は latin1キャラクタセットに対して有効でないからです。

mysql> SELECT _latin1 'x' COLLATE latin2_bin;
ERROR 1253 (42000): COLLATION 'latin2_bin' is not valid
for CHARACTER SET 'latin1'

テーブル Tのカラム Xに以下のlatin1カラムの値が設定されているとします。

Muffler
Muller
MX Systems
MySQL

さらに、以下のステートメントを使用してカラムの値を取得したとします。

SELECT X FROM T ORDER BY X COLLATE collation_name;

この表は、複数の異なった照合順序を ORDER BY節で使用した結果の一例です。

例では、2 個の点が上に付いている U が問題の原因です(u)。この文字をドイツでは「ウムラウト」と呼んでいますが、私たちは分音記号付きの U と呼んでいます。

MySQL には、文字列を返す多数の演算子と関数があります。このセクションでは。そのような文字列のキャラクタセットと照合順序について解説しています。

文字列の入力を取得して文字列の結果を出力として返す単純な関数では、出力のキャラクタセットおよび照合順序は主要な入力のキャラクタセットおよび照合順序と同じです。たとえば UPPER(X)は、キャラクタセットおよび照合が Xと一致する文字列を返します。同じことはいかについても当てはまります。INSTR()、 LCASE()、LOWER()、 LTRIM()、MID()、 REPEAT()、 REPLACE()、 REVERSE()、 RIGHT()、 RPAD()、 RTRIM()、SOUNDEX()、 SUBSTRING()、TRIM()、 UCASE() そして UPPER()。

注:REPLACE()関数は他のすべての関数とは異なり、文字列入力の照合順序を無視し、大文字と小文字が区別される比較を毎回実行します。

入力文字列あるいはファンクションの結果がバイナリ文字列の場合、キャラクタセットあるいは照合順序に対する文字列はありません。これはCHARSET()とCOLLATION()ファンクションを使ってチェックすることができます。両ファンクションとも、引数がバイナリ文字列であると明示するためbinaryを返します。

mysql> SELECT CHARSET(BINARY 'a'), COLLATION(BINARY 'a');
+---------------------+-----------------------+
| CHARSET(BINARY 'a') | COLLATION(BINARY 'a') |
+---------------------+-----------------------+
| binary              | binary                |
+---------------------+-----------------------+

複数の文字列入力を組み合わせて単一の文字列出力を返す操作には、標準SQLの「集約ルール」が適用されます。

例えば、CASE ... WHEN a THEN b WHEN b THEN c COLLATE X END と指定されている場合、結果照合順序は Xになります。同じことは以下についても当てはまりますUNION、||、CONCAT()、ELT()、GREATEST()、IF()、LEAST()。

文字データを変換する操作のため、結果文字列のキャラクタセットと照合順序はcharacter_set_connectionとcollation_connectionシステム変数値によって定義されています。.このことは以下についてのみ当てはまります。CAST()、CONV()、FORMAT()、HEX()、SPACE()。

もし文字列ファンクションに返された結果のキャラクタセットや照合順序にたいして不明の場合、確かめるためにCHARSET()またはCOLLATE()ファンクションを使用してください。

mysql> SELECT USER(), CHARSET(USER()), COLLATION(USER());
+----------------+-----------------+-------------------+
| USER()         | CHARSET(USER()) | COLLATION(USER()) |
+----------------+-----------------+-------------------+
| test@localhost | utf8            | utf8_general_ci   | 
+----------------+-----------------+-------------------+

CONVERT() を使用すると、異なるキャラクタセット間でデータを変換することができます。構文は以下のとおりです。

CONVERT(expr USING transcoding_name)

MySQL では、トランスコーディング名は対応するキャラクタセット名と同じです。

例：

SELECT CONVERT(_latin1'Muller' USING utf8);
INSERT INTO utf8table (utf8column)
    SELECT CONVERT(latin1field USING utf8) FROM latin1table;

CONVERT(... USING ...) は、標準SQLの仕様に基づき実装されています。

CAST() を使用し、文字列を別のキャラクタセットに変換することもできます。構文は以下のとおりです。

CAST(character_string AS character_data_type CHARACTER SET charset_name)

例：

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8);

CAST()woCHARACTER SETの指定なしで使用した場合、キャラクタセットと照合順序はcharacter_set_connectionとcollation_connectionのシステム変数で定義されます。CAST()をCHARACTER SET Xの指定ありで使用した場合、キャラクタセットはX、照合順序はXのデフォルト照合順序になります。

COLLATE節をCAST()の内部で使用することはできませんが外部では使用することができます。したがってCAST(... COLLATE ...)無効ですが、CAST(...) COLLATE ...は有効です。

例：

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8) COLLATE utf8_bin;

複数のSHOW ステートメントからキャラクタセットの追加情報が得られます。これらの中にはSHOW CHARACTER SET、SHOW COLLATION、SHOW CREATE DATABASE、 SHOW CREATE TABLE そしてSHOW COLUMNSが含まれます。これらのステートメントを以下に簡単に挙げます。

さらに詳しい情報が必要な場合は、次を参照してください項12.5.4. 「SHOW 構文」。

INFORMATION_SCHEMA にはSHOWステートメントで表示される情報に類似した複数のテーブルが含まれます。例えば、CHARACTER_SETSおよびCOLLATIONS テーブルはSHOW CHARACTER SETおよびSHOW COLLATIONで表示される情報を含みます。 章?21. INFORMATION_SCHEMA データベース.

SHOW CHARACTER SETコマンドは全ての有効なキャラクタセットを示します。どのキャラクタセット名を整合させるかはオプションのLIKE節が使用されます。例：

mysql> SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | cp1252 West European        | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+

SHOW COLLATIONからの出力は全ての有効なキャラクタセットを含みます。.どの照合順序名を整合させるかはオプションのLIKE節が使用されます。例：

mysql> SHOW COLLATION LIKE 'latin1%';
+-------------------+---------+----+---------+----------+---------+
| Collation         | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1  |  5 |         |          |       0 |
| latin1_swedish_ci | latin1  |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci  | latin1  | 15 |         |          |       0 |
| latin1_german2_ci | latin1  | 31 |         | Yes      |       2 |
| latin1_bin        | latin1  | 47 |         | Yes      |       0 |
| latin1_general_ci | latin1  | 48 |         |          |       0 |
| latin1_general_cs | latin1  | 49 |         |          |       0 |
| latin1_spanish_ci | latin1  | 94 |         |          |       0 |
+-------------------+---------+----+---------+----------+---------+

SHOW CREATE DATABASEは指定されたデータベースを作成するCREATE DATABASEステートメントを示します。

mysql> SHOW CREATE DATABASE test;
+----------+-----------------------------------------------------------------+
| Database | Create Database                                                 |
+----------+-----------------------------------------------------------------+
| test     | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------+-----------------------------------------------------------------+

COLLATE節が表示されていなければキャラクタセットのデフォルト照合順序が適用されます。

SHOW CREATE TABLE は類似していますが、CREATE TABLE既存のテーブルを作成するためのステートメントを表示します。カラム定義はキャラクタセット仕様を指定し、テーブルオプションはキャラクタセット情報を含んでいます。

SHOW COLUMNSステートメントはSHOW FULL COLUMNSとして実行された場合、テーブルカラムの照合順序を表示します。CHAR、VARCHAR、またはTEXTデータ型を含むカラムには照合順序があります。ニューメリックと他の文字列の存在しない型には照合順序がありません(Collation値としてNULLで表示されます）。例：

mysql> SHOW FULL COLUMNS FROM person\G
*************************** 1. row ***************************
     Field: id
      Type: smallint(5) unsigned
 Collation: NULL
      Null: NO
       Key: PRI
   Default: NULL
     Extra: auto_increment
Privileges: select,insert,update,references
   Comment:
*************************** 2. row ***************************
     Field: name
      Type: char(60)
 Collation: latin1_swedish_ci
      Null: NO
       Key:
   Default:
     Extra:
Privileges: select,insert,update,references
   Comment:

キャラクタセットは表示の一部ではなく照合順序名で示されます。

MySQLにはキャラクタセットが 2 つ存在します。これらのキャラクタセットを使用し、約 650 の言語でテキストを保存することができます。

注：ucs2_roman_ciとutf8_roman_ciの照合順序では、IとJおよびU とV は等価として比較されます。

ucs2_hungarian_ciとutf8_hungarian_ci の照合順序はMySQL 5.1.5で追加されています。

MySQL はutf8_unicode_ci照合順序を、以下に示されるhttp://www.unicode.org/reports/tr10/Unicode 照合順序アルゴリズム(UCA) によって実行されます。照合順序ではバージョン-4.0.0 UCAのウェイトキーが使用されます。http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt 以下ではutf8_unicode_ciを使用しますが、ucs2_unicode_ciに対しても有効です。

現在、utf8_unicode_ci照合順序はUnicode 照合順序アルゴリズムを部分的にのみサポートしています。中にはまだサポートされていない文字もあります。また、結合マークは完全にはサポートされていません。このことはベトナム語を中心に、ロシア内のマイノリティ言語に影響します。

utf8_unicode_ci主な特徴は、拡張をサポートしていることです。それは1つの文字が他の文字のコンビネーションと等価であると比較された場合です。例えば、ドイツ語や他の言語では、‘s’ は‘ss’に相当します。

utf8_general_ciは拡張をサポートしないレガシー照合順序です。文字間で1対１の比較しかできません。つまり、utf8_general_ci照合順序に対する比較の方が早いが、utf8_unicode_ciに比べてわずかに正確性が劣ります。

例えば、以下の等式がutf8_general_ciとutf8_unicode_ciにおいて証明されます。

A = A
O = O
U = U

照合順序間の違いはutf8_general_ciに対して有効です。

s = s

utf8_unicode_ciにとって有効である場合：

s = ss

MySQL がutf8キャラクタセットに対する特定言語の照合順序を実行するのはutf8_unicode_ci内での順序が言語に対してうまく機能しないときだけです。 例えば、utf8_unicode_ciはドイツ語とフランス語では正しく機能するので、これら２言語に対する特定のutf8照合順序を作成する必要はありません。

utf8_general_ciもドイツ語・フランス語ともに有効ですが、ただし‘s’は‘s’と等価であり、‘ss’と等価ではありません。これが使用しているアプリケーションに対して可能な場合、utf8_general_ciの方が早いのでこちらをお勧めします。それ以外の場合、utf8_unicode_ciを使うほうがより正確です。

utf8_swedish_ciは他のutf8 特定言語の照合順序のように、追加言語ルールとともにutf8_unicode_ciから由来します。例えば、スウェーデン語ではドイツ語やフランス語を使用するユーザでは予期しないような以下の関係が有効です

U = Y < O

utf8_spanish_ciとutf8_spanish2_ci照合順序は現代スペイン語および従来のスペイン語に対しても同様に対応します。両照合順序において‘n’ (n-tilde)は、 ‘n’や‘o’とは区別すべき文字です。さらに従来のスペイン語では‘ch’ は‘c’と‘d’は区別すべき文字であり、‘ll’は‘l’と‘m’とも区別すべき文字です。

西ヨーロッパのキャラクタセットには、大部分の西ヨーロッパ言語（フランス語、スペイン語、カタロニア語、バスク語、ポルトガル語、イタリア語、アルバニア語、オランダ語、ドイツ語、デンマーク語、スウェーデン語、ノルウェー語、フィンランド語、フェロー語、アイスランド語、アイルランド語、スコットランド語、英語など）が含まれています。

MySQLではチェコ、スロバキア、ハンガリー、ルーマニア、スロベニア、クロアチア、ポーランドで使用されるキャラクタセットも一部サポートされています。

MｙSQLでは南ヨーロッパや中東、アルメニア語、アラビア語、グルジア語、ギリシャ語、ヘブライ語、トルコ語のキャラクタセットがサポートされています。

バルト語に含まれるキャラクタセットにはエストニア語、ラトビア語、そしてリトアニア言語が含まれます。

ベラルーシ語、ブルガリア語、ロシア語、ウクライナ語と共に使用するキリル語のキャラクタセットおよび照合順序を以下に示します。

サポートされているアジアのキャラクタセットには、中国語、日本語、韓国語、タイ語が含まれています。これらは複雑な場合があります。たとえば、中国語のキャラクタセットは数千種類の文字に対応していなければなりません。 cp932 およびsjisキャラクタセットについてのさらに詳しい情報は次を参照してください。項9.10.7.1. 「cp932のキャラクタセット」

MySQLのアジアのキャラクタセットに関する一般的な質問や問題のサポートについては、次を参照してください。項A.12. 「MySQL 5.1 FAQ ? MySQL Chinese, Japanese, and Korean Character Sets」