web工程设计

时间:2022-08-17 04:23:21

Schema与数据类型优化  

  良好的逻辑设计和物理设计是高性能的基石,应该根据系统将要执行的查询语句来设计schema,这往往需要权衡各种因素。

  一:选择优化的数据类型

    ①:更小的通常更好

      整数类型:MySQL支持SQL标准整数类型 INTEGER(或INT)和 SMALLINT。作为一个可扩展标准,MySQL也支持整数类型 TINYINTMEDIUMINT和 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

      该DECIMALNUMERIC 类型的存储精确的数值数据。在保持精确精度很重要时使用这些类型,例如使用货币数据。在MySQL中,NUMERIC实现为DECIMAL,所以下面的注释DECIMAL同样适用于 NUMERIC

      salary DECIMAL(5,2)

     浮点类型(近似值) - FLOAT,DOUBLE

      FLOATDOUBLE类型代表近似数字数据值。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类型 相似,但它们被存储和检索的方式不同。它们的最大长度和尾随空间是否保留也不同。

      下表说明之间的差别 CHARVARCHAR通过显示存储各种字符串值到的结果 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的常数替代,反而增加了代码的复杂度