Schema与数据类型优化
良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要执行的查询语句来设计schema，这往往需要权衡各种因素。
一：选择优化的数据类型
①：更小的通常更好
整数类型：MySQL支持SQL标准整数类型 INTEGER（或INT）和 SMALLINT。作为一个可扩展标准，MySQL也支持整数类型 TINYINT，MEDIUMINT和 BIGINT。下表显示了每种整数类型所需的存储和范围。
表11.1 MySQL支持的整数类型所需的存储和范围
| 类型 | 存储（字节） | 最小值签名 | 最小值无符号 | 最大值签名 | 最大值无符号 |
|---|---|---|---|---|---|
TINYINT |
1 | -128 |
0 |
127 |
255 |
SMALLINT |
2 | -32768 |
0 |
32767 |
65535 |
MEDIUMINT |
3 | -8388608 |
0 |
8388607 |
16777215 |
INT |
4 | -2147483648 |
0 |
2147483647 |
4294967295 |
BIGINT |
8 | -263 |
0 |
263-1 |
264-1 |
定点类型（精确值） - DECIMAL，NUMERIC
该DECIMAL和NUMERIC 类型的存储精确的数值数据。在保持精确精度很重要时使用这些类型，例如使用货币数据。在MySQL中，NUMERIC实现为DECIMAL，所以下面的注释DECIMAL同样适用于 NUMERIC。
salary DECIMAL(5,2)
浮点类型（近似值） - FLOAT，DOUBLE
FLOAT和DOUBLE类型代表近似数字数据值。MySQL对于单精度值使用四个字节，对于双精度值使用八个字节。
比特值类型 - BIT
该BIT数据类型被用于存储比特值。一种 能够存储位值的类型。 范围从1到64。
超出范围和溢出处理
当MySQL将值存储在超出列数据类型允许范围的数值列中时，结果取决于当时生效的SQL模式：
-
-
- 如果启用了严格的SQL模式，则MySQL会根据SQL标准拒绝带有错误的超出范围的值，并且插入失败。
- 如果未启用限制模式，MySQL会将值剪辑到列数据类型范围的相应端点，并存储结果值。当超出范围的值分配给整数列时，MySQL会存储表示列数据类型范围的相应端点的值。
-
-
-
- 当为浮点或定点列分配的值超出指定（或默认）精度和比例所隐含的范围时，MySQL会存储表示该范围的相应端点的值。
-
时间类型：DATE，DATETIME和TIMESTAMP类型
DATE类型用于具有日期部分但没有时间部分的值。MySQL DATE以'YYYY-MM-DD'格式检索和显示 值 。支持的范围是 '1000-01-01'到 '9999-12-31'。
DATETIME类型用于包含日期和时间部分的值。MySQL DATETIME以'YYYY-MM-DD HH:MM:SS'格式检索和显示 值。支持的范围是 '1000-01-01 00:00:00'到'9999-12-31 23:59:59'。
TIMESTAMP数据类型被用于同时包含日期和时间部分的值。 TIMESTAMP具有'1970-01-01 00:00:01'UTC到'2038-01-19 03:14:07'UTC 的范围。
选择：TIMESTAMP只使用了DATETIME的一半的存储空间，并且会根据时区变化，具有特殊的自动更新能力，但是TIMESTAMP允许的时间范围小得多，这是它的一个障碍。
字符类型：
CHAR和VARCHAR类型 相似，但它们被存储和检索的方式不同。它们的最大长度和尾随空间是否保留也不同。
下表说明之间的差别 CHAR和VARCHAR通过显示存储各种字符串值到的结果 CHAR(4)和VARCHAR(4) 列（假设该列使用单字节字符集，例如latin1）。
更多详情：https://dev.mysql.com/doc/refman/8.0/en/binary-varbinary.html
| 值 | CHAR(4) | 需要存储 | VARCHAR(4) | 需要存储 |
|---|---|---|---|---|
'' |
' ' |
4字节 | '' |
1个字节 |
'ab' |
'ab ' |
4字节 | 'ab' |
3个字节 |
'abcd' |
'abcd' |
4字节 | 'abcd' |
5个字节 |
'abcdefgh' |
'abcd' |
4字节 | 'abcd' |
5个字节 |
②：简单就好
简单的数据类型操作需要更少的cpu周期：
整型比字符操作更低（因为字符集的校对规则决定了比整型更复杂）
③：尽量避免null
通常很多应用程序需求不要使用到null的值，但是还是很多字段属性默认为null（最好为not null）：
null的列使索引，索引统计和值得比较变得复杂起来，可能null的列会使用更多的存储空间；当可为null的列上创建索引时，每个索引需要一个额外的字节。
调优：通常避免将索引建在为null的列上，误建了，可将null更改成not null 提升性能
二：schema中的设计缺陷
讨论mysql的schema的设计问题，可以避免发生一些问题错误，并且选择mysql中实现最好的替代方案。
①：太多列
存储引擎在存储数据时，需要在存储层api和服务层之间通过缓冲格式拷贝数据
②：太多的关联
最多每个关联操作只能61张表，关联查询最好在12表内做关联（官方），实际开发中
③：全能的枚举
④：变相枚举
⑤：非必要的取代null值
在前面说过字段默认为null 对索引查询新能的影响，但是遵循这个原则不要走极端，但确实需要表示未知值时也不要害怕使用null，在特定的场景中，使用例如0，-1的常数替代，反而增加了代码的复杂度