高性能mysql笔记---schema与数据结构[-3-]

1.选择优化的数据类型

a.数据大小更小更好

b.简单就好

c.尽量避免NULL，Null对于mysql更难优化，索引、值比较都更加复杂了。

1>整数类型

TINYINT	8
SMALLINT	16
MEDIUMINT	24
INT	32
BIGINT	64

mysql可以为整数类型指定宽度，例如INT(11)，但是对于大多数应用是没有意义的，不会限制值的合法范围，只是规定了MYSQL的一些交互工具用来显示的字符个数，对于存储和计算来说，INT(1)和INT(20)是相同的。
2>实数类型

DECIMAL用于存储精确的小数，计算的时候，DECIMAL会转换成DOUBLE，因为需要额外的空间和计算开销，所以尽量使用BIGINT来代替。

3>字符串类型

a.VARCHAR类型用于存储可变长字符串，它比定长类型更节省空间，越短的字符串使用越少的空间。但是有一种情况例外，如果mysql表使用ROW_FORMAT=FIXED创建的话，每一行都会使用定长存储，这会浪费空间。需要使用1个或者2个额外的字节来记录字符串的长度。假如采用latinl字符集，一个VARCHAR(10)的列需要11个字节的存储空间，VARCHAR(1000)的列需要12个字节的存储空间。

在5.0或者更高的版本，mysql在存储和检索时会保留末尾空格，但是在4.1或者更老的版本，mysql会剔除末尾空格。

InnoDB可以把过长的VARCHAR存储为BLOB。

b.CHAR

定长，适合存储很短的字符串，或者所有值都接近同一个长度。当存储时，MYsql会删除所有末尾的空格。CHAR值会根据需要采用空格进行填充方便比较。

CHAR(1)需要一个字节，VARCHAR(1)则需要俩个字节。

c.BINARY和VARBINARY， 与字符串非常相似，BINARY采用的是\0(零字节)而不是空格。在检索时，不会去掉填充值。

#慷慨是不明智，VARCHAR(5)和VARCHAR(200)存储'hello'的空间开销是一样的，但是更长的列会消耗更多的内存，无论是使用内存临时表还是使用磁盘临时表，来进行排序时都是非常糟糕的。

d.BLOB和TEXT

都是存储很大的数据而设计的字符串数据类型的，分别采用二进制和字符方式存储。

TINYTEXT,SMALLTEXT,TEXT,MEDIUMTEXT,LONGTEXT

TINYBLOBSMALLBLOB,BLOB,MEDIUMBLOB,LONGBLOB

4>时间类型

a.DATETIME和TIMESTAMP

DATETIME使用8个字节的存储空间，装到格式为YYYYMMDDHHMMSS整数中，使用8个字节的存储空间。

TIMESTAMP使用4个字节的存储空间，保存了从1970-01-01午夜（格林尼治标准时间）以来的秒数。

依赖于时区，例如存储值为0的TIMESTAMP在美国东部时区显示为“1967-12-31 19:00:00”，与格林尼治差5个小时。

注意：自动生成的schema通常意味着没有设计更有的数据类型来存储。

2.范式与反范式

范式：

1>优点：更新操作比反范式快，表通常更小，执行操作快。

2>缺点：查询需要关联。

反范式：

1>优点：所有数据在同一张表，可以使用更好的索引策略。当数据比内存大时这可能比关联要快得多，因为避免了随机I/O.

2>缺点：修改数据时，可能发生数据不一致性。（例如同一个部门的leader可能有俩个，一个人有俩个块手表就永远不知道时间）
3.缓存表和汇总表

1>计数器表

每条记录都会有行级锁，要获得更高的并发性，可以创建若干行数据，每次update选择一个随机的槽。