MySQLクエリが遅い場合の理由と解決策

Python プログラムを書き、Mysql ライブラリを集中的に操作したためです。データ量が多くないときは、非常に遅いことに気づきませんでした。その後、どんどん遅くなりました。データ量が多いためだと思っていましたが、その後、耐えられないほど遅くなりました。長時間チェックし、使用できるインデックスをすべて使用しました。それでも、1 回の実行に 3 ～ 4 秒かかり、耐えられませんでした。

そこで、キャッシュ可能なすべてのクエリを redis を使用してキャッシュし、アプリケーションの速度を大幅に向上させました。

しかし、キャッシュできないものもまだいくつかあります。言い換えると、クエリするたびに結果が異なる場合は、キャッシュする方法がありません。 Navicat のクエリ概要を使用すると、スタックしている部分はデータの送信セクションにあり、3.5 秒かかり、クエリ時間の 99% を占めていることがわかります。

オンラインでいくつかの情報を調べたところ、その一部は SQL ステートメントの問題によるものであることがわかりましたが、varchar や in メソッドはまったく使用していませんでした。

そこで、テーブルが大きすぎてメモリにキャッシュされていないのではないかと思い、mysqldプロセスが占有するメモリを確認したところ、50M強しかなく、明らかに少なすぎました。テーブルの実際の容量は200M以上で、navicatのオブジェクト列で確認できます。各クエリがディスクから読み込まれるため、非常に時間がかかります。そこで、win10のディスクIOを確認したところ、確かにそうでした。ディスクIOは100％に達し、ソリッドステートドライブで、1秒あたり約80Mの読み取りでした。こんなに遅いのも不思議ではありません。

そこで、mysql の設定ファイルを確認したところ、32M の設定しかありませんでした。512M に調整して、mysql を再起動しました。今度は、時間が 3.5 秒から 0.76 秒に短縮されました。

構成項目は次のとおりです。

innodb_buffer_pool_size=32M

これは MySQL 5.7 のデフォルトです。ハードウェア構成に応じて、512 または 1024 に変更して再起動してください。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。これについてもっと知りたい場合は、次のリンクをご覧ください。