序文：
優れたデザインとロジックは高いパフォーマンスの基本的な保証ですスキーマとデータ型の最適化を使用したmysqlのいくつかの提案と原則を見てみましょう。
1.最適化されたデータ型を選択するための一般的なルール
- 通常
、小さい方が優れています。一般的に、小さいデータタイプはビジネスシナリオのニーズを満たすことができます。小さいデータタイプは、CPUオーバーヘッド、メモリおよびストレージスペースの使用量が少ないことを意味し、効率を向上できます。 - 単純なデータ型
整数のデータ型は、文字や浮動小数点のデータ型よりも処理が簡単で簡単です。
NULL値を格納する必要がない場合は、NULLの使用を避けてください。通常、列をNOT NULLとして指定する必要があります。NULLの可能性がある列は、より多くのスペースを使用し、使用時に追加のリソースを消費します。
また、列がNULLの場合、インデックスの作成には追加のオーバーヘッドも必要です。上記の一意のインデックスはNULLを1つとして数えず、複数のNULLデータを正常に保存できるため、データの一意性にも影響します。
2.データ型選択の最適化
2.1整数型：
1.mysql的证书类型：TINYINT(8)，SMALLINT(16)，MEDIUMINT(24)，INT(32)，BIGINT(64)后面小括号中的数字是占用的存储空间。
2.unsigned不会影响mysql的储存空间，有符号的INTYINT储存范围是-128~127，无符号的TINY能储存0~255。总共包含的数值尺寸（总共256个数字），
但是数据的范围是有变化的。可以根据具体的场景来设置最合适的范围。
3.对于整数类型而言int(1)和int(20)没有区别，计算和储存都不会有影响，只是可能会影响一些mysql的客户端工具显示字符的个数。
注：这里稍微扯一点题外话，TINYINT设置为1和大于1的数字，会影响mybatis generator逆向生成java bean和xml的时候的数据格式。
TINYINT(1)会对应Boolean类型，TINYINT(n) n>1的话显示的是Byte类型。
2.2実数型
1.mysql内部使用DOUBLE作为浮点型运算的类型，DECIMAL只是一种储存格式，在计算的时候也会转换为DOUBLE。DOUBLE和DECIMAL，mysql5.0之后对DECIMAL进行了优化，可以支持高精度的计算，但是会比较消耗性能，DOUBLE计算更快但是可能会丢失经度。
2.因为DECIMAL使用了更多的空间和计算的消耗，所以只在对小数进行精确计算的时候才使用DECIMAL，正常储存浮点数不用计算的话，DOUBLE就够了。
3.还有一种方式就是使用整型来储存浮点数，将要储存的浮点数乘以小数的位数变成整型在储存起来。这样可以避免浮点储存计算不精确和DECIMAL计算消耗大的问题。
2.3文字列型
1.varchar可能是我们用的最多的类型了，它是可变长度的，varchar(1000)如果只用到了10个字节，实际上储存空间上就用了11个字节，一个字节用来记录字符串的长度，当字符串超过255个字节的时候会使用两个字节。另一个char是不可变的字符串，
如果是char(10),实际上使用了11个字节，1个用来记录字符串的长度。
2.不过因为varchar是可变长的，如果字段更新操作时变长了，会需要额外的开销，所以varchar最合适的场景是字符串最大长度比平均长度大很多，而且更新不频繁。
3.char在储存字符串的时候，会把末尾的空格给去掉，如果是'abc ',实际使用和储存时都是'abc'。
4.如果设置了ROW_FORMAT=FIXED,即使是varchar也是会使用定长字节来储存的
5.之前从来没有用过mysql的枚举类型数据，看了书才知道还有枚举类型，平时基本上都是用的java建的枚举类使用比较方便。mysql的枚举类底层储存的也是整数，估计是做了
hash的操作给映射成整数了，不过如果mysql的枚举要联表查询的话性能消耗比较高，可能这也是不太常用的原因之一吧。
2 .4 日付タイプの公式ドキュメントへのリンク。
1.datetime格式范围大概是从1001年-9999年（如果超过了9999年会怎么样呢？会报错的），timestamp这个是从1970年1月1日开始的，而且范围贼小到2038-01-19 03:14:07，
因为我们是东八区所以可以在加八个小时。
所以最好不要用时间戳，这还有18年可能你写的程序就会因为时间格式超过了范围而报错。
2.timestamp在插入时没有值会默认写入一个当前时间戳的值，切不能为null。
3.mysql数据库支持的时间粒度是秒，如果要储存更小粒度的时间，可以使用mysql的分支MariaDB，或者使用BIGINT，DOUBLE处理后来储存时间戳。
2.5ビットデータ型
1.set和bit都可以用来存储true/false的值，不是很常用。例如保存某个数据的状态可以用bit，不过一般用tinyint会更常见一些。
2.6識別子を選択
1.为标识列选择合适的数据类型很重要。整数型 > 字符串 > set/enum
2.7特殊型データ
1.这里谈到一个例子IPV4，人们经常用VARCHAR(15)来储存，实际上去除掉符号点，是一个无符号的整数。用整数来储存更加合适，
mysql提供了INET_ATON()和INET_NOTA()来转换。
3.スキーマ設計の落とし穴
3.1列が多すぎる
mysql储存引擎和服务层之前拷贝数据的时候，会将缓存的内容解码为各个对应的列。但是
一张表如果列宽很长，几千个列这样，实际使用的时候有时候只用到了小部分数据，这样解码效率就很低，查询也会变得很慢。
3.2関連付けが多すぎる
mysql限制了每个关联最多61张表(当然我觉得是够用了，要是一个关联能关联61张表，那就设计上很有问题了)。经验法则，一个查询要想又快又能保持并发性良好，关联最好不超过12张表。
3.3全能の列挙
一个枚举如果包含了太多的数据，当成了字典来使用的话，当要进行修改的使用因为是阻塞操作，会导致使用这个枚举的业务都停下来。
3.4変装した列挙
当使用set来代替enum来使用的时候，比如记录是true/false，如果有很多个这样的值，用set来储存容易导致混乱，最好用enum。
3.5 NULLの代替
前面说了尽量不使用NULL，我们可以使用-1，0，空字符串来代替。但是不要每个地方都这样用，有时候使用替代方案可能会导致编写代码和业务场景变得更加复杂，比如其他部门都用NULL，我们使用-1，这样很多调用部分都得做出相应的修改。
在具体的场景可以具体分析，并不是说NULL就不能用了。