chapter03_架构优化和索引_1_选择优化的数据类型

• 基本原则

  (1) 满足需求的前提下，越小越好

  能用TINYINT就不用INT

  (2) 越简单越好

  能用整数就不用字符串（例如IP地址）；

  能有内置类型就不用字符串（例如日期类型）

  (3) 尽量避免NULL

  当可为NULL的列作为索引时，每条记录需要额外的字节 -->考虑有0等特殊值代替NULL

• 整数

  (1) TINYINT:8

  SMALLINT:16

  MEDIUMINT:24

  INT:32

  BIGINT:64

  它们都可以添加UNSIGNED修饰，此时存储位数不变，只不过数据范围变了

  (2) 整数__运算时__，通常使用BIGINT(64 bit)进行运算

  (3) 规定INT(11)对于内部存储毫无意义，只是提示用来显示的位数

  (4) 什么类型的变量，决定了MySQL会把数据保存在__内存还是磁盘__上，进而影响了速度

• 实数

  (1) DECIMAL：用于保存__精确__的小数（支持精确的数学运算），存储位数不定长（但是有最长位数65 bit限制）

  DOUBLE: 64

  FLOAT: 32

  (2) DECIMAL不仅可以用于表示小数，它还提供了比BIGINT__更大范围__的整数

  (3) 实数运算时要么使用DECIMAL，要么使用DOUBLE

  (4) 由于需要额外的空间和计算开销，所以__只有需要对小数精确计算时__再用DECIMAL

• 字符串

  (1) VARCHAR

  1° VARCHAR的存储结构是：字符串本身需要的空间 + 1或2 byte的字符串长度

  --> 更节省空间 --> 对性能有帮助 
  

  2° 更新时，如果VARCHAR变量的长度改变造成不适合放在原始位置了，则

  InNoDB引擎：分页

  MyIsam引擎：拆分行

  因此更新时可能会有性能问题

  3° 当最大长度远大于平均长度，且更新的情况较少时(插入记录后很少更新数据)，就非常适合用VARCHAR

  (2) CHAR

  1° 固定长度存储

  2° 末尾的空格在存储的时候就会被去掉

  3° 适合用CHAR而不是VARCHAR的情况

  a. 存储长度近似相同的字符串(例如密码)

  b. 经常改变的值

  c. 极短的字符串(例如单字符)，因为VARCHAR需要多一个保存字符串长度的byte

• BLOB和TEXT

  (1) BLOB保存的是二进制数据，没有字符集和排序规则；TEXT保存的有字符集合排序规则

  (2) MySQL对BLOB和TEXT的排列方式不会按照完整的长度排序，而是规定的按前几个字节排序

  (3) MySQL不能索引这些数据类型的完整长度，也不能为排序使用索引