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