あなたが述べたことは完全に正しいです、一時的なテーブルは現在のユーザー/接続にのみ表示されます。それでも、いくつかのオーバーヘッドと、次のような他の問題があります。
- 数千の検索ごとに、そのテーブルを作成して入力します（後でドロップします）。ユーザーごとではなく、検索ごとに。各検索でスクリプトが再実行される可能性が高く、「セッションごと」はPHPセッションを意味するのではなく、データベースセッション（接続を開く）を意味するためです。
-
CREATE TEMPORARY TABLESが必要になります あなたがかもしれない特権 持っていません。 - それでも、そのテーブルは実際にはMEMORYタイプである必要があります。これにより、RAMが見た目よりも多く盗まれます。 VARCHARがある場合でも、MEMORYテーブルは固定長の行ストレージを使用します。
- ヒューリスティックが後でそのテーブルを2回参照する必要がある場合（
SELECT xyz FROM patternmatch AS pm1, patternmatch AS pm2 ...）-これはMEMORYテーブルでは不可能です。
次に、LIKE '%xyz%'を追加する方が簡単です。データベースも簡単です。 imagesに直接 テーブルWHERE 句。 TEMP TABLEを作成して結合するオーバーヘッドなしで、同じことを実行します。
いずれにせよ、どちらに行っても、WHEREはひどく遅くなります。 images.nameにインデックスを追加しても ほとんどの場合、LIKE '%xyz%'が必要になります LIKE 'xyz%'の代わりに 、インデックスが使用されないようにします。
いいえ。:)
代替オプション
MySQLには、組み込みの全文検索 （InnoDBの場合も5.6以降）そのスコアを与えることさえできます：私はそれを読んで試してみることを強くお勧めします。その検索を効率的に行う方法をデータベースがあなたよりもよく知っていることを確信できます。
InnoDBの代わりにMyISAMを使用する場合は、結果の数がテーブルの合計行の50％未満の場合にのみ、FULLTEXT検索で何も返されないという見過ごされがちな制限に注意してください。
あなたが見たいと思うかもしれない他のものは、例えばSolrです（そのトピック自体への素晴らしい紹介は http://en.wikipedia.org/wiki/Apache_Solr ）。私たちはそれを私たちの会社で使用していて、それは素晴らしい仕事をしていますが、それはかなりの学習を必要とします。
概要
現在の問題自体（検索）の解決策は、フルテキスト機能を使用することです。
数字を言うと、1秒あたり10.000回の呼び出しは、すでに「些細なこと」ではありません。1秒あたり数十万回の検索で、発生するパフォーマンスの問題の種類は、セットアップのいたるところにあります。いくつかのサーバー、負荷分散、その他の驚くべき技術的ながらくたが必要になります。そして、これの1つは、たとえばSolrです;）