45

私のテーブルのウェブサイト

Website_Name//column name
Google
Facebook
Twitter
Orkut
Frype
Skype
Yahoo
Wikipedia

utf8_bin照合を使用すると、Webサイトでウィキペディアを検索するためのクエリは次のようになります。

Select Website_Name from Website where lower(Website_Name)='wikipedia'

そして、utf8_unicode_ciを使用する場合、Webサイトでウィキペディアを検索するための選択クエリは次のとおりです。

Select Website_Name from Website where Website_Name='wikipedia'

次のクエリに応じて、どの照合が最適かを知りたいです。

4

3 に答える 3

74

それはあなたが必要とするものに依存します。

utf8_bin照合は、純粋にUnicodeコードポイント値に基づいて文字列を比較します。すべてのコードポイントの値が同じである場合、文字列は等しくなります。ただし、マークを組み合わせるための異なる構成の文字列（構成された文字と分解された文字）、または正規に同等であるが同じコードポイント値を持たない文字がある場合、これは崩壊します。場合によっては、を使用utf8_binすると、期待どおりに文字列が一致しなくなることがあります。理論的にutf8_binは、文字列にUnicode正規化が適用されないため、最速ですが、希望どおりでない場合があります。

utf8_general_ci言語固有のルールを使用してUnicode正規化を適用し、文字列を大文字と小文字を区別せずに比較します。utf8_general_cs同じことを行いますが、文字列を大文字と小文字を区別して比較します。

于 2012-06-07T10:20:14.280 に答える
14

個人的にはutf8_unicode_ci、検索したい結果に対して大文字と小文字が一般的に重要ではないと予想される場合は、を使用します。

照合は、実行時だけでなく、MySQLがインデックスを作成するときにも使用されます。したがって、これらの列のいずれかがインデックスに表示される場合、その照合の比較ルールに従ってデータを検索することは、これまでにないほど高速になります。

大文字と小文字を区別しないマッチングが必要ない場合は、上または下を適用しないでください。代わりにBINARY、utf8列の前にキーワードを適用して、照合によるものではなく、リテラルのコードポイント比較を強制します。

mysql> create table utf8 (name varchar(24) charset utf8 collate utf8_general_ci, primary key (name));
Query OK, 0 rows affected (0.14 sec)

mysql> insert into utf8 values ('Roland');
Query OK, 1 row affected (0.00 sec)

mysql> insert into utf8 values ('roland');
ERROR 1062 (23000): Duplicate entry 'roland' for key 'PRIMARY'
mysql> select * from utf8 where name = 'roland';
+--------+
| name   |
+--------+
| Roland |
+--------+
1 row in set (0.00 sec)

mysql> select * from utf8 where binary name = 'roland';
Empty set (0.01 sec)

このような場合、MySQLは最初に列の値のコピーを作成し、その大文字と小文字を変更してから比較を適用する必要があるため、これは下位または上位を使用するよりもはるかに高速です。BINARYを配置すると、最初にインデックスを使用して一致を検索し、次に値が等しくないことが検出されるまでコードポイントごとの比較を実行します。これにより、通常は高速になります。

于 2012-06-07T10:40:57.077 に答える
9

私は教義によってデフォルトである'utf8_unicode_ci'を使用していました、私はそれをに変更しなければなりませんでした：

 * @ORM\Table(name = "Table", options={"collate"="utf8_bin"})

私の複合主キーのいくつかはテキストフィールドで構成されていたので。悲しいことに、「utf8_unicode_ci」は「poistný」と「poistny」を同じ主キー値として解決し、フラッシュを挿入する教義でクラッシュして終了しました。複合主キーの一部の照合を単純に変更することはできず、テーブルを削除して再作成する必要がありました。それが他の誰かの時間を節約することを願っています。

于 2016-02-18T13:24:25.813 に答える