MySQLでスケーリングする方法（適切にスケーリングする準備ができていない場合）
MySqlを使用しています。
私の状況
それぞれ数百万行のテーブルが多数あります。これらのテーブルは1秒ごとに更新され、情報の追加と取得の両方に使用されます。各テーブルは5GBまたは10GBまたはそれ以上にすることができます。
情報の合計を保持する1つのテーブル（必要な情報の要約テーブルのようなもの）がありますが、これもサイズが大きくなり始めています。
私の制限
現時点では、さまざまな理由でデータベースを変更できません（主に知識、時間、予算がありません）。
サーバーに追加するすべての追加機能は、必要な他のリソースに割り当てられるため、非常に重いクエリを実行できません
スケーリングについて考えた一時的な方法
これらのことを念頭に置いて、私は自分が持っているものに合わせてスケーリングする方法を考えています：
数百万行のテーブルの場合、データベースを分離することを考えました（バックアップ、エクスポート、変更を簡単に行えるようになりました）。主なデータを1つのデータベースに保存し、すべての周辺機器（巨大なテーブル）を他のデータベースに保存します。異なるニーズのために異なるデータベースがあるとしましょう。
私が定期的に必要とし、急速に成長しているテーブルの問題については、XXテーブルに分割することを考えていました。ユーザーごとに1つのテーブル（多すぎる可能性があります）またはXXXユーザーごとに1つのテーブルです。
これらのアイデアは完全にクレイジーで本当に悪いDBデザインですか？
はいの場合....すべてを一度に変更する以外の提案はありますか？
PARTITIONingはnotスペースを節約します。各パーティションには4M〜7Mの「空き」スペースがあります。合計することができます。パーティショニングcanサーバーからデータを削除する（または別のサーバーに移動する）「古い」データに使用します。詳細な議論： http://mysql.rjweb.org/doc.php/partitionmaint
また、その場限りのパーティション分割も役に立たないでしょう。つまり、テーブルを分割し、データベース間を移動しても（サーバーではなくCREATE DATABASEについて話している）、パフォーマンスも領域も変わりません。一方、「バックアップ/エクスポートの方が簡単」mayは正当な理由です。詳細をお知らせください。
「シャーディング」は複雑ですが、複数のサーバー間でデータを分割する方法です。 （注：別の物理マシンを意味するために「サーバー」を使用しています。）
小さな修正は、テーブルのデータ型を縮小することです。 BIGINT（3バイト）で十分なときにMEDIUMINT（8バイト）を使用していますか？等.
サマリーテーブルは、スペースを節約し、「レポート」を高速化する優れた方法です。しかし、おそらくそれらは可能な限り小さくありませんか？ SHOW CREATE TABLEを見てみましょう。
「私はそれをXXテーブルに分割することを考えていました」-いいえ、いいえ、いいえ！唯一の例外は、「シャーディング」時です。
どのようにしてサマリーテーブルを作成しますか？いくつかのヒント： http://mysql.rjweb.org/doc.php/summarytables リアルタイムで、または毎晩サマリーテーブルが更新されると思いますか？そして、最初からやり直すのではなく、段階的に更新するだけです。
毎秒1挿入と言いますか？それは非常に低いレートです。おそらくそれよりも速いですか？
データが適切にインデックス付けまたは要約されている場合、テーブルのsizeは重要ではありません（パフォーマンスに関して）。ディスク容量または速度を心配していますか？
あなたの問題を解決するための最初のステップは、あなたが何もなしで何かを達成することができないという受け入れであると思います。 :-)
そのトートロジーが邪魔にならないため、異なるデータベース間でテーブルを再配置した場合にどのような違いが生じるかはまったく明らかではありません。なぜこれが役立つと思いますか？
ユーザーごとに1つのテーブルに分割する対象のテーブルについても同じです。なぜこれが役立つのでしょうか。全表スキャンを行っていますか？テーブルを分割することはおそらくよりクリーンなアプローチですが、提供した限られた情報に基づいて特定のアドバイスをすることは困難です。全表スキャンの一般的な解決策は、すでに使用していると述べたサマリー表です。