58同城Mysqlデータベース設計原則(回転)
2787 ワード
(一)核心原則
(1)データベースで演算しない
cpu計算は必ず業務層に移動しなければならない.
(2)制御テーブルデータ量
int型は1000 wを超えず、charを含むと500 wを超えない.合理的に表を分ける.制限単庫表の数は300以内である.
(3)制御列数
フィールドは少なくて精巧で、フィールド数は20以内であることを提案します;
(4)バランスパターンと冗長性
効率優先;往々にしてパターンを犠牲にする.
(5)3 Bの拒絶
(二)フィールド類の原則
(6)数値タイプをうまく使う
(7)文字を数字に変換
char(15)ではなくintでipを格納する
(8)enumまたはsetを優先的に使用
例:`sex`enum(‘F’,‘M’)
(9)NULLフィールドの使用を避ける
(10)text/blobの使用を控える
varcharの性能はtextよりずっと高いです.blobは本当に避けられません.表を外してください.
(11)データベースに画像を保存しない
これは理解できません!しかし、これはネットの経験を集めて、detailを求めます!
(三)インデックスクラスの原則
(12)インデックスの適切な使用
クエリーを改善し、更新を遅らせる.インデックスは多ければ多いほど良いわけではありません(追加しないで、追加しなければならないものは必ず追加しなければなりません).上書きレコードの数が多すぎると、「性別」などのインデックスを作成するのに適していません.
(13)文字フィールドに接頭辞インデックスを作成する必要がある
(14)インデックスにカラム演算をしない
(15)innodbプライマリ・キーは自己増分列の使用を推奨する.
プライマリ・キーはクラスタ・インデックスを確立します.プライマリ・キーは変更されるべきではありません.文字列はプライマリ・キーにすべきではありません.プライマリ・キーを指定しない場合、innodbは一意で空でないインデックスで置き換えられます.
(16)外部キーを使わない
プログラムによって制約を保証してください.
(四)sql類の原則
(17)sql文はできるだけ簡単
1本のsqlは1つのcpuでしか演算できません.大きい文は小さい文を分解して、ロック時間を減らします;大きなsqlはライブラリ全体を塞ぐことができます.
(18)単純なトランザクション
(19)trig/funcの使用を避ける
トリガ、関数は使いません.クライアントプログラムの代わりに;
(20)selectを使わない*
cpu、io、メモリ、帯域幅を消費します.このプログラムは拡張性がない.
(21)ORをIN()に書き換える
(22)OR UNIONに書き換える
(23)マイナス方向を避ける
(24)countを慎む(*)
(25)limitの効率的なページング
(26)unionの代わりにunion allを使用する
unionはオーバーヘッドがある
(27)接続joinを少なくする
(28)groupbyの使用
グループ化;自動ソート;
(29)同型比較を使用してください
(30)load dataを用いてデータを導く
load dataはinsertより約20倍速い.
(31)分散一括更新
(32)新エネルギー分析ツール
テキストhttp://www.html5wd.com/archives/1090.html
(1)データベースで演算しない
cpu計算は必ず業務層に移動しなければならない.
(2)制御テーブルデータ量
int型は1000 wを超えず、charを含むと500 wを超えない.合理的に表を分ける.制限単庫表の数は300以内である.
(3)制御列数
フィールドは少なくて精巧で、フィールド数は20以内であることを提案します;
(4)バランスパターンと冗長性
効率優先;往々にしてパターンを犠牲にする.
(5)3 Bの拒絶
sql :big sql
:big transaction
:big batch
(二)フィールド類の原則
(6)数値タイプをうまく使う
tinyint(1Byte)
smallint(2Byte)
mediumint(3Byte)
int(4Byte)
bigint(8Byte)
bad case:int(1)/int(11)
(7)文字を数字に変換
char(15)ではなくintでipを格納する
(8)enumまたはsetを優先的に使用
例:`sex`enum(‘F’,‘M’)
(9)NULLフィールドの使用を避ける
NULL ;
NULL ;
NULL ;
bad case:
`name` char(32) default null
`age` int not null
good case:
`age` int not null default 0
(10)text/blobの使用を控える
varcharの性能はtextよりずっと高いです.blobは本当に避けられません.表を外してください.
(11)データベースに画像を保存しない
これは理解できません!しかし、これはネットの経験を集めて、detailを求めます!
(三)インデックスクラスの原則
(12)インデックスの適切な使用
クエリーを改善し、更新を遅らせる.インデックスは多ければ多いほど良いわけではありません(追加しないで、追加しなければならないものは必ず追加しなければなりません).上書きレコードの数が多すぎると、「性別」などのインデックスを作成するのに適していません.
(13)文字フィールドに接頭辞インデックスを作成する必要がある
(14)インデックスにカラム演算をしない
!!! , !!!
bad case:
select id where age +1 = 10;
(15)innodbプライマリ・キーは自己増分列の使用を推奨する.
プライマリ・キーはクラスタ・インデックスを確立します.プライマリ・キーは変更されるべきではありません.文字列はプライマリ・キーにすべきではありません.プライマリ・キーを指定しない場合、innodbは一意で空でないインデックスで置き換えられます.
(16)外部キーを使わない
プログラムによって制約を保証してください.
(四)sql類の原則
(17)sql文はできるだけ簡単
1本のsqlは1つのcpuでしか演算できません.大きい文は小さい文を分解して、ロック時間を減らします;大きなsqlはライブラリ全体を塞ぐことができます.
(18)単純なトランザクション
;
bad case:
(19)trig/funcの使用を避ける
トリガ、関数は使いません.クライアントプログラムの代わりに;
(20)selectを使わない*
cpu、io、メモリ、帯域幅を消費します.このプログラムは拡張性がない.
(21)ORをIN()に書き換える
or n ;
in log(n) ;
in 200 ;
select id from t where phone=’159′ or phone=’136′;
=>
select id from t where phone in (’159′, ’136′);
(22)OR UNIONに書き換える
mysql
select id from t where phone = ’159′ or name = ‘john’;
=>
select id from t where phone=’159′
union
select id from t where name=’jonh’
(23)マイナス方向を避ける
(24)countを慎む(*)
(25)limitの効率的なページング
limit ,
select id from t limit 10000, 10;
=>
select id from t where id > 10000 limit 10;
(26)unionの代わりにunion allを使用する
unionはオーバーヘッドがある
(27)接続joinを少なくする
(28)groupbyの使用
グループ化;自動ソート;
(29)同型比較を使用してください
(30)load dataを用いてデータを導く
load dataはinsertより約20倍速い.
(31)分散一括更新
(32)新エネルギー分析ツール
show profile;
mysqlsla;
mysqldumpslow;
explain;
show slow log;
show processlist;
show query_response_time(percona)
テキストhttp://www.html5wd.com/archives/1090.html