2

なぜそれは私が実行するときです

ANALYZE TABLE table_name_here

MySQL サーバーは次のエラーを出し始めます。

1040 - 接続が多すぎます

私はPHPMyAdminでこれを実行しました..

また、テーブルには 1,500 万行を超えるデータが含まれています。これを修正する方法はありますか？

MySQLTuner の結果:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.91-rs-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB +Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 10G (Tables: 192)
[!!] Total fragmented tables: 14

-------- Security Recommendations  -------------------------------------------
ERROR 1142 (42000) at line 1: SELECT command denied
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 21m 37s (134K q [103.756 qps], 982 conn, TX: 267M, RX: 20M)
[--] Reads / Writes: 88% / 12%
[--] Total buffers: 1.2G global + 22.2M per thread (120 max threads)
[!!] Maximum possible memory usage: 3.8G (99% of installed RAM)
[OK] Slow queries: 0% (4/134K)
[OK] Highest usage of available connections: 14% (17/120)
[OK] Key buffer size / total MyISAM indexes: 1.0G/2.9G
[OK] Key buffer hit rate: 97.7% (1M cached / 25K reads)
[OK] Query cache efficiency: 72.7% (92K cached / 127K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)
[!!] Joins performed without indexes: 492
[!!] Temporary tables created on disk: 44% (490 on disk / 1K total)
[OK] Thread cache hit rate: 98% (17 created / 982 connections)
[OK] Table cache hit rate: 97% (262 open / 268 opened)
[OK] Open file limit used: 0% (463/65K)
[OK] Table locks acquired immediately: 99% (78K immediate / 78K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 10.0M, or always use indexes with joins)
    tmp_table_size (> 192M)
    max_heap_table_size (> 192M)

もともと、私のキー バッファ サイズは 64MB にしか設定されていませんでした。キー バッファー サイズを 1GB に設定すると、そのコマンドの実行中に、接続ユーザーの最大数が 17 でピークに達しました。また、64MB のみに設定すると、常に最大許容接続ユーザー数に達していました。私のサーバーは 4GB の RAM にしか制限されていないため、これ以上の値を設定することはできません。

4

1 に答える 1

1

ここでコメントを完全な回答に移動します。これは MySQL の構成の問題であり、サーバーの障害に関してより適切な回答が得られる場合があります。

ANALYZE TABLE は、サーバーの問題を引き起こす 2 つのことを行います。まず、実行に時間がかかるコマンドです。問題の簡潔な説明から、アプリケーションがデータベースに対して非常に多くの短い接続を行っていると推測しました。ANALYZE には時間がかかるため、実行中に使用される接続はロックされます。アプリケーションが接続プールを使用している場合、または作成できる接続数にアプリケーション固有の制限がある場合、このような作業を実行できるように、これを MySQL 接続制限よりも 3 つ短い値に設定します。

次に、MyISAM テーブルの ANALYZE TABLE がインデックスを再構築します。つまり、MySQL はテーブル全体をメモリにロード (またはテーブル全体を読み取り) して、インデックスを新たに構築しようとします。これにより、テーブルに対してテーブル ロックが発生し、膨大な量のメモリが使用され、MySQL が他の作業 (アプリケーションの実行など) を実行する機能が妨げられます。

私の本当の提案は、MyISAM ではなく InnoDB に移行することです。メモリ、インデックス、およびデータの管理が大幅に改善されます。処理しているテーブル サイズについては MyISAM よりも高速であり、頭痛の種も少なくなります。

于 2011-03-21T19:43:10.573 に答える