私は、longtext列とUnicode文字列を比較する、いくつかの 'startswith' ORM操作を実行するdjangoアプリケーションを使用しています。これにより、u'mystring'ユニコード文字列との比較操作がLIKE BINARYになります。 LIKE BINARYは普通のLIKEよりも遅くなる可能性がありますか？SQL 'LIKE BINARY'は、普通の 'LIKE'よりも遅いですか？
私は一般的な答えがベンチマークであることを知っていますが、私は前にLIKE BINARYクエリを見たことがないので、私のアプリケーションではなく一般的なデータベースの一般的な考え方を得たいと思います。
私はMySQLを使用していますが、一般的にはSQLデータベースの回答に興味があります。
パフォーマンスが問題になるようであれば、の最初のコピーを作成することをお勧めします。長い文章の255文字は、その上にインデックスを追加し、それとstartswithを使用してください。
BTW、this page says： "大文字と小文字を区別してマッチングする必要がある場合は、カラムをBINARYとして宣言してください。バイナリ以外のカラムをキャストするクエリでLIKE BINARYを使用しないでください。その列のインデックスを使用してください。古いヒントですが、これはまだ有効です。この横切る次の人のために
- 私たちの比較的小さなデータベースクエリに：に比べ
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と（5.5で、それは全表スキャンを行いながら。）のMySQL 5.1で同じデータベースに対して私のテストでLIKE BINARYクエリはまだインデックスを使用して確認
mysql 5.5.31のこの動作。 djangoでは、パフォーマンスを向上させるために__startswithの代わりに__istartswithを使用することが重要であることを意味します。 – Julian