327

MySQL データベースのパフォーマンスが低下し始めるのはどの時点ですか?

  • 物理データベースのサイズは重要ですか?
  • レコードの数は重要ですか?
  • パフォーマンスの低下は線形ですか、それとも指数関数的ですか?

私は大規模なデータベースであると信じているものを持っており、約 15M のレコードがあり、ほぼ 2GB を占めています。これらの数値に基づいて、データを一掃するインセンティブはありますか、それとも、さらに数年間スケーリングを続けても安全ですか?

4

15 に答える 15

218

物理データベースのサイズは関係ありません。レコードの数は関係ありません。

私の経験では、遭遇する最大の問題はサイズではなく、一度に処理できるクエリの数です。ほとんどの場合、読み取りクエリをスレーブに対して実行し、書き込みクエリをマスターに対して実行できるように、マスター/スレーブ構成に移動する必要があります。ただし、まだ準備ができていない場合は、実行中のクエリのインデックスをいつでも微調整して、応答時間を短縮できます。また、Linuxのネットワークスタックとカーネルに対して実行できる多くの調整が役立ちます。

適度な接続数で最大10GBを取得しましたが、リクエストは問題なく処理されました。

最初にインデックスに焦点を当て、次にサーバー管理者にOSを確認してもらいます。それでも問題が解決しない場合は、マスター/スレーブ構成を実装する時期かもしれません。

于 2008-08-04T15:26:55.807 に答える
104

一般に、これは非常に微妙な問題であり、些細なことではありません。mysqlperformanceblog.comとHigh Performance MySQLを読むことをお勧めします。これには一般的な答えはないと本当に思います。

私は、ほぼ 1 TB のデータを持つ MySQL データベースを持つプロジェクトに取り組んでいます。最も重要なスケーラビリティ要素は RAM です。テーブルのインデックスがメモリに収まり、クエリが高度に最適化されている場合、平均的なマシンで妥当な量のリクエストを処理できます。

テーブルの外観に応じて、レコードの数は重要です。varchar フィールドが多いか、int または long が 2 つしかないかの違いです。

データベースの物理的なサイズも重要です。たとえば、バックアップについて考えてみてください。エンジンによっては、たとえば innodb を使用すると、物理的な db ファイルが大きくなりますが、縮小しません。そのため、多くの行を削除しても、物理ファイルの圧縮には役立ちません。

この問題には多くのことがあり、多くの場合、悪魔は細部に宿っています。

于 2008-08-04T18:44:15.690 に答える
49

データベースのサイズは重要です。100 万を超えるレコードを含む複数のテーブルがある場合、パフォーマンスは実際に低下し始めます。もちろん、レコードの数はパフォーマンスに影響します。MySQL は、大きなテーブルでは遅くなる可能性があります。100 万件のレコードに達した場合、インデックスが正しく設定されていないと、パフォーマンスの問題が発生します (たとえば、"WHERE ステートメント" のフィールドや結合の "ON 条件" にインデックスがないなど)。1,000 万レコードに達すると、すべてのインデックスが適切であっても、パフォーマンスの問題が発生し始めます。ハードウェアのアップグレード (メモリとプロセッサ パワー、特にメモリの追加) は、パフォーマンスを少なくともある程度向上させることで、最も深刻な問題を軽減するのに役立つことがよくあります。例えば37 個のシグナルが、Basecamp データベース サーバーの32 GB RAM から 128 GB RAM に移行しました。

于 2012-01-26T10:33:01.050 に答える
25

サーバー管理者にOSを確認させるよりも、最初にインデックスに焦点を当てます。それでも問題が解決しない場合は、マスター/スレーブ構成の時期かもしれません。

それは本当だ。通常機能するもう1つのことは、繰り返し処理されるデータの量を減らすことです。「古いデータ」と「新しいデータ」があり、クエリの99％が新しいデータで機能する場合は、すべての古いデータを別のテーブルに移動するだけで、それを見ないでください;）

->パーティショニングをご覧ください。

于 2008-08-11T19:19:05.547 に答える
23

2GB と約 15M のレコードは非常に小さなデータベースです - 私は pentium III(!) でもっと大きなものを実行しましたが、すべてはまだかなり高速に実行されています..あなたのデータベースが遅い場合、それはデータベース/アプリケーションの設計の問題であり、mysql ではありません. 1。

于 2010-08-05T09:03:48.627 に答える
19

「データベースのパフォーマンス」について話すのはちょっと無意味です。ここでは「クエリのパフォーマンス」の方が適切な用語です。答えは、クエリ、操作対象のデータ、インデックス、ハードウェアなどに依存します。スキャンされる行数と、EXPLAIN 構文で使用されるインデックスを把握できます。

2GB は実際には「大規模な」データベースとは見なされません。中程度のサイズです。

于 2008-08-06T19:53:54.580 に答える
9

私はかつて、「動作を停止した」mysqlを調べるように求められました。DBファイルがNFS2でマウントされ、最大ファイルサイズが2GBのネットワークアプライアンスファイラーにあることを発見しました。そして確かに、トランザクションの受け入れを停止したテーブルは、ディスク上で正確に2GBでした。しかし、パフォーマンスカーブに関しては、まったく機能しなくなるまで、チャンピオンのように機能していたと言われています。この経験は、あなたが自然に疑うものの上下に常に次元があることを思い出させる良い思い出として常に役立ちます。

于 2008-08-06T04:27:52.373 に答える
9

また、複雑な結合にも注意してください。トランザクションの複雑さは、トランザクションの量に加えて大きな要因になる可能性があります。

重いクエリをリファクタリングすると、パフォーマンスが大幅に向上する場合があります。

于 2008-08-04T19:01:23.860 に答える
8

考慮すべき点は、システムの目的と日々のデータです。

たとえば、車の GPS 監視を備えたシステムの場合、前月の車の位置からのクエリ データは関係ありません。

したがって、データを他の履歴テーブルに渡して相談できるようにし、日々のクエリの実行時間を短縮できます。

于 2012-12-06T05:13:30.677 に答える
5

クエリと検証によって異なります。

たとえば、100,000 の薬のテーブルを操作しました。このテーブルには、列の一般名があり、そのテーブル内の各薬に対して 15 文字を超えています。2 つのテーブル間で薬の一般名を比較するクエリを配置しました。クエリは実行するのにさらに数分かかります。同じように、ID 列を使用して (上記のように) 薬物インデックスを使用して薬物を比較すると、数秒しかかかりません。

于 2016-11-29T12:05:24.577 に答える