必須データベース使用仕様

5604 ワード

ガイド:MySQLデータベースの仕様については、いくつかのドキュメントを見たことがあると思います.この文章はみんなに詳しく分類してデータベースの関連規範を総括して、ライブラリの表の命名の設計規範から話して、インデックスの設計規範まで、後でまたSQLの編纂の方面の提案を提供します.これらの仕様は多くの企業に適用されると信じており、仕様に従ってデータベースを使用することで、より高いパフォーマンスを発揮することができます.
ライブラリについて:
  • 【強制】ライブラリの名前は32文字以内に制御し、英語はすべて小文字にしなければならない.
  • 【強制】ライブラリ名フォーマット:ビジネスシステム名_サブシステム名.
  • 【強制】ライブラリ名は、英字、数字、下線のみを使用し、英字で始まります.
  • 【強制】データベースを作成するときは、文字セットを明示的に指定する必要があります.文字セットはutf 8またはutf 8 mb 4のみです.データベースSQLの作成例:Create database db 1 default character set utf 8;
  • 【推奨】テンポラリ・ライブラリ、テーブル名はtmp_をプレフィックスとし、日付を接尾辞とし、バックアップ・ライブラリ、テーブルはbak_をプレフィックスとし、日付を接尾辞とする.

  • テーブルについて
  • 【強制】表と列の名前は32文字以内に制御する必要があります.表名はアルファベット、数字、下線しか使用できません.すべて小文字です.
  • 【強制】表名はモジュール名に強く関連することを要求し、同じモジュールで使用される表名はできるだけ統一接頭辞を使用する.
  • 【強制】テーブルを作成するときは、utf 8またはutf 8 mb 4の文字セットを明示的に指定する必要があります.
  • 【強制】カラム名は、できるだけキーワード(type、orderなど)を使用しないでください.
  • 【強制】表を作成する際には、表ストレージエンジンのタイプを明示的に指定する必要があります.特別な要件がない場合は、すべてInnoDBです.
  • 【強制】建表にはコメントが必要です.
  • 【強制】100 W行を超える大きなテーブルに対してalter tableを行うには、DBAの監査を経て、業務の低ピーク期間に実行しなければならず、複数のalterを統合する必要がある.alter tableはテーブルロックを生成するため、テーブルに対するすべての書き込みをブロックし、ビジネスに大きな影響を及ぼす可能性があります.
  • 【推奨】テーブルの構築時にプライマリ・キーについて:テーブルにプライマリ・キー(1)が必要で、プライマリ・キーをid、タイプをintまたはbigint、auto_incrementではunsigned符号なしタイプを推奨します.(2)表内の各行の本体を識別するフィールドはメインキーにしないで、user_のような他のフィールドにすることを推奨するid,order_idなど、unique keyインデックスを作成します.プライマリ・キーを設定し、プライマリ・キー値をランダムに挿入すると、innodb内部のpage分裂と大量のランダムI/Oが発生し、パフォーマンスが低下するためです.
  • 【推奨】ユーザー・テーブルなどのコア・テーブルには、行データの作成時間フィールドcreate_が必要です.timeと最終更新時間フィールドupdate_time、問題を調べるのに便利です.
  • 【推奨】表のすべてのフィールドは、必要に応じてDEFAULT値を定義できるように、NOT NULL属性であることが望ましい.NULL値を使用すると、行ごとに余分なストレージ容量が消費され、データの移行にエラーが発生しやすくなり、集約関数の計算結果のばらつきなどの問題が発生します.
  • 【推奨】中間テーブルは、tmp_で始まる名前の中間結果セットを保持するために使用されます.バックアップ・テーブルは、ソース・テーブルのスナップショットをバックアップまたはキャプチャするために使用されます.名前はbak_で始まる必要があります.中間テーブルとバックアップテーブルは定期的にクリーンアップされます.
  • 【模範】比較的規範的な建表文:
    CREATE TABLE user_info (
      `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT '    ',
      `user_id` bigint(11) NOT NULL COMMENT '  id',
      `username` varchar(45) NOT NULL COMMENT '    ',
      `email` varchar(30) NOT NULL COMMENT '    ',
      `nickname` varchar(45) NOT NULL COMMENT '  ',
      `birthday` date NOT NULL COMMENT '  ',
      `sex` tinyint(4) DEFAULT '0' COMMENT '  ',
      `short_introduce` varchar(150) DEFAULT NULL COMMENT '       ,  50   ',
      `user_resume` varchar(300) NOT NULL COMMENT '           ',
      `user_register_ip` int NOT NULL COMMENT '       ip',
      `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '    ',
      `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '    ',
      `user_review_status` tinyint NOT NULL COMMENT '        ,1   ,2    ,3    ,4       ',
      PRIMARY KEY (`id`),
      UNIQUE KEY `uniq_user_id` (`user_id`),
      KEY `idx_username`(`username`),
      KEY `idx_create_time_status`(`create_time`,`user_review_status`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='        '
  • 索引について
  • 【強制】InnoDBテーブルにはid int/bigint auto_のプライマリ・キーが必要ですincrementで、プライマリ・キー値の更新が禁止されています.
  • 【強制】InnoDBとMyISAMストレージエンジンテーブル、インデックスタイプはBTREEである必要があります.
  • 【推奨】プライマリ・キーの名前はpk_で始まり、ユニーク・キーはuniq_またはuk_で始まり、通常のインデックスはidx_で始まり、すべて小文字フォーマットを使用し、フィールドの名前または略語を接尾辞として使用します.
  • 【推奨】単一テーブルのインデックス数は8個を超えてはならない.
  • 【推奨】インデックスを作成する際には、連合インデックスの作成を多く考慮し、最も分割度の高いフィールドを先頭に置く.列useridの区別度はselect count(distinct userid)によって計算することができる.
  • 【推奨】マルチテーブルjoinのSQLでは、被駆動テーブルの接続列にインデックスがあることを保証し、joinの実行効率が最も高い.
  • 【推奨】テーブルを構築したり、インデックスを追加したりする場合、テーブルに冗長インデックスが存在しないことを保証します.MySQLでは、テーブルにkey(a,b)が既に存在する場合、key(a)は冗長インデックスであり、削除する必要があります.

  • SQL作成
  • 【強制】プログラム側SELECT文は具体的なフィールド名を指定しなければならない.
  • 【強制】プログラム側insert文は、insert into t 1 values(...)と書かないで、特定のフィールド名を指定します.
  • 【強制】静的テーブルまたは小さなテーブル(100行以内)を除き、DML文にはwhere条件があり、インデックス検索を使用する必要があります.
  • 【強制】where条件では、等号の左右のフィールドタイプが一致する必要があります.そうしないと、インデックスは利用できません.
  • 【強制】WHERE句では、フルファジイLIKE条件のみで検索することは禁止されています.他の等値または範囲クエリー条件が必要です.そうしないと、インデックスは使用できません.
  • 【強制】インデックス列は、関数または式を使用しないでください.そうしないと、インデックスは使用できません.例えばwhere length(name)='Admin'またはwhere user_id+2=10023.
  • 【推奨】insert into...values(XX),(XX),(XX),(XX)..ここでXXの値は5000個を超えないでください.値が多すぎると、オンラインが速くなりますが、プライマリ・スレーブの同期遅延が発生します.
  • 【推奨】SELECT文ではUNIONを使用せず、UNIOALLを使用することを推奨し、UNION句の数を5個以内に制限します.union allは、データベース・リソースを節約し、パフォーマンスを向上させる必要がないためです.
  • 【強制】dbにまたがるjoin文を禁止します.
  • 【推奨】サブクエリの使用は推奨されません.サブクエリSQLを結合プログラムから複数のクエリに分割するか、サブクエリの代わりにjoinを使用することを推奨します.
  • 【推奨】オンライン環境、マルチテーブルjoinは5つのテーブルを超えないでください.
  • 【推奨】マルチテーブルjoinでは、できるだけ結果セットの小さいテーブルをドライバテーブルとして選択し、他のテーブルをjoinします.
  • 【推奨】一括操作データの場合、トランザクション間隔時間を制御し、必要なsleepを行う必要があります.
  • 推奨」トランザクションにはSQLが5つ以上含まれていません.長すぎるトランザクションはロックデータが長くなり、MySQLの内部キャッシュ、接続消費が多すぎるなどの問題があります.
  • 【推奨】トランザクションで文を更新するには、update...where id=XXなどのプライマリ・キーまたはunique keyに基づいてください.ギャップロックが発生し、内部がロック範囲を拡大し、システムのパフォーマンスが低下し、デッドロックが発生します.
  • 【推奨】order byの使用を減らし、ビジネスとのコミュニケーションをソートせずにソートしたり、ソートをプログラム側に置いたりすることができます.Order by、group by、distinctなどの文はCPUを消費し、データベースのCPUリソースは極めて貴重です.
  • 【推奨】order by、group by、distinctといったSQLは、できるだけインデックスを利用して並べ替えられたデータを直接取得します.例えばwhere a=1 order by bはkey(a,b)を利用することができる.
  • 【推奨】order by、group by、distinctなどのクエリーの文が含まれています.where条件でフィルタされた結果セットは1000行以内にしてください.そうしないとSQLは遅くなります.