SQL 'LIKE BINARY'は普通の 'LIKE'よりも遅いですか?

私は longtext の列をUnicode文字列と比較する、いくつかの 'startswith' ORM操作を行うdjangoアプリケーションを使用しています。この結果、 u'mystring 'のUnicode文字列を持つ LIKE BINARY の比較操作が行われます。 LIKE BINARYは普通のLIKEよりも遅くなる可能性がありますか?

私は一般的な答えがベンチマークであることを知っていますが、私は前にLIKE BINARYクエリを見たことがないので、私のアプリケーションではなく一般的なデータベースの一般的な考え方を得たいと思います。

私はMySQLを使用していますが、一般的にはSQLデータベースの答えに興味があります。

6
追加された
ビュー: 1

2 答え

パフォーマンスが問題になるようであれば、最初のコピーを作成することをお勧めします 。長いテキストの255文字にインデックスを追加し、 startswith を使用します。

ところで、このページが表示されます: "必要ならば大文字と小文字を区別するマッチングを行うには、カラムをBINARYとして宣言し、クエリでLIKE BINARYを使用して非バイナリカラムをキャストしないでください。そうすると、MySQLはそのカラムのインデックスを使用しません。古いヒントですが、これはまだ有効です。

5
追加された
mysql 5.5.31でこの動作を確認しました。 djangoでは、パフォーマンスを向上させるために__startswithの代わりに__istartswithを使用することが重要であることを意味します。
追加された 著者 Julian,

これを横断する次の人のために - 私たちの比較的小さなデータベースでは、

SELECT * FROM table_name WHERE field LIKE 'some-field-search-value';

... Result row

Returns 1 row in set (0.00 sec)

に比べ:

SELECT * FROM table_name WHERE field LIKE BINARY 'some-field-search-value';

... Result row

Returns 1 row in set (0.32 sec)

少なくとも私たちのデータベース(MySQL 5.5/InnoDB)では、2つのルックアップの間に非常に大きな違いがあります。

どうやら、これはMySQL 5.5のバグです: http://bugs.mysql.com/bug .php?id = 63563 であり、MySQL 5.1の同じデータベースに対する私のテストでは、LIKE BINARYクエリはインデックスを使用しています(5.5ではフルテーブルスキャンです)。

2
追加された