Databases for MySQLのベストプラクティス

ベスト・プラクティス
ベスト・プラクティス	注記
`max_allowed_packet` に正しい値を設定する。	大きなトランザクションやビンログが制限を超えるようなレプリケーションセットアップでは、 `max_allowed_packet` のサイズに違反すると、レプリカがフェイルコピー状態になり、プライマリがロックされる危険性があります。 BLOBまたはVARTEXTカラムを使用してファイルの内容を MySQL カラムに格納すると、バックアップのレプリケーションとリストアで問題が発生することがあります。カラムに様々な長さのデータをロードする場合は、max_allowed_packetを最大値に設定することを推奨する。さらに、特定のテーブルで複数のワイドLONGBLOBカラムを使用しないでください。行サイズが許容最大値を超えてしまい、ポイント・イン・タイムを使用したリストアが機能しなくなる可能性があるからです。
行数の多いテーブルに主キーを実装する。	5K 行を超えるテーブルに主キーを追加すると、レプリケーションが大幅に最適化され、過剰なラグを防ぐことができる。 5K 行以上のDELETEまたはUPDATE操作を1つのステートメントで実行するテーブルには、主キーを定義することを推奨します。主キーを追加できない場合は、 5K 行未満のバッチでDELETEし、バッチごとにコミットする。
DROP TABLEとTRUNCATE TABLEは、可能な限り、テーブル全体のDELETEよりも優先する。	レプリケーションは行の削除ごとにログを記録するため、処理が大幅に遅くなる可能性がある。削除と更新をチャンキングすることを推奨する。 DROP、CREATE、TRUNCATEはDDL文であり、バックアップ中に完了するのではなく、バックアップ操作が完了するまで待機することに注意してください。ログ・エントリには、これらのステートメントがブロックされるバックアップ中の時間に対する警告メッセージが表示されます。監視ダッシュボードのディスク使用パネルで、バックアップ時間を見積もることができます。目安として、500GBのデータのバックアップには約90分かかる。
UPDATE JOINやDELETEのような単一ステートメントによる複数行の操作は、WHERE範囲句を使用して、タッチした行数を最小限に抑える。	こうすることで、クエリーのパフォーマンスを向上させ、ロックの競合を減らすことができる。
アプリケーション・エンドでコネクション・プーリングを使用する。	プーリングはコネクションを再利用し、コネクションが最大になるのを防ぐ。プールのサイズは、データベースの `max_connections`。再試行ロジックを実装し、例外をキャッチしてプールの枯渇や接続の失敗を処理する。
本番アプリケーションごとに専用の ICD-MySQL インスタンスを使用することで、爆発半径を縮小します。	アプリケーションを分離することで、サービスインスタンスあたりのボリュームを減らし、多くのアプリケーションからの需要の集約によって引き起こされる問題を最小限に抑える。
MySQL インスタンスごとに MySQL リードレプリカをデプロイする。	リード・レプリカは、メイン・インスタンスからのリード・トラフィックをサポートする機能を提供し、全体的なワークロードを削減し、信頼性を高めます。