クエリされたデータに対して一定期間データベースがアイドル状態になっている場合にのみ問題が発生しました。最初のクエリは非常に遅く、30秒のオーダーで実行され、関連するクエリは0.1秒のように高速になります。私はこれがキャッシュに関連していると仮定していますが、私はその原因を見つけることができませんでした。mysqlが最初のクエリで遅くなり、その後関連するクエリが高速になる
mysql変数tmp_table_size、max_heap_table_sizeを大きなサイズに変更しても、メモリ内に一時テーブルを作成する以外は効果がありません。
これは、索引付けされている最初の低速問合せの後に同じ問合せのバリアントが低速問合せログに表示されないため、これは問合せ自体に関連しないと思います。私はこの問題の原因を特定しようとすることに最も関心があります。問題のトラブルシューティングを行うために問題のキャッシュをリセットする方法もあります。
innodbデータファイルのページがinnodbバッファプールにキャッシュされます。これはあなたが期待するものです。ファイルを読み込むのは、良いハードドライブであっても遅いです。特にランダムな読み取りは、ほとんどのデータベースに見られます。
最初のクエリでは、多くのページをバッファプールにプルする何らかの種類のテーブルスキャンが行われている可能性があります。または類似のもの。
これは私が期待しているものです。
理想的には、すべてのテーブル（例外：システムテーブル、一時テーブル（おそらく）、非常に小さなテーブルまたは短命のテーブル）に対して同じエンジンを使用します。あなたがこれをしなければ、ラムのために戦わなければならない。
すべてのテーブルがinnodbであると仮定すると、（マシン上で他の多くのタスクを実行しすぎないと仮定して）バッファプールをサーバーの物理RAMの75％まで使用します。
次に、12G程度のデータベースをラムに収めることができるので、一度「ウォームアップ」されると、データベースの「最もよく使われている」12GがRAMに格納されます。 mysqlのの
一部のユーザーは、彼らが生産・プールにそれらを追加するまで、しばらくの間、それらを別のマシンからコピーされたクエリを送信することにより、再起動（これらになりますレプリケーションスレーブ）以下の運用サーバーを「ウォームアップ」する傾向があります。これにより、キャッシュが寒い間に見られる極端な遅さが回避されます。例えば、YouTubeのがこれを行う（あるいは少なくともそれが使用され、Googleがそれを買って、彼らは今、Googleの-FUを使用することができます）
に移動することを考えると、その答えはmysql設定ファイルを変更してinnodbを調整することが判明しました。 innodb変数のサイズが大きくなると、データベースはいくつかのクエリの後でウォームアップします。私は起こっていたことは、キャッシュが小さすぎてメモリ内のすべてのテーブルインデックスを持つことができないため、ディスクから常にスワップしていて、最初のクエリが遅くなっていることです。今は、問題がなくなるように、それらをすべて記憶しておくのに十分です。 –
私の質問は、最初のクエリを高速にすることは可能ですか？または、それは何ですか、バッファプールをアップすることは正しい方法ですか？ –
あなたのmysqlサーバで何か他のものが動作していますか？私の考えは、おそらく最初のクエリの後、あなたのテーブルはまだメモリにキャッシュされています。アイドル状態になると、別のプロセスによってキャッシュが解除されます。しかし、ちょうど推測する。
実行中のメモリはどれくらいありますか？
mysqlは実行中の唯一のものですサーバー。 16Gbのメモリを搭載しています。私はそれがメモリからキャッシュされていないことに同意しますが、私は問題をトラブルシューティングできるようにキャッシュされている場所を特定できません。私はそれがmysqlの設定の問題、Linuxの設定の問題、SQLの問題など私は同じ問題を抱えている他のグーグルを持っているかどうかはわからないが、問題が何であるかについての洞察力はなかった。 –
これに基づいて：http://dev.mysql.com/doc/refman/5.1/en/query-cache.html、多分query_cache_sizeを大きくしてみてください。 LinuxはMySQLがそれを知らせるかどうかにかかわらず、このものをキャッシュしておく必要があるので、奇妙です。また、インデックスを追加したり、巨大なテーブルを持たないなど、クエリを高速化するための汎用メソッドを試すこともできますが、それらが役立つかどうかはわかりません。 –
query_cache_sizeはゼロに設定されているため、これは問題ではありません。私はそれがキャッシュされていることを知りたい。 –
時間を置いてクエリを実行したときにlinuxコマンドラインで "vmstat 1"の出力を比較し、再実行して結果を速くして比較します。具体的には、 "bi"列（ディスクから1秒間に読み取られるKB）を確認します。
オペレーティングシステムがディスクブロックを高速でキャッシュしていることがあります（したがって、低い「bi」数字）が、低速の場合（したがって大きな「bi」数字）ではありません。
どちらの場合でも、vmstatがCPU使用率の高低を示していることがあります。速いときにディスクのスループットが低く、ディスクのスループットも低い場合は、関連する設定値が0に設定されているにもかかわらず、キャッシュされたクエリが返されている可能性があります。おそらくshow engine innodb statusとSHOW VARIABLESの出力を確認して確認してください。
innodb_buffer_pool_sizeも高く設定する必要があります。これは、OSがそれらを返す前にブロックをキャッシュします。
「key_buffer」が高く設定されていると、索引のキーがキャッシュされ、選択が瞬時に高速になる可能性があります。
mysql performance blogサイトで多くの有用な情報を確認してください。
これは何が起こっているかです。サーバーは、最初のクエリでディスクからinnodbテーブルを読み込み、同様のクエリを実行するときにキャッシュを使用しています。今私はibdata1のサイズを減らす方法を見つけなければなりません。 innodb_file_per_table –
を私はタイムアウトたSSISパッケージを持っていました。クエリは単一のMySQLテーブルから非常にシンプルでしたが、多くの場合レコードが返され、最初は数分かかりました。私たちはADO接続に悩まされていました。これは30秒後にタイムアウトすることを意味していたので、ロードしようとしていたデータベースの約半数が失敗していました。
壁に頭を打つと、最初に最初のクエリを実行しようとしました。非常に単純で、いくつかの行を返すだけです。シンプルで速く実行され、クエリを高速化するためにキャッシュにテーブルを設定しました。パッケージの次のステップでは、より時間のかかる大きなデータセットを返すより複雑なクエリを実行します。問題解決 - すべてのテーブルがロードされました。私は定期的にこれをやり始めるかもしれません、複雑なクエリは、最初に単純なクエリを実行することではるかに高速に実行されます。
大きなクエリだけではなく、小さなクエリとオリジナルの大きなクエリを短時間で実行できると言っていますか？あなたは、MySQLがこれを理解して、必要なものをメモリに移してから、大きなクエリを試すことさえできると思います。 – mpen
アイドル期間後に最初のクエリでMySQL 5.6が遅かった場合に問題が発生しました。これはMySQLインスタンスの問題ではなく、接続の問題でした。 MYSQL Query Browserを実行すると「select * from some_queue」を実行し、数時間そのままの状態にしてからクエリを実行すると、実行速度は遅くなりますが、サーバのプロセスやブラウザの新しいインスタンスが同じテーブルから選択されます即座に。 my.iniファイルにスキップ・ホスト・キャッシュ、スキップ名-決意を追加
は、この問題を解決しました。
私はなぜそれがわかりません。なぜ私はこれを試したのですか？そのオプションを持たないMySQL 5.1では、他のネットワークからの接続がゆっくりと確立されていました（例えば192.168.1.100、192.168.1.101が高速接続、192.168.2.100が遅く接続）、MySQL 5.6ではこのような問題はありませんでした当初はこれらをmy.iniに追加していませんでした。
UPD：事例の半分を実際に解決しました。 wait_timeoutを最大整数に設定すると、残りの半分が固定されました。たぶん私は今でも、スキップ、名前解決、スキップ・ホスト・キャッシュを削除することができ、それが例100％に減速しないであろう
私は、MySQLの専門家だが、あなたはおそらくMySQLのバージョンを追加する必要があり、 OS情報とエンジン情報（MyISAM、InnoDB？） –
良い提案、5.0.26標準ログとほとんどInnoDB。
Linux 2.4.21-47.ELsmp＃1 SMP Wed 7月5日20:30:30 EDT 2006 x86_64 x86_64 x86_64 GNU/Linu –
これはhttp://www.serverfault.comに属します –