高性能mysql笔记---schema与数据结构[-3-]
Posted 空方块
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高性能mysql笔记---schema与数据结构[-3-]相关的知识,希望对你有一定的参考价值。
1.选择优化的数据类型
a.数据大小更小更好
b.简单就好
c.尽量避免NULL,Null对于mysql更难优化,索引、值比较都更加复杂了。
1>整数类型
TINYINT | 8 |
SMALLINT | 16 |
MEDIUMINT | 24 |
INT | 32 |
BIGINT | 64 |
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选择一个随机的槽。
以上是关于高性能mysql笔记---schema与数据结构[-3-]的主要内容,如果未能解决你的问题,请参考以下文章