大規模なMySQL SELECT WHERE IN句の最適化
次のSELECT WHERE INケースを最適化するにはどうすればよいですか？
3カラムしかない1億行を超えるテーブルがあります。主キー（col1）は127 varcharです。 IN句が5,000文字列であるSELECT col1 WHERE col1 IN（...）を実行しています。 5,000個の文字列のうちどれが主キーとしてDBにあるかを確認しようとしています。
専用サーバーとInnoDBテーブルを使用すると、クエリに3〜10秒かかるため、許容できません。 5万行を選択した場合でも、1億行以上がMySQLでSELECTを実行するのが難しいとは思わないが、おそらく間違っているのではないか。
これを最適化するために何ができるでしょうか？ FULLTEXTキーについて少し読んだことがあります。キーは127 varcharなので、これらの方が良いでしょうか。または、あるタイプのJOINまたはUNIONは、大きなIN句に対してこのクエリを高速化しますか？
何か助けていただければ幸いです！ありがとう！
---- EDIT ----
SHOW ENGINE INNODB STATUS;
| InnoDB | |
=====================================
2014-07-14 10:59:19 2bf5cf25700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 5 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 6664 srv_active, 0 srv_shutdown, 142740 srv_idle
srv_master_thread log flush and writes: 149372
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 417120
OS WAIT ARRAY INFO: signal count 449454
Mutex spin waits 323558, rounds 2089912, OS waits 48403
RW-shared spins 49101, rounds 462555, OS waits 12976
RW-excl spins 406820, rounds 11261153, OS waits 350839
Spin rounds per wait: 6.46 mutex, 9.42 RW-shared, 27.68 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 21503
Purge done for trx's n:o < 21472 undo n:o < 0 state: running but idle
History list length 641
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 15895, OS thread handle 0x2bf5cf25700, query id 399305 localhost root init
SHOW ENGINE INNODB STATUS
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
1203330 OS file reads, 2141172 OS file writes, 78570 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 5, seg size 7, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276671, node heap has 52 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 117811837521
Log flushed up to 117811837521
Pages flushed up to 117811837521
Last checkpoint at 117811837521
0 pending log writes, 0 pending chkp writes
21279 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 720503
Buffer pool size 8191
Free buffers 1024
Database pages 7115
Old database pages 2606
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 4741, not young 1045985243
0.00 youngs/s, 0.00 non-youngs/s
Pages read 1202370, created 1138775, written 2068616
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 7115, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Main thread process no. 23063, id 3020409116416, state: sleeping
Number of rows inserted 113995729, updated 144489445, deleted 0, read 171054938
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
一般的に、長いIN操作を一時テーブルに対する結合に置き換えることに成功しました。 RDBMSはJOINを可能な限り効率的に実行するように最適化されており、長いINリストの処理は、INリストのすべての値に対してクエリを繰り返すことによって行われる可能性が高いため、これは理にかなっています。表示されるパフォーマンスの問題は、5,000回実行されるクエリの単純な事実によって簡単に説明できます。
ハードウェア、InnoDB構成、およびクエリの詳細については何もわからないため、以下は長い目で見てください。ただし、ジョブ（InnoDBエンジン）に間違ったツールを使用していると思います。
あなたが達成しようとしていることは、非常に重いインデックスを作成することです（最大127文字、これはかかる可能性があります-これは大まかな近似です）127 * 3バイトエントリごとに）、これはInnoDBで使用できる唯一の方法であるB +ツリーを使用して作成されます。また、行が主キーの周りにクラスター化されているため、実際には行全体がインデックス上にあり、主キーにアクセスすることは、行全体のコンテンツを含むページにアクセスすることを意味します。
つまり、テーブル全体を含む一意のインデックスがあり、メモリに多かれ少なかれ収まるはずです（必ずしもすべてではありませんが、このあなたのワーキングセットはほとんどの行のようです）。 InnoDBバッファープールの大きさは？バッファプールのヒット率はどうですか？SHOW ENGINE INNODB STATUSで両方のパラメータを確認できます。私の賭けは、あなたのバッファプールが小さすぎるか、あなたのワーキングセットを保持するのに十分な物理メモリがないことです。どちらの場合も、これによりInnoDBはすべてのクエリに対してIOPSを実行する必要があります。すべてを適切に機能させるために、すべてのキャッシュを用意する必要はなく、正しいはずです。ただし、特定のワークロード（大きなPK）の場合、InnoDBは最適なエンジンではありません。 ハッシュインデックスは、他のRDBMSおよびMySQLエンジンで使用できますが、おそらく小さくて高速です、ただしInnoDBではサポートされていません。さらに、膨大な数の行を含むIN + list of valuesは、（MySQLレベルで）クエリの最適な方法とは言えませんが、個別にクエリを実行するよりも確実に高速です。
- クエリプランナー（
EXPLAINで確認できます）がrangeJOINタイプを使用しており、全表スキャンを実行していないことを確認してください。 - その後、最初にInnoDBバッファーを調整してInnoDBキャッシュミスを減らすことをお勧めします。
- 次に試すことは、小さなセカンダリインデックスを作成して、ハッシュインデックスをエミュレートすることです。 この方法は「ハイパフォーマンスMySQL」という本で説明されています 。この方法では、小さなセカンダリインデックスのみがメモリにキャッシュされ、物理メモリに適合する可能性があります。
- これらが機能しない場合は、テクノロジーを変更する前に、別のエンジンを使用して、Key-Valueデータセットでうまく機能することをお勧めします。多分TokuDBはこれを処理する方が良いかもしれませんか？また、MySQL/InnoDB 5.6に統合されたmemcachedインターフェースも別の解決策になるでしょうか？ Multi-getは、ソリューションに非常に適しているようです。
- 最後に、負荷がほとんど読み取りである場合は、全文検索エンジンなどの外部テクノロジーを試すことができます-言及しますが、それらに注意してください一部のソフトウェアはファジー検索に依存する傾向があり、一部の結果が省略される可能性があり、完全にACIDに準拠しない傾向があります（これらは、クエリ速度と引き換えに犠牲にする必要があります）。