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

InnoDB テーブルに非常に単純な MySQL 更新クエリがあります。

私のテーブルは次のように構成されています。

この単純な更新クエリは、平均で 3.5 秒かかりますか? これを MediaTemple MySQL GRID コンテナーで実行しています。

これは、UPDATE を SELECT に切り替えたときの EXPLAIN の結果です。

私がこれを正しく行っていない方法について誰かが洞察を提供できますか?

[編集: インデックスのリストを追加]

それで、これはインデックスの大きな混乱ですか？ここに冗長なインデックスがたくさんありますか?

乾杯、ジョン

MySQLで遅いクエリがヒットしたページを知るにはどうすればよいですか?

このクエリがページ user.php および他の多くのページで作成され、このクエリがスロー ログに記録されたとします。

エラーログから、これが実行された正確なページを知る必要があります

クエリログが遅いことは承知していますが、これは最大実行時間を超えたクエリだけではないでしょうか? 私の質問は少し異なります（と思います）。

以下のクエリを実行していますが、問題があるとは思えません。しかし、私がそれを実行すると、「実行中」の時間が20秒を超えてから、何年もの間「フェッチ中」になります。DBのパフォーマンスの問題のために停止しなければならないところまで。

ここで私が間違っている場所を誰かが説明できますか。コーディング初心者なのでお手柔らかにお願いします。

更新 - わかりましたので、必要なものは次のとおりです。私たちは患者データベースを持っており、これらの患者はこのデータベースに記録された手順を持っています。私は、患者の oid (t1.oid) を、彼らが持っていた最初の手順 (2005 年から 2014 年の間にあった場合) と、それを持っていた場所 (それぞれ t2.date と t2.site) と共に返そうとしていますが、プロシージャは特定のタイプです (t2.type = '-25')

だから基本的に。2005年から2014年の間にAVFを患ったすべての患者と、AVFの「部位」（この場合は左腕/右腕など）

これで少しわかりやすくなれば幸いです。

前もって感謝します。

マイキー

特定の左結合に問題があり、重要なクエリが大幅に遅くなります。PHPMyAdmin を使用してクエリをテストすると、クエリが 546 行を返すのに 3.9 秒かかったことが示されています。

関連する 2 つのテーブルがあります: nsi (1,553 行) とファイル (233,561 行)。このクエリで言及されているすべての列は個別にインデックス化されているだけでなく、files テーブルの filejobid、category、isactive に複合インデックスが存在します。比較されるものもすべて整数です。

この簡易バージョンのクエリの目的は、nsi テーブルの行を 1 回表示し、誰かがカテゴリ 20 のファイルをアップロードしたかどうかを判断できるようにすることです。複数のファイルが存在する可能性がありますが、1 つの行のみである必要があるため、グループ化されます。

クエリ:

このデータの 67 秒の読み込み時間は、私のアプリケーションでは受け入れられず、これ以上最適化する方法がわかりません。インデックスと複合インデックスを作成しました。代わりに、よりラウンドアバウトな新しいソリューションを検討する必要がありますか?

助けてくれてありがとう！

AWS RDS インスタンスに Mysql DB があり、log_queries_not_using_indexes = YES の遅いクエリ ログがあります。

そして、それは機能していますが、ほぼ5秒ごとに、これは私がログに見ているものです:

これは何ですか？

最適化する必要があるクエリが 1 つまたは 2 つあり、残りのログ ファイルはこれです。

これはデータベースとどのように関連していますか? それらのクエリは私のものではありません。これは AWS が行っていることだと思いますが、パフォーマンスに影響する理由と方法はわかりません。

long_query_time パラメータを 2 (つまり 2 秒) に設定しました。しかし、2 秒未満のスロー ログ ファイルに多くのクエリが表示されます。実際には、2秒以上のファイルにデータを入力する必要がありますか?

以下はmysqlの遅いログエントリです

次の設定でスロークエリログを設定したmysqlサーバーを使用しています

mysqlイベントで毎分次のイベントを設定しました。

現在、これらの列playing, lastplayed, and ispresentはすべてインデックス化されていますが、これはスロー クエリ ログに次の詳細とともに表示されます。

このクエリが遅いログに表示されるのはなぜですか?

次のクエリがあります..

過去 3 か月以内に (2389) 以外のすべての人によって販売された車の平均市場価値を見つけますが、(2389) によって販売された同じメーカー、モデルの車のみです。

上記のクエリを最適化できますか? 1,100 万レコードの実行に 2 分かかります。

ありがとう

特定のクエリが遅いという問題があります。すべてが大量にインデックス化されていますが、いくつかの同様のクエリは正常に機能し、インデックスが使用されていますが、クエリは依然として地獄のように遅い. 理由がわからないので、誰か助けてください。

前提条件として、基になるテーブルの書き込み速度は問題ではありません。テーブルには約 350 万のエントリが含まれていますが、MySQL で問題なく処理できるはずです。

遅いクエリは約 2 秒かかります

際立っている唯一のことは、関連する膨大な量の行です。この質問の最後に添付した2つの高速クエリと比較すると、文字通り唯一の違いです（少なくとも最初のクエリとは異なります）。ですから、おそらくそれが問題です。しかし、それがデータが私に与えられる方法なので、それを処理する必要があります。インデックスに関与していれば、mysqlはデータをうまく処理できると思いました。

クエリを最適化する方法について誰か提案がありますか? クエリにより適した別のインデックスを使用できるとしたら、何か提案はありますか?

比較のために、これら 2 つの同様のクエリは非常に高速に動作します

テーブル (貼り付けるには長すぎると思われる多くのインデックスがあります)。

求人情報サイトを作りたいのですが、条件(タイトル、カテゴリ、タグ、市区町村...)が多いので、MySQLの正規表現を使っています。ただし、非常に遅く、500 内部サーバー エラーが発生する場合があります。

一例を次に示します。

何かアドバイス？