mysql data type
Page content
データ型について勉強やでしかし
VARCHAR って
MySQL の VARCHAR(n) の n ってバイト数だと思っていたら、文字数だったはなし。
公式ドキュメントの探し方が悪かったようで、よくわかっていなかった。 11.7 データ型のストレージ要件 の 文字列型のストレージ要件 というセクションや。
カラム値が 0 から 255 バイトを必要とする場合は、L + 1 バイト、値が 255 バイト以上を必要とする可能性のある場合は、L + 2 バイト ※L は指定された文字列値の実際の長さをバイト数で表します。
ちなみに PostgreSQL でも同じく文字数で会話する。
証拠
- 戒めの実験ログ
mysql> desc users; +-------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+----------------+ | id | int | NO | PRI | NULL | auto_increment | | name | varchar(200) | YES | | NULL | | | age | int | YES | | NULL | | | email | varchar(100) | YES | | NULL | | +-------+--------------+------+-----+---------+----------------+ 4 rows in set (0.02 sec) mysql> insert into users values (6, '200lettersあああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ あああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ', 20, ''); Query OK, 1 row affected (0.01 sec) mysql> select * from users where id=6; +----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+-------+ | id | name | age | email | +----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+-------+ | 6 | 200lettersああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ | 20 | | +----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------+-------+ 1 row in set (0.00 sec)
MySQL 可変長フィールドを全てvarchar(255)にしたら何か問題があるか
- varchar なので、 prefix が増えなければ消費ディスク容量は変わらない。 varchar(10) でも varchar(255) でも10文字入れるなら同じ。
- １つのテーブルに作成できるフィールド（カラム）数が少なくなる。 -> 自分のケースではハマるほどフィールド数多くない (MySQL 5.6 リファレンスマニュアル テーブルカラム数と行サイズの制限 )
- バッファサイズが大きくなってキャッシュヒット率が下がる。 -> 自分たちの扱うデータサイズではそんなに肥大化しないし、そんなにキャッシュヒット率を気にしない（まずは）
- むしろ変に狭めることで後で不自由するのを恐れている
他、パフォーマンスチューニング系
- データサイズの最適化 性質はとてもわかり易い
ディスク上の領域を最小にするようにテーブルを設計します。これにより、ディスクに対して読み取りおよび書き込みされるデータの量が減ることで、大幅な改善が見られます。内容がクエリー実行中にアクティブに処理される間、テーブルが小さいほど、通常必要なメインメモリーの量は少なくなります。テーブルデータの領域の削減により、インデックスも小さくなり、高速に処理できます。