完了するのに約 30 分かかる、約 1,400 万のレコードを持つテーブルに対する非常に単純なクエリがあります。クエリは次のとおりです。
select a.switch_name, a.recording_id, a.recording_date, a.start_time,
a.recording_id, a.duration, a.ani, a.dnis, a.agent_id, a.campaign,
a.call_type, a.agent_call_result, a.queue_name, a.rec_stopped,
a.balance, a.client_number, a.case_number, a.team_code
from recording_tbl as a
where client_number <> '1234567'
client_number でのフィルタリングが原因のようで、その列にはインデックスがあります。他に何を試すべきかわかりません。
client_number で INDEX を作成することから始めて、それがどのように役立つかを確認できますが、EXPLAIN コマンドを使用して問題を分析すると、最良の結果が得られます。
http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html
テーブルは myisam または innodb ですか? innodb が innodb バッファを大量に増やして、テーブル全体がメモリに収まるようにする場合。myisam が正常に機能している場合、OS キャッシュ バッファーを介して自動的にメモリに読み込まれます。RAM を増設します。より高速なディスク ドライブをインストールします。テーブル全体のスキャンを行っていることを考えると、これらが唯一の解決策のようです（テストクライアントIDと思われるクライアント番号を差し引いたものですか？）
テーブルをRAMにロードするのにもしばらく時間がかかるので、データベースが起動するとすぐにロードされるとは思わないでください.
クエリは、クエリ内の 1 つのテーブルで全テーブル スキャンを実行していますrecording_tbl。「tbl」プレフィックスがあるため、これはビューではなくテーブルであると想定しています。これがビューの場合は、ビューを最適化する必要があります。
説明を見る必要はありません。99% 程度のレコードの client_number が 1234567 でない限り、インデックスが役立つ可能性はほとんどありません。スラッシングと呼ばれる現象のために、インデックスが機能する可能性があります。
問題は、ハードウェアのサイズが小さいか、MySQL クエリ エンジンに割り当てられたリソースが不足していることです。最初にエンジンのバッファリングを調べ、次にディスク ハードウェアとプロセッサへの帯域幅を調べます。
Client_Number が数値フィールドとして格納されている場合
where client_number = 1234567
文字列の比較によってキャストが行われ、インデックスが使用されない可能性がある場合は、より高速になる可能性があります。
多分...
where client_number = '1234567'
...もう少し速くなります。