web工程设计<mysql数据模型-数据类型的优化>

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	`-2⁶³`	`0`	`2⁶³-1`	`2⁶⁴-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的常数替代，反而增加了代码的复杂度