問題タブ [mysql-slow-query-log]

InnoDB を使用している単純なテーブルがあります。

テーブルには 106 個のタグしかなく、この単純な選択クエリでは 10 秒、16 秒、30 秒、またはそれ以上かかることがあります。

私の質問: このクエリを最適化する方法はありますか (完了までに 26 秒かかりません)、それとも Mysql サーバーの過負荷の明確な兆候ですか? 共有ホスティングから VPS にアップグレードすると、この問題は解決しますか?

417 日間正常に動作した後、ランプ サーバーが 4 日から 1 日に数回タイムアウトする原因を理解しようとしています。

実行中のプロセスtopを調べると、mysql を指す場合があります。それで、スロークエリのログを調べたところ、これしか見つかりませんでした。

あなたはそれを理解できますか？特にラインがselect sleep(60)気になります。特に、私のウェブサイトのコードベースにないためです。

mysql スロー クエリ ログの query_time パラメータの計算に使用されるタイムスタンプは何ですか? そのパラメータの定義が見つかりません。私が見つけた唯一のものは

初期ロックを取得する時間は、実行時間としてカウントされません。

から: http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

スローログの「request_time」で指定された時間に、キューでの待機時間が含まれているかどうかを知りたいので、この質問をしています (ある場合)。

いくつかのキューがある場合、新しいクエリが実行されるときに現在の待機キューの長さをログに記録する可能性はありますか (できればスロー ログに)。

キューがない場合、すべてのスレッドが現在何らかのクエリを実行している場合、mysql は着信クエリをどのように処理しますか? 更新: スレッドで実行できるようになるまで、これらのクエリを TCP バッファに保持しますか?

さらに読むためのリンクは大歓迎です。

よろしくコルビニアン

次の構造のテーブルがあります

ここからデータを取得する基本的なクエリがありますが、これは非常に遅いです。そのため、クエリをより単純な用語に分解したところ、この非常に単純なクエリは遅い (17.52 秒) ことがわかりました。

テーブルには 6,274,617 行あります。実際、SELECT COUNT(*) FROM data_temperature3.66 秒もかかります。

このクエリが実行されているシステムは私の開発システムで、Ubuntu 14.04 を実行するクアッドコア、4 GB の RAM、およびソリッドステート ドライブです。

これは、このようなクエリを実行するのにかかる時間についてですか、それとも何か間違っていますか? データを返すより効率的な方法はありますか?

最初は、スクリプトの中から遅いクエリを見つけようとしています。そして、私を悩ませていることの1つはINSERT、テーブルにいくつかのインデックスがあるため、クエリです（この場合、インデックスを毎回再計算する必要があるため、挿入が瞬時に行われないことを理解できます）。

私のホスティング会社 (siteground) は、遅いクエリで実際の状況を調査するために、MySQL ログへのアクセスを制限しています。したがって、問題を見つけるためにバイパス方法を検索する必要があります。

今、phpmyadminで疑わしいクエリを実行し、クエリにかかる時間が問題ないかどうかを確認しています。

ただし、このアプローチにはいくつかの弱点があります。

• 現在のサーバー負荷に基づいて実行時間を取得します。したがって、その時点でサーバーがビジー状態だった場合、誇張された時間が表示されます。

• クエリがキャッシュされた場合、過小評価された時間が得られます。

• クエリを確認するには、DB データを実際に変更する必要があります。のようなクエリについては問題ありませんが、およびSELECTについては扱いにくくなっています。DELETEUPDATE

したがって、別のアプローチを使用する方がはるかに優れています。EXPLAIN次の場合を除き、良い解決策になる可能性があります。

• EXPLAIN私のDBサーバーでのクエリに対してのみ機能しSELECTます（MySQLサーバーのバージョン5.5.32、DOCからの引用：MySQL 5.6.3より前では、SELECTは唯一の説明可能なステートメントです）。私は説明UPDATEしDELETE、EXPLAIN SELECT代用することができます（それは正しいですか？）が、EXPLAIN INSERTそれでも大きな問題です。

質問は次のとおりです。

1. 少なくとも 1 つのインデックスがあると遅くなるINSERT 可能性があるというのは正しいですか?

2. EXPLAIN UPDATE代用できますDELETEかEXPLAIN SELECT？

3. 言及された phpmyadmin の実行と EXPLAIN に加えて、どのアプローチを使用してクエリ速度を調査できますか?

InnoDBエンジンを使用しています。

こんにちは、私は MySQL バージョン 5.5 で作業しています。誰かが mysql の mysql.slow_log テーブルからデータをクリア/フラッシュするのを手伝ってくれませんか?

バナーがある大きなテーブル (30000000 行) を持つ MySQL データベースがあります。次のようなクエリがあります。

問題は、IN の数値が大きく、クエリが遅くなることです。

数をグループに分けてクエリしたい、例えば各グループ1000

これは良い方法ですか？または他の最適化？

特定のテーブルのデータベースに 20,000 行しかない場合に、これだけの行数が返される方法。「row_examination」でご案内ください。どういう意味ですか？

スロークエリをログに記録せずにスロークエリをチェックする方法は他にあるのでしょうか。非常にビジーなサーバーがあり、メモリと I/O を節約するために多くのログを記録する余裕がないとします。次に、遅いクエリがあるかどうかを確認する他の方法はありますか? クエリのプロファイリングを行うことはできますが、時間とメモリを最も消費しているクエリを特定するために正確に何をすべきかはまだわかりません。

mysql の管理を開始したばかりで、これを処理する方法がわかりません。どんなガイダンスも高く評価されます。