前に書いた言葉: 災害復旧の重要性を思い出すのは常に災害が発生した後、誰かが思い出させてくれたことを思い出すのは常に損失を被った後です。

2. 単一テーブル内のデータ量を制御する: 単一テーブル内のレコードを 1,000 万件で制御する
3.列の数: フィールドの数は 20 以内に制御されます
4. パラダイムと冗長性のバランスをとる Yu: 効率を向上させるためにパラダイム設計と冗長データを犠牲にする
5. 拒否 3B: 大規模な SQL、大規模なトランザクション、大規模なバッチを拒否します
6.テーブル文字セットの場合
7. INNODB ストレージ エンジンを使用します

リーリー

3. enum または set を最初に使用します。
enum ('F', 'M')sex4、 NULL フィールドの使用を避ける
リーリー

8。 utf-8 は latin1 の 3 倍のスペースを占有するため、utf-8 の使用はできるだけ少なくしてください。 latin1 は、メール、URL など、utf-8 を使用する必要のないフィールドで使用できます。 9. 精度とスペースの変換。一般に、浮動小数点型は、同じ数値範囲のデータを格納する場合、DECIMAL 型よりも使用するスペースが少なくなります。 FLOAT フィールドはデータの格納に 4 バイトを使用します。 DOUBLE 型は 8 バイトを必要とし、精度が高く、より大きな数値範囲を持ちます。DECIMAL 型のデータは DOUBLE 型に変換されます
10。ライブラリ名、テーブル名、フィールド名は 12 文字以内の固定長でなければなりません。ライブラリ名、テーブル名、フィールド名は 32 文字を超えることはできません。名前の意味を理解する必要があります。MySQL の予約語はライブラリ名、テーブル名、およびフィールド名では禁止されています。一時ライブラリとテーブルの名前には接頭辞として tmp を付け、接頭辞として bak を付ける必要があります。 InnoDB テーブル行レコードの物理長は 8KB を超えません。B+Tree の特性に基づいて、データ ページには少なくとも 2 レコードを保存する必要があります。したがって、大きな列 (特に TEXT/BLOB 列) の実際のストレージ長が 8KB を超えると、ORACLE の「行移行」と同様の「ページ オーバーフロー ストレージ」が発生します。 TEXT/BLOB タイプ）、頻繁に読み書きされる場合は、これらの列をサブテーブルに分割し、メイン テーブルと一緒に格納しないことが最善です。頻繁に行われない場合は、メイン テーブルに保持することを検討できます。 innodb
page
size オプションを 8KB に変更する場合、行レコードの物理長は 4KB
を超えないようにすることをお勧めします。
インデックスクラス
1. インデックスは慎重かつ合理的に使用しますリーリー

2. 文字フィールドはプレフィックスインデックスを構築する必要があります。
3. インデックス内で列操作を実行しないでください。悪い例: age +1 = 10 の ID を選択します。
4. innodb の主キーには自動インクリメント列を使用することをお勧めします。 リーリー

6. すでにインデックスが存在するプレフィックスにインデックスを作成しないでください。例: インデックス (a, b) が存在する場合、インデックス (a) を削除します
7. 単一のインデックスの長さを制御します。キー (名前 (8)) を使用して、データの最初の数文字にインデックスを作成します。 8. インデックスを選択して使用します。性別列など、めったに変更されない列にインデックスを使用するのはあまり良いことではありません。 9. テーブルの最適化は、頻繁に実行しないように注意してください。 11. インデックスの選択性。インデックス値は、カーディナリティ テーブル内のデータ行数の比率とも呼ばれます。インデックスの選択性 = Count(distinct(username))/count(*) がインデックスの選択性です。インデックスの選択性が高いのは mysql です。一致を検索する場合、値 1
12 を使用すると、より多くの行をフィルタリングできます。INNODB エンジンのインデックスには、重複したインデックスや冗長なインデックスを使用しないでください。データが変更されるたびに、主キー インデックスにインデックスを作成する必要があります。補助インデックス内の対応するインデックス値が変更されると、大量のデータの移行、ページング、断片化が発生する可能性があります。 20 の場合は、完全な列インデックスではなくプレフィックス インデックスを作成するのが最善です (例: ALTER TABLE t1 ADD INDEX(user(20)))。これによりインデックスの使用率が効果的に向上しますが、プレフィックス インデックスが作成されないという欠点があります。この列を並べ替えるときに使用されます。プレフィックス インデックスの長さは、フィールドの統計に基づいて決定できます。通常、平均の長さよりわずかに大きくなります。 14. pt-duplicate-key-checker ツールを定期的に使用して、重複したインデックスを確認し、削除します。たとえば、インデックス idx1(a, b) がすでにインデックス idx2(a) をカバーしている場合、idx2 インデックスを削除できます

SQLステートメント設計クラス

1. SQL ステートメントはできるだけ単純です。1 つの SQL は 1 つの CPU 上でのみ実行できます。ロック時間を短縮するために、1 つの大きな SQL でライブラリ全体をブロックできます。マルチコア CPU のフル活用)
2. シンプルなトランザクション、トランザクション時間はできるだけ短くする必要があります。悪い例: 画像のアップロード トランザクション
3. trig/func の使用を避け、トリガーと関数を使用せず、クライアントに置き換えます。プログラム
4. CPU、IO、メモリ、帯域幅を消費する select * は必要ありません。この種のプログラムはスケーラブルではありません

6. OR は UNION に書き換えられます

MySQL のインデックスのマージは非常に愚かです
リーリー
7. not in/like などの負の % を避ける
8. count(*) は慎重に使用してください
9.

リーリー

12. グループ化、グループ化、および自動ソートを使用します。

15. データの更新は一度に大量のデータを分割して更新しないでください。
16. リーリー
17. --log-slow-queries --long-query-time=2 を使用して、スロークエリステートメントを表示します。次に、Explain を使用してクエリを分析し、最適化を行います

最適化 データの挿入、更新、削除時には、ある程度のデータ移行とページングが避けられず、時間の経過とともに断片が蓄積され、パフォーマンスに影響を与えるため、DBA は断片を減らすためにデータベースを定期的に最適化する必要があります。これは最適化コマンドによって行われます。たとえば、MyISAM テーブルを操作する場合: テーブル テーブル名を最適化します

18. データベース内で大規模なクエリを実行することは禁止されています。
19. SQL ステートメントを 1 回解析して複数回使用するよりも効率的な、プリコンパイルされたステートメントを使用します。 rand() による order の使用は禁止されています
21. 単一の SQL ステートメントで複数のテーブルを同時に更新することは禁止されています
22. データベース内の数学的演算は避けてください (MySQL は数学的演算と論理的判断が苦手です)
23. SQL ステートメントにはすべての研究開発が必要であり、すべての SQL キーワードは大文字であり、各単語に使用できるスペースは 1 つだけです
24. NOT IN を使用できる場合は、NOTIN を使用できます。落とし穴が多すぎます。 。空と NULL をチェックアウトします

4. pt-query-digest を使用してスロークエリログを定期的に分析し、Box Anemometer と組み合わせてスロークエリログの分析と最適化を構築します。システム

今日面白いものを見ました:
どのアルゴリズム/データ構造を「認識」し、名前で知るべきですか?