本文では、TDSQL-C for MySQLクラスタ作成後の関連利用規約に関するご提案をご紹介します。
データベース権限仕様
すべてのDDL（例：テーブル作成、テーブル構造変更など）は、レビューを通過した後にのみ、DBAがデータベース管理ツール（DMC）を通じて実行し、業務閑散期にリリースされます。
権限は細粒度制御が必要であり、読み取り権限と書き込み権限を分離し、運用保守権限と開発権限を分離する必要があります。
DDL操作は操作ログを保持します。
データベースおよびテーブルの設計指針
InnoDBはMySQLにおいてトランザクションをサポートするエンジンです。MySQLデータベースでテーブルを作成し、トランザクション機能を使用する必要がある場合、必ずInnoDBエンジンを使用してテーブルを作成する必要があります。MySQLに対応する他のエンジンはトランザクションをサポートしていません。
小数型は必ずdecimal型を使用して定義し、floatやdoubleの使用は禁止します。
説明：
floatおよびdoubleは保存時に精度損失の問題が発生し、値比較時に誤った結果が得られる可能性があります。保存データの範囲がdecimalの範囲を超える場合は、データを整数部分と小数部分に分割して別々に保存することをお勧めします。
予約語の使用を禁止します。desc、range、match、delayedなどについては、MySQL公式予約語を参照してください。 データテーブルには必ず主キーが必要です。ビジネスに関連する、順序付けられ一意性のあるフィールドを主キーとして使用することも、ビジネスに関連しないオートインクリメントフィールドを主キーとして使用することも推奨されます。
説明：
主キーがないと、マスターの実行速度低下やレプリケーション遅延の問題が発生しやすくなります。
テーブル作成時には、フィールドにデフォルト値を設定し、NOT NULLに設定する必要があります。これにより、データ挿入時にNULL値や欠損値が発生するのを防ぎます。数値型のデフォルト値には0を、varcharなどの文字列型には空文字（''）を推奨します。
テーブルにはcreate_timeとupdate_timeの2つのフィールドを含めることを推奨します。いずれもdatetime型です。
説明：
データウェアハウスでのデータ抽出時には、これらの統一されたフィールドを活用することで業務確認が不要になります。
データベースに不測の事態が発生した場合、データの登録時刻や更新時刻を特定でき、障害発生時のデータ復旧判断に役立ちます。
単一テーブルのフィールド数を制御し、上限は50フィールドとします。
保存する文字列の長さがほぼ等しい場合は、char固定長文字列タイプを使用します。
フィールドの適切なテーブル間冗長化が許可されます。これにより結合クエリを回避し、クエリパフォーマンスを向上させますが、データの一貫性を考慮する必要があります。
説明：
冗長フィールドは以下の原則に従う必要があります：
頻繁に変更されないフィールド。
varcharの超長フィールドやtextフィールドではありません。
適切なストレージ長（LONG TEXTやBLOBなどの長いタイプのフィールドの使用は推奨しません）は、データベースのテーブルスペースを節約するだけでなく、インデックスのストレージも節約し、さらに重要なのは検索速度を向上させることです。
インデックス規範
フィールドタイプの違いによる暗黙的な変換を避け、それによってインデックスが無効になるのを防ぎます。
ビジネス上で一意性を持つフィールドは、複数のフィールドの組み合わせであっても、すべての一意性フィールドの最小セットにユニークインデックスを設定することを推奨します。
例：a、b、c、d、e、fフィールドを含むテーブルで、ビジネス上abとefがそれぞれ一意性を持つフィールドセットである場合、最小セットであるabとefにそれぞれユニークインデックスを設定するのが最適です。
説明：
アプリケーション層で完全な検証制御を行っていても、ユニークインデックスがなければ、不正なデータが発生する可能性があります。
同時に、作成したユニークインデックスがクエリに実際に役立つかどうかを考慮する必要があり、役に立たないインデックスは削除を検討できます。
複数のインデックスを設定することが挿入性能に与える影響を考慮する必要があり、一意性に関連するデータの正確性の要件およびパフォーマンス要件に基づいて、一意性インデックスを複数設定する必要があるかどうかを検討します。
定長フィールド（例：INT）にインデックスを設定することを推奨します。varcharフィールドにインデックスを設定する場合は、インデックス長を指定する必要があり、フィールド全体にインデックスを設定する必要はありません。実際のテキストの識別度に基づいてインデックス長を決定すればよいです。
説明：
インデックスの長さと識別度は相反する関係にあります。一般的に文字列型データの場合、長さ20のインデックスで識別度が90%以上に達することがあり、count(distinct left(列名, 索引長))/count(*)の識別度を使用して決定できます（識別度の高いものを前に、低いものを後ろに配置します）。
ページ検索では左方一致（例：SELECT * FROM users WHERE u_name LIKE '%hk'）や全一致の使用を避け、インデックススキャンからフルテーブルスキャンへの低下を防いでください。必要な場合はアプリケーション層で対応してください。
説明：
インデックスファイルはB-treeの最左端前方一致の特性を持っており、左側の値が確定していない場合、このインデックスを使用することはできません。
カバリングインデックスを利用してクエリ操作を行うことで、テーブルアクセスを回避できますが、カバリングインデックスに追加するフィールドが多すぎないように注意し、書き込み性能とのバランスを考慮する必要があります。
説明：
作成可能なインデックスの種類：主キーインデックス、ユニークインデックス、通常インデックスです。カバリングインデックスはクエリの効果の一種であり、explainの結果を利用すると、extra列に「using index」が表示されます。
SQLパフォーマンス最適化の目標：少なくともrangeレベルに達する必要があり、refレベルが求められます。可能であればconstsが最良です。
複合インデックスを作成する際は、識別度が最も高いものを左側に配置します。
単一テーブルのインデックス数は5個以内に制御するか、テーブルのフィールド数の20%を超えないようにします。
インデックス作成における以下の誤った認識を避ける：
過剰に作成しても構わないという誤った認識。一つのクエリには一つのインデックスが必要だという誤解。
過剰に作成しないという誤った認識。インデックスがスペースを消費し、更新や新規追加の速度を著しく低下させると誤解している。
ユニークインデックスを使用しない。ビジネスの一意性はすべてアプリケーション層で「先に検索してから挿入する」方法で解決できると誤って認識している。