mysql空间数据模型_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

-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的常数替代，反而增加了代码的复杂度