超詳細なMySQL使用仕様の共有

最近、データベース関連の操作が多くなり、会社の既存の仕様はあまり包括的ではありません。インターネット上のさまざまな専門家の関連仕様に基づいて、自分用にいくつかの標準的な使用方法をまとめました。ご訂正いただければ幸いです。

データベース環境

dev: 開発環境

開発者はテーブル構造を読み取り、書き込み、変更できます。開発者はテーブル構造とその中のデータを自由に変更できますが、他の開発者に影響を与えないようにする必要があります。

テスト: テスト環境

開発者は読み取りと書き込みが可能で、開発者はツールを使用してテーブル構造を変更できます。

オンライン: オンライン環境

開発者はオンライン環境で直接データベース操作を実行することはできません。操作が必要な場合は、DBA を見つけて操作を実行し、対応する記録を作成する必要があります。ストレステストは禁止されています。

重要な問題は、各環境の MySQL サーバーに対応するユーザー権限が明確に分割され、認識可能であり、ビジネスシナリオを具体的に区別できる必要があることです。

命名規則

基本的な命名ルール

意味のある英語の単語を使用し、単語をアンダースコアで区切ります。（ピンインは使用しないでください）
使用できるのは英語の文字、数字、アンダースコアのみで、名前は英語の文字で始まる必要があります。
ライブラリ、テーブル、フィールドはすべて小文字にする必要があります。キャメルケースは使用しないでください。
desc などの ORACLE および MySQL の予約語や index などのキーワードの使用は避けてください。
名前は 32 文字を超えることはできません。名前の意味は明確である必要があります。動詞の代わりに名詞を使用することをお勧めします。
データベースとテーブルはすべてプレフィックスを使用します
一時データベース名とテーブル名には、先頭に tmp を付け、末尾に日付を付ける必要があります。
バックアップデータベースとテーブルには、先頭に bak、末尾に日付を付ける必要があります。

すべてのライブラリ、テーブル、フィールドが小文字なのはなぜですか?

MySQL では、データベースとテーブルはディレクトリとそのディレクトリ内のファイルに対応します。したがって、オペレーティングシステムの感度によって、データベース名とテーブル名の大文字と小文字の区別が決まります。

Windows では大文字と小文字は区別されません。
Linuxケースルール
データベース名とテーブル名では大文字と小文字が厳密に区別されます。
テーブルエイリアスでは大文字と小文字が厳密に区別されます。
列名と列エイリアスでは、大文字と小文字は区別されません。
変数名も厳密に大文字と小文字が区別されます。
キャメルケース命名が設定されている場合、どうすれば解決できますか? MySQL 構成ファイル my.ini に lower_case_table_names = 1 を追加するだけです。

テーブル名

同じモジュール内のテーブルでは、可能な限り同じプレフィックスを使用し、テーブル名は可能な限り意味のあるものにする必要があります。すべてのログテーブルはlog_で始まります。

フィールドの命名

実際の意味を表す英語の単語または略語。ブールフィールドには、is_ という接頭辞が付き、その後に動詞の過去分詞が続きます。
各テーブル内の同じ意味を持つフィールドには、同じ名前を付ける必要があります。テーブル間で同じ意味を持つフィールドには、モジュールプレフィックスを除いたテーブル名_フィールド名で名前が付けられます。
外部キーフィールドは、テーブル名_フィールド名を使用して関連関係を示します。
テーブルの主キーは通常、自動増分型の id とされ、他のテーブルの外部キーは xxx_id の形式で表現されます。

インデックスの命名

一意でないインデックスは、「idx_フィールド名_フィールド名[_フィールド名]」という名前にする必要があります。
一意のインデックスは「uniq_field name_field name[_field name]」という名前にする必要があります

制約の命名

主キー制約: pk_table 名。
一意制約: uk_テーブル名_フィールド名。 (アプリケーション内で一意性チェックロジックも必要です。)

テーブル設計仕様

テーブルエンジンは実際のアプリケーションシナリオによって異なります。ログテーブルとレポートテーブルには MyISAM が推奨され、トランザクション、監査、金額に関連するテーブルには InnoDB が推奨されます。特に指定がない限り、テーブルの作成時には innodb エンジンが使用されます。

デフォルトの文字セットはutf8mb4で、データベースの照合ルールはutf8mb4_general_ciです。（データベース定義はデフォルトを使用しているため、データテーブルを再定義できますが、安全のために、次のように記述することをお勧めします。

文字セットで utf8 が選択されず、照合順序で utf8_general_ci が使用されないのはなぜですか?

utf8 エンコーディングを使用する MySQL では、プレースホルダーとして 4 バイトを使用する絵文字表現を保存できません。バックエンドプロジェクトがクライアントによって入力された絵文字表現を完全にサポートするようにするには、エンコーディングを utf8mb4 にアップグレードするのが最善の解決策です。 JDBC 接続文字列の characterEncoding が utf8 に設定されている場合、または上記の設定後に絵文字データを正常に挿入できない場合は、コードで接続の文字セットを utf8mb4 として指定する必要があります。

すべてのテーブルとフィールドでは、コメント列属性を使用して、テーブルまたはフィールドの真の意味を記述する必要があります。列挙値の場合は、フィールドで使用されるコンテンツを定義することをお勧めします。

特に指定がない限り、テーブルの最初の id フィールドは主キーであり、自動的に増分される必要があります。トランザクション外でのデータ転送のコンテキストまたは条件としてこれを使用することは禁止されています。主キーステートメントの設計として varchar を使用しないでください。

特に指定がない限り、テーブルには create_time フィールドと modify_time フィールドが含まれている必要があります。つまり、テーブルには作成時刻と変更時刻を記録するフィールドが含まれている必要があります。

特に指定がない限り、テーブルにはデータが削除されたかどうかを示す is_del が含まれている必要があります。原則として、データベースデータの物理的な削除は許可されません。

フィールドのデータを保存するのにできるだけ少ないストレージスペースを使用する
int が使用できる場合は char または varchar を使用しないでください。
tinyint が使える場合は int を使わない
負でない値を格納するには UNSIGNED を使用します。
ENUM 型と SET 型の使用は推奨されません。代わりに TINYINT を使用してください。
短いデータ型を使用します。たとえば、値の範囲が 0 ～ 80 の場合は、TINYINT UNSIGNED を使用します。
正確な浮動小数点数を保存するには、FLOAT や DOUBLE の代わりに DECIMAL を使用する必要があります。
時間フィールドは、特別な場合を除き、unix_timestampを記録するためにintを使用します。
年を保存するには、YEAR 型を使用します。
日付を保存するには、DATE 型を使用します。
TIMESTAMP は 4 バイト、DATETIME は 8 バイトを使用するため、時間 (秒単位の精度) を保存するには TIMESTAMP 型を使用することをお勧めします。
IPV4 を保存するには INT UNSIGNED を使用することをお勧めします。
できる限り TEXT 型と BLOB 型の使用は避けてください。
画像やファイルなどを保存するためにデータベースで VARBINARY および BLOB を使用することは禁止されています。他のストレージ方法 (TFS/SFS) を使用することをお勧めします。MySQL はポインタ情報のみを保存します。
1つのレコードのサイズは8k（列の長さ（中国語）_3（UTF8）+列の長さ（英語）_1）を超えることはできません。

datetime と timestamp の違いは何ですか?

類似点:

TIMESTAMP 列の表示形式は DATETIME 列の表示形式と同じです。表示幅は 19 文字に固定され、形式は YYYY-MM-DD HH:MM:SS です。

違い:

タイムスタンプ

4 バイトは、時間範囲 1970-01-01 08:00:01 ~ 2038-01-19 11:14:07 を保存するために使用されます。値は UTC 形式で保存され、タイムゾーンの変換が行われます。保存時に現在のタイムゾーンが変換され、取得時に現在のタイムゾーンに再変換されます。
datetime は 8 バイトで保存され、時間の範囲は 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 です。
タイムゾーンに関係なく、実際のフォーマットが保存されます

TIMESTAMP の自動割り当てプロパティを使用するにはどうすればよいでしょうか?

ts のデフォルト値として現在の時刻を使用します: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP。行が更新されると、ts の値を更新します: ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP。

1 と 2 を組み合わせることができます: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。

INT UNSIGNED を使用して IP を保存するにはどうすればよいですか?

IPv4 アドレスを保存するには、char(15) ではなく INT UNSIGNED を使用し、MySQL 関数 inet_ntoa および inet_aton を使用して変換します。現在、IPv6 アドレスの変換関数は存在せず、DECIMAL または 2 つの bigINT を使用して保存する必要があります。

注釈がない場合、すべてのフィールドは NOT NULL に設定され、デフォルト値が設定されます。
プレーンテキストのパスワードをデータベースに保存しない
コメントがない場合、is_hot や is_deleted などのすべてのブールフィールドのデフォルト値は 0 に設定する必要があります。
特に注釈がない場合、ソートフィールド order_id はプログラム内でデフォルトで降順でソートされます。
整数定義に長さを追加しないでください。たとえば、INTの代わりにINTを使用してください[4]

INT[M]、Mの値は何を表していますか？

数値型の括弧の後の数字は幅のみを示し、ストレージ範囲とは関係がないことに注意してください。多くの人は、INT(4)とINT(10)の値の範囲はそれぞれ(-9999〜9999)と(-9999999999〜999999999999であると考えていますが、この理解は誤りです。実際、整数型のM値をZEROFILL属性と組み合わせて使用すると、列の値の幅を均等にすることができます。 INT[M]のMの値に関係なく、その値の範囲は（符号付きの場合-2147483648〜2147483647）、（符号なしの場合0〜4294967295）です。

表示幅は、列に保持できる値の範囲を制限するものではなく、指定された列の幅を超える値の表示を制限するものでもありません。オプションの拡張属性 ZEROFILL と組み合わせて使用すると、デフォルトでは追加のスペースがゼロに置き換えられます。たとえば、INT(5) ZEROFILLとして宣言された列の場合、値4は00004として取得されます。表示幅を超える値を整数列に格納すると、MySQL が複雑な結合の一時テーブルを生成するときに問題が発生する可能性があることに注意してください。これは、このような場合、MySQL はデータが元の列幅に収まると判断するためです。数値列に ZEROFILL を指定すると、MySQL は列に UNSIGNED 属性を自動的に追加します。

VARBINARY を使用して大文字と小文字を区別する可変長文字列を保存する

CHAR と VARCHAR はいつ使用すればよいのでしょうか?

CHAR 型と VARCHAR 型は似ていますが、保存方法と取得方法が異なります。また、最大長や末尾のスペースが保持されるかどうかという点でも異なります。 CHAR 型と VARCHAR 型に対して宣言された長さは、保存する文字の最大数を示します。たとえば、CHAR(30)は30文字を占めることができます。

CHAR 列の長さは、テーブルの作成時に宣言された長さに固定されます。長さは 0 から 255 までの任意の値にすることができます。 CHAR 値が格納される際、指定された長さまで右側にスペースが埋め込まれます。 CHAR値が取得されると、末尾のスペースは削除されます。保存または取得中に大文字と小文字の変換は実行されません。

VARCHAR 列の値は可変長文字列です。長さは 0 から 65,535 までの値として指定できます。 (VARCHAR の最大有効長は、最大行サイズと使用される文字セットによって決まります。全体の最大長は 65,532 バイトです)。 CHAR とは対照的に、VARCHAR 値は必要な文字数のみで保存され、長さを記録するための追加バイトが追加されます (列の宣言された長さが 255 を超える場合は 2 バイトが使用されます)。 VARCHAR値はパディングなしで保存されます。標準 SQL に準拠して、値が保存および取得されるときに末尾のスペースが保持されます。

char はユーザーのパスワードの MD5 ハッシュを保存するのに適しており、その長さは常に同じです。頻繁に変更される値の場合、固定長の行は断片化される可能性が低いため、char は varchar よりも適しています。非常に短い列の場合も、char は varchar よりも効率的です。 char(1) 文字列はシングルバイト文字セットでは 1 バイトしか占有しませんが、varchar(1) 文字列は長さ情報を格納するために 1 バイトが使用されるため 2 バイトを占有します。

インデックス設計仕様

MySQL のクエリ速度は適切なインデックス設計に依存するため、高パフォーマンスにはインデックスが不可欠です。適切なインデックスはクエリを高速化します (UPDATE および DELETE の速度も含む)。MySQL は行を含むページをメモリにロードしてから UPDATE または DELETE 操作を実行します。不適切なインデックスはクエリを低速化します。 MySQL のインデックス検索は、新華辞書のピンインと部首の検索に似ています。ピンインと部首のインデックスが存在しない場合は、ページを 1 つずつめくって検索するしかありません。 MySQL クエリがインデックスを使用できない場合、MySQL は完全なテーブルスキャンを実行し、大量の IO を消費します。インデックスの目的: 重複排除、高速ポジショニング、ソートの回避、カバーインデックス。

カバーインデックスとは何ですか?

InnoDB ストレージエンジンでは、セカンダリインデックス (非主キーインデックス) に行アドレスが直接格納されるのではなく、主キーの値が格納されます。ユーザーがセカンダリインデックスに含まれていないデータ列をクエリする必要がある場合、ユーザーは最初にセカンダリインデックスを通じてプライマリキー値を見つけ、次にプライマリキーを通じて他のデータ列をクエリする必要があるため、クエリを 2 回実行する必要があります。カバーリングインデックスの概念は、クエリを 1 つのインデックスで完了できることです。カバーリングインデックスの効率はより高くなり、主キークエリは自然なカバーリングインデックスです。カバーリングインデックスを使用する場合、インデックスを適切に作成し、クエリステートメントを適切に使用するとパフォーマンスが向上します。たとえば、SELECT email,uid FROM user_email WHERE uid=xx です。uid が主キーでない場合は、index(uid,email) としてインデックスを追加してパフォーマンスを向上させることができます。

基本的なインデックス仕様

インデックス数量制御: 1 つのテーブル内のインデックス数は 5 を超えてはならず、1 つのインデックス内のフィールド数も 5 を超えてはなりません。
データ密度と分布の総合評価
クエリと更新の比率を考慮する

テーブル内のインデックスが多すぎるのはなぜいけないのでしょうか?

InnoDB のセカンダリインデックスはストレージに b+tree を使用するため、UPDATE、DELETE、INSERT 中に b+tree を調整する必要があります。インデックスが多すぎると、更新プロセスが遅くなります。

文字列にはプレフィックスインデックスを使用します。プレフィックスインデックスの長さは 8 文字を超えてはなりません。プレフィックスインデックスを優先することをお勧めします。必要に応じて、疑似列を追加してインデックスを作成します。

BLOB/テキストフィールドをインデックスしないでください。また、大きなフィールドをインデックスしないでください。インデックスによってストレージ領域が大量に消費されることになります。

プレフィックスインデックスとは何ですか?

簡単に言えば、プレフィックスインデックスとは、テキストの最初の数文字のインデックスを作成することです (インデックスを作成するときに、特定の文字数を指定します)。これにより、作成されるインデックスが小さくなるため、クエリが高速になります。プレフィックスインデックスを使用すると、インデックスファイルのサイズを効果的に削減し、インデックス作成速度を向上させることができます。しかし、プレフィックスインデックスにも欠点があります。MySQL では、プレフィックスインデックスを ORDER BY または GROUP BY で使用することはできず、カバーインデックスとして使用することもできません。

プレフィックスインデックスを作成するための構文は次のとおりです: ALTER TABLE table_name ADD KEY(column_name(prefix_length));

主キー基準

テーブルには主キーが必要です
頻繁に更新される列は使用しないでください
文字列列を選択しないようにしてください
UUID MD5ハッシュは使用しないでください
デフォルトで非NULLの一意のキーを使用する
自動増分または数値ジェネレータを選択することをお勧めします

重要な SQL はインデックス化する必要があり、コア SQL にはインデックスをカバーする優先順位を与える必要があります。

UPDATE および DELETE ステートメントの WHERE 条件列
ORDER BY、GROUP BY、DISTINCT のフィールド
複数テーブル結合のフィールド

最も特徴的なフィールドが最初に配置される

注文番号、ユーザー ID など、フィルタリングプロパティがより優れたフィールドを選択して先頭に配置します。通常、タイプやステータスなど、フィルタリングプロパティがより優れたフィールドを先頭に配置することは推奨されません。
インデックスは左プレフィックスの原則に従います。結合インデックス (a, b, c) が作成されると、クエリ条件に (a) または (a, b) または (a, b, c) が含まれている場合にのみインデックスを使用できます。 (a, c) を条件として使用すると、列 a のインデックスのみを使用できます。したがって、a によって返される列の数が多すぎないようにする必要があります。そうしないと、ステートメントの設計が不合理になります。 (b, c) は使用できません。
適切に結合インデックスを作成します（冗長性を避けます）。(a,b,c) は (a)、(a,b)、(a,b,c) と同等です。

インデックスタブー

「性別」などのカーディナリティの低い列にはインデックスを作成しないでください。
インデックス列に対して数学演算や関数演算を実行しないでください
頻繁に使用される小さなテーブルにはインデックスを付けない
外部キーの使用を避ける
外部キーは参照整合性を保護するために使用され、ビジネス側で実装できます。
親テーブルと子テーブルに対する操作は相互に影響を及ぼし、可用性が低下します。
INNODB のオンライン DDL に関する独自の制限

MYSQL のインデックスの制限

MYISAM ストレージエンジンインデックスの合計長は 1000 バイトを超えることはできません。
BLOBおよびTEXT型の列ではプレフィックスインデックスのみ作成できます
MYSQL は現在、関数インデックスの使用をサポートしていません。不等号 (!= または <>) が使用されている場合、MYSQL はインデックスを使用できません。
フィルターフィールドで関数操作 (abs (列) など) を使用した後、MYSQL はインデックスを使用できなくなります。
結合ステートメントの結合条件フィールドタイプが矛盾している場合、MYSQL はインデックスを使用できません。LIKE 操作を使用する場合、条件がワイルドカード ('%abc...' など) で始まると、MYSQL はインデックスを使用できません。
等しくない値のクエリを使用する場合、MYSQL はハッシュインデックスを使用できません。

ステートメントデザイン仕様

準備されたステートメントの使用

パラメータのみを渡す方がSQL文を渡すよりも効率的です。
一度解析すれば何度でも使える
SQLインジェクションの可能性を減らす

暗黙的な変換を避ける

これによりインデックスが失敗する

プレフィックスインデックスを活用する

一番左の接頭辞である必要があります
2つの範囲条件を同時に使用することはできません
% の先頭文字を使用しないクエリ (例: "%ab")

not in/likeなどの否定的なクエリは使用しないでください。

インデックスを使用できないため、テーブル全体がスキャンされます
フルテーブルスキャンによりバッファプールの使用率が減少する

ストアドプロシージャ、トリガー、UDF、イベントなどの使用は避けてください。

データベースに最善を尽くさせる
ビジネスの結合を減らしてシャーディングとシャーディングの余地を残す
バグの回避

大きなテーブルでのJOINを避ける

MySQLは単一テーブルの主キー/セカンダリインデックスクエリに最適です。
JOINはより多くのメモリを消費し、一時テーブルを生成します。

データベースで計算を行わないようにする

MySQLは数学的な演算や論理的な判断が苦手です
インデックスを使用できません

データベースとのやり取りの回数を減らす

重複キーの更新時に挿入...
REPLACE INTO、INSERT IGNORE、INSERT INTO VALUES()、()、()
更新...WHERE ID IN (10,20,50,…)

ページングを適切に使用する

ページネーションで表示されるページ数を制限します。前のページと次のページのみクリックできます。遅延関連付けが使用されます。

ページングを正しく使用するにはどうすればいいですか?

次のようなページングステートメントがあるとします: SELECT * FROM table ORDER BY id LIMIT 10000, 10。MySQL が LIMIT OFFSET を処理する方法は、OFFSET+LIMIT のすべてのデータを取得し、次に OFFSET を削除して、一番下の LIMIT を返すことです。したがって、OFFSET 値が大きい場合、MySQL のクエリパフォーマンスは非常に低下します。これは id > n を使用することで解決できます。

id > n を使用する方法には制限があります。ページをめくるときに最後の id を同時に渡すことで、不連続な id の問題は解決できます。

http://example.com/page.php?last=100 
テーブルから * を選択、ID が 100 未満、ID で並べ替え、降順、制限 10 
//前のページ http://example.com/page.php?first=110 
テーブルから * を選択し、ID が 110 より大きい場合は、ID で並べ替え、降順で制限を 10 にします。

この方法の最大の欠点は、閲覧中に挿入/削除操作があった場合、ページが更新されず、ページの合計数が新しいカウント(*)に基づいて計算され、最終的に一部のレコードにアクセスできなくなる可能性があることです。この問題を解決するには、現在のページ番号と、最後のページめくり以降のレコードの合計数に影響する挿入/削除などの操作があったかどうかを引き続き入力し、それらをキャッシュします。

テーブルから * を選択、ID >= (テーブルから ID を選択、ID 制限 #offset#、1 で順序付け)

大きなSQLを拒否し、小さなSQLに分割する
クエリキャッシュを活用する
マルチコアCPUを活用する
or の代わりに in を使用してください。in の値は 1000 を超えてはなりません。
rand() による順序を使用しないでください
EXPLAIN診断を使用して一時テーブルの作成を回避する

EXPLAIN ステートメント (MySQL クライアントで実行) は、MySQL が SELECT ステートメントを実行する方法に関する情報を取得できます。 SELECT ステートメントで EXPLAIN を実行すると、SELECT ステートメントの実行時に MySQL がインデックス、完全なテーブルスキャン、一時テーブル、ソートなどの情報を使用するかどうかを知ることができます。 MySQL による完全なテーブルスキャン、一時テーブルの使用、ソートなどの実行は避けてください。詳細については公式ドキュメントを参照してください。

unionの代わりにunion allを使用する

union all と union の違いは何ですか?

union キーワードと union all キーワードはどちらも 2 つの結果セットを 1 つに結合しますが、使用方法と効率の点で 2 つは異なります。

結合テーブルがリンクされた後、重複レコードは除外されるため、テーブルがリンクされた後、結果セットがソートされ、重複レコードが削除されてから結果が返されます。のように：

test_union1 から * を選択 
ユニオンはtest_union2から*を選択します

この SQL を実行すると、まず 2 つのテーブルの結果が取得され、次にソートスペースを使用して重複レコードがソートおよび削除され、最後に結果セットが返されます。テーブル内のデータ量が多い場合は、ディスクソートが行われる場合があります。

Union all は、単に 2 つの結果を結合して返します。この方法では、返された 2 つの結果セットに重複データがある場合、返された結果セットには重複データが含まれます。

効率の点では、union all の方が union よりもはるかに高速なので、2 つのマージされた結果セットに重複データが含まれていないことを確認できる場合は、次のように union all を使用します。

test_union1 から * を選択、union all から * を選択、test_union2 から * を選択

プログラムにはSQL例外を捕捉するメカニズムが必要である
単一のSQL文が複数のテーブルを同時に更新するのを防ぐ
select * を使用しないでください。SELECT ステートメントは必要なフィールドのみを取得します。
CPUとIOを消費し、ネットワーク帯域幅を消費する
カバーインデックスは使用できません
テーブル構造の変更による影響を軽減する
大きいため、選択/結合により一時テーブルが生成される場合があります。
UPDATEおよびDELETEステートメントではLIMITは使用されません
INSERT文ではフィールド名を明示的に指定する必要があり、INSERT INTO table()は使用しないでください。
INSERT ステートメントはバッチ (INSERT INTO table VALUES(),(),()…) を使用して送信され、値の数は 500 を超えません。
テーブル内のレコード数をカウントする場合は、COUNT(primary_key) および COUNT(1) の代わりに COUNT(*) を使用します。注: これは MyISAM にのみ適用されます。
データの更新では、セカンダリインデックスを使用して最初にプライマリキーをクエリし、次にプライマリキーに基づいてデータを更新することをお勧めします。
データベース間のクエリは禁止されています
サブクエリは禁止されています。サブクエリを関連クエリに変換することをお勧めします。
varchar 型フィールドのプログラム処理では、ユーザー入力を確認し、事前設定された長さを超えないようにしてください。

テーブル仕様

1～2年以内に単一テーブルのデータ量が500万を超える場合や、データ容量が10Gを超える場合は、テーブル分割を検討してください。履歴データの移行や履歴データのアプリケーションによる自己削除を事前に検討する必要があります。均等分割やバランス分割、ビジネスルールに従った分割などをご利用いただけます。分割するデータテーブルについては、DBAと分割戦略について話し合う必要があります。

HASHを使用してテーブルを分散し、テーブル名の接尾辞として10進数を使用し、添え字は0から始まります。
日付と時刻で区切られた表は、YYYY[MM][dd][HH]の形式に準拠する必要があります。
適切なデータベースおよびテーブルシャーディング戦略を採用します。たとえば、1000 個のライブラリと 10 個のテーブル、100 個のライブラリと 100 個のテーブルなどです。
パーティションテーブルの使用は禁止されています。パーティションテーブルには、パーティションキーに関する厳しい要件があります。パーティションテーブルが大きくなるにつれて、DDL、シャーディング、および単一テーブルのリカバリを実行することが難しくなります。
大きなフィールドとアクセス頻度の低いフィールドを分割して、ホットデータとコールドデータを分離します。

行動規範