MYSQL のボトルネックと対策
1) MYSQL 構成のバッファとキャッシュの値を増やし、サーバー CPU の数を増やすMYSQL のパフォーマンスのボトルネックに大きく対処できるのは、ハードウェアとサーバーの最適化です。
2) サードパーティのエンジンまたは派生バージョンを使用します。 ;
3) 他のデータベースに移行する;
4) 単一テーブルのサイズを削減するための補助的なソリューションを使用する。 Memcached、Redis などの NoSQL として
6) データ分割と分散展開にミドルウェアを使用します。
最後に、ツールをうまく使用できるかどうかは人的要因に依存します。
(1) パラダイムとアンチパラダイム: DB 設計を標準化するために、DB の開発過程で理論、DB は徐々に形成される パラダイム理論には、これまでに 5 つの主要なパラダイムがあります。 3 番目のパラダイムでは、通常はビジネス ニーズを満たすことができ、テーブル間の関係は比較的明確で維持が容易です。
(2) アンチパラダイムの提案: パラダイム理論は 1970 年代に提唱され、1980 年代にほぼ完成しました。当時のシステムの特徴は、利用可能なメモリ リソースが非常に限られていたことです。ネットワークを利用するには未熟なため、通常は 1 台のマシンのコンピューティング パフォーマンスのみが必要となるため、パラダイム理論では、本質的に安価なストレージは問題になりません。同時に、高い同時実行性、複雑なビジネス ロジック、低遅延の要件に直面するため、パラダイム設計理論では盲目的に従うべきではなく、スペースと引き換えに冗長性を高めることは価値があります。時間、最小値は最初のパラダイムに帰着できます。
(3) データベースを設計するときは、通常、次の原則に従う必要があります。
1) コア ビジネスはパラダイムを使用します。
2) 弱い一貫性要件 - アンチパラダイム
3) 時間のためのスペース
4) 不必要な冗長性を避ける
いわゆるパーティショニングは、データ テーブルのファイルとインデックスを別の物理ファイルに保存することです。MySQL バージョン 5.1 以降ではパーティショニングのみがサポートされます。 SHOW VARIABLES LIKE ‘%partition%’ を使用して、パーティショニングがサポートされているかどうかを確認できます。 MYSQL でサポートされるパーティション タイプには、Range/List/Hash/Key が含まれます。このうち、Range が最も一般的に使用されます。 例:
CREATE TABLE foo (id INT NOT NULL AUTO_INCREMENT, created DATATIME, PRIMARY KEY(id, created)) ENGINE = INNODB PARTITION BY RANGE (TO_DAYS(created)) (PARTITION foo_1 VALUES LESS THAN (TO_DAYS('2009-01-01')),PARTITION foo_2 VALUES LESS THAN (TO_DAYS('2010-01-01') ))
通常は範囲パーティショニングが使用されますが、マスター/スレーブ構造ではマスターサーバーが SELECT ステートメントを使用することはほとんどなく、現時点では範囲クエリを使用することはあまり意味がありません。ハッシュ タイプのパーティショニングを使用するには: PARTITON BY HASH (id) PARTITION 10. データを挿入するとき、データは ID に従って各パーティションに均等に分散されます。ファイル サイズが小さく、効率が高いため、更新操作が高速になります。通常は時間フィールドによって分割されますが、特定の状況はニーズによって異なります。
パーティショニングは優れていますが、現在の実装には次のような多くの制限があります。
主キーまたは一意のインデックスには、PRIMARY KEY (id, created) などのパーティショニング フィールドが含まれている必要があります。 )、ただし、InnoDB の場合、大きな主キーのパフォーマンスは良くありません
多くの場合、パーティショニングを使用する場合は、主キーを使用しないでください。そうしないと、パフォーマンスに影響を及ぼす可能性があります
パーティション化は、INI タイプのフィールドまたは INI タイプを返す式によってのみ実行できます。通常は、YEAR または TO_DAYS
などの関数を使用します。各テーブルには最大 1024 個のパーティションがあります。無制限にパーティションを拡張することはできません。パーティションを過度に使用すると、大量のシステム メモリが消費されます
パーティションを使用するテーブルはサポートされていません 外部キーと関連する制約ロジックをコードに実装する必要があります
パーティション分割後にインデックス エラーが発生する可能性があります分割の実現可能性を検証する必要があります