MySQLのカラム型の使い分けについてなど
db設計する時にカラムに与える型の選び方とその理由について教わった。
MySQL公式見たら他にもカラム型あったけど、今回は良く見るカラム型について書く
signとunsign
c#とかだとintとuintという表記でこの2つは分かれている
- signはマイナスも含んだ表現(intだと-21億くらい~21億くらい)よく使う
- unsignはプラスの含む表現(intだと0~42億くらい)
型の種類(unsigned)
マイナスの値も入れたい場合もあるらしいが、今回は意識しないのでunsignedのお話です
tinyint : 1byte = 8bit(0~255)
- 10個程度のフラグ管理などに使う(mysqlにbool型が無いし)
smallint : 2byte = 16bit(0~65535)
- マスターデータなど、ユーザーによって増えたりしない値の保存に使うと良いかも
int : 4byte = 32bit(0~地球人口の約半分の42億くらい)
- player_idとかならこれでいいかも(ただFBやTwitterはbigintかな?)
bigint : 8byte = 64bit(0~17000景くらい?)
- (player情報x何か)の情報を格納するテーブルのauto_incrementなidは確実にplayer_idの倍以上の数になるのでbigintにするべきらしい
bigintについて詳しく
- 例えばカードゲームの場合、『player_idと所持カードのセットを格納するtable』があるとすると、初期のデータ量でも(playerの数x20枚)くらいになる
- もしも100万ユーザーの20万DAUのカードゲームなら、毎日１枚のカードを各ユーザが取得したとすると、毎日20万レコード増えて、AUTO_INCREMENTされるidの桁数がどんどん増えて行って億単位にすぐに届いてしまう
なんでそんなに用心するの？後で型を変えれば良いじゃん
- リリース後に本番用のデータが入った状態でDBの設計を変えるのはデータが既に入っている量だけ、データの入れ替えにかなりの時間がかかるから開発時に設計を固めておく必要が有る
- 2万レコードくらいならALTER文を打ってもいけるらしけど、正確なギリギリラインとか無さそうだし、やっぱり危ないからリリース後のサービスで変えるのは良くない。
--追記@ichirin2501さんからの指摘--
しかし、読み取り専用のマスターデータなどはレコード数が限られているし、共有ロックしかかかってないので、低いリスクでALTER_TABLEができる
まとめ
MySQL、色々な機能があるし奥が深い
