MYSQL の 1 つのテーブルのデータ数が 2,000 万に達しました。さらに最適化するにはどうすればよいですか?
MYSQL の 1 つのテーブルのデータ数が 2,000 万に達しました。
データのクエリが非常に遅くなります。改善方法がわかりません。
現在の方法では、大量のキャッシュ テーブルを作成しますが、データはリアルタイムではありません。
このようなステートメント select max(id) from unit_keywords を実行するのに 7 秒かかりました。マシンのパフォーマンスは比較的良好で、64 ビット、4 コア、8G メモリ
- ---- -解決策--------------------
主キーとインデックスが正しく構築されているか確認してください。
テキストは主キーとして使用されますか?
2,000 万は多いですが、7 秒もかかりません。
------解決策---------
mysql 設定ファイルを確認してください。
おそらくあなたの構成は小規模なデータベース用です
------解決策------------------
以上です 2000W、パフォーマンスはまだ非常に高いので、 look mysql バッファの設定を見てください
うまくいかない場合は、別のテーブルに分割してください。
------解決策----------------------
この問題は PHP バージョンでは投稿しないでください。実際、DBA やシステム アーキテクトに問題の解決を手伝ってもらう必要があります。
テーブルから max(id) を選択するのに 7 秒かかる問題から判断すると、主流の慣行として id を自己増加する主キーとみなすことができます。これは、あなたのビジネスがロックの競合に遭遇していることを意味します。 (このフィールドが主キーまたはインデックスではなく、7 秒以内に 2,000 万行が返された場合、それは実際にマシン構成が非常に良好であることを意味します)
あなたのビジネスでは、これに対して SELECT、INSERT、および UPDATE 操作も実行していると思います。テーブルには DELETE がある場合もあります。 実際、パフォーマンスを追求するために、MySql の MyISAM テーブルを使用し、SELECT と INSERT 操作だけを残して業務を最適化している企業も少なくありません。 これは、INSERT ではテーブルをロックする必要がなく、SELECT 間にインターロックがないためです。 データを更新する必要があるという問題については、更新する必要があるフィールドを新しいテーブルに取り除き、その新しいテーブルで UPDATE を実行することで解決できます (もちろん、これは UPDATE 操作がそれほど頻繁ではない場合です。頻度が多すぎて意味がありません)。
もう 1 つは、ビジネスのクエリ句に従って対応するインデックスを確立することです。 MySql の Explain コマンドは、優れた参照の役割を果たします。
テーブルのキャッシュの問題に関しては、APC や Memcache などの別のキャッシュ サービスを使用し、データの更新中にキャッシュも更新されるようにすることをお勧めします。
テーブルの構造についてはよくわかりません。一般的な方法をいくつか説明しているだけです。 可能であれば、分析を容易にするために show create table の結果を公開することをお勧めします。