高性能MySQL-Schema与数据类型优化

良好的逻辑设计和物理设计是高性能的基石,应该根据系统将要执行的查询语句设计schema,但记住这往往需要权衡各种因素。例如,反范式的设计可以加快某些类型的查询,但同时也可能使一些查询变慢。比如添加计数表和汇总表是很好的优化查询的方式,但这些表的维护成本很高。

==================================================================

1.1 选择优化的数据类型

MySQL支持的数据类型非常多,选择正确的数据类型对于获得高性能至关重要。以下罗列选择的原则:

1)更小的通常更好。一般情况下,应该使用可以正确存储数据的最小数据类型。例如,只需存储0-200整数,那么相比 int 来说 tinyint unsigned 更好。更小的数据类型通常更快,占用更少的磁盘空间、内存、CPU缓存,并且处理时需要的CPU周期也更少。但是需要确保没有低估存储值的范围,因为未来要在schema中多个地方增加数据类型的范围是一个耗时和痛苦的操作。

2)简单就好。简单数据类型的操作通常需要更少的CPU周期,例如整数型比字符型操作代价更低,因为字符集和校对规则(排序规则)使字符比较比整型更复杂。另外的例子,使用MySQL内建的date、time、datetime来存储日期和时间,而不是使用字符串,还有使用整型存储IP地址,也不要使用字符型。

3)尽量避免使用NULL。创建时尽量使用NOT NULL,因为NULL值会使该列的索引、索引统计、值的比较都更复杂,而且会使用更多存储空间。特别是一定要在列上建立索引时,一定是NOT NULL。

如何选择数据类型,第一步,需要确定合适的大类型,第二步,在大类型中选择小类型。

==================================================================

1.1.1 整数类型

整数类型主要包括 TINYINT(8位,-128~127)、SMALLINT(16位)、MEDIUMINT(24位)、INT(32位)、BIGINT(64位),他们的存储的值的范围为:-2^(N-1)至2^(N-1)-1,以上都可以使用UNSIGNED,取值范围为0~2^N-1。

注意:这个选择仅影响数据在内存和硬盘中的存储,不会对整数的计算产生影响,因为MySQL计算时均转换为64位 BIGINT 进行。

注意:MySQL可以为整数类型指定宽度,这只是显示的宽度,如INT(5),显示5个字符宽度,如123,会显示00123,因此不会影响取值,也就是说比如INT(5)和INT(11)在存储和计算时是相同的,没有区别。

==================================================================

1.1.2 实数类型

实数类型包括 FLOAT(不精确类型)、DOUBLE(不精确类型)、DECIMAL(精确类型),支持指定精度,如DECIMAL(18,9),表示小数点两边各9个数字。

注意:由于指定精度,会使得MySQL悄悄地选择不同的数据类型,或者在存储时对值自动取舍,因此建议只指定数据类型,不指定精度,精度根据需要在前端取舍。

注意:如果真需要DECIMAL,建议使用乘以10^N取得整数后使用INT(或BIGINT)数据类型,前端显示时根据需要除以10^N获得正确的结果,或者将指数N对应以INT存入数据库,这样使MySQL得到优化。

==================================================================

4.1.3 字符串类型

MySQL有多种字符串类型,每种可以定义不同的字符集、排序规则(校对规则),这些东西会很大程度上影响性能。

VARCHAR和CHAR是两种基本的类型,不幸的是,很难解释清楚两种类型是怎么存储在磁盘和内存中的,因为这跟存储引擎有关。不同的存储引擎(MyISAM、InnoDB、。。。)都不同。

VARCHAR类型,用于存储可变长字符串,它比定长类型节省空间,因为它仅使用必要的空间,即,越短的字符串使用越少空间。除非使用 ROW_FORMAT=FIXED,每行定长,这样会浪费空间。另外,VARCHAR使用1~2个额外字节记录字符串的长度,如果列长度小于或等于255,使用1个字节表示(8位),如果大于255,使用2个字节。

VARCHAR类型,虽然节约了空间,但由于行是变长的,在UPDATE时可能会使行变得更长,这就导致额外的工作;如果行变长后,页内没有更多空间可以存储,这种情况下,就需要拆分片段(MyISAM)或分裂页(InnoDB)来处理。

VARCHAR类型,适用情况,列最大长度比平均长度大很多,且很少更新,因为碎片将不是问题。

CHAR类型,是定长类型,根据指定的字符串长度分配足够的空间;CHAR类型适合于存储很短的字符串,或者所有值都接近同一个长度。例如,CHAR类型非常适合于存储密码的MD5值,因为MD5是一个定长的值。另一方面,CHAR类型也适合存储经常变更的数据,因为定长的CHAR不容易产生碎片。对于非常短的列,CHAR比VARCHAR在存储空间上也更有效率。如,用CHAR(1)存储只有Y和N的值,如果用单字节字符集只需要一个字节,但VARCHAR(1)在单字节情况下则需要两个字节,因为还有一个额外字节用于记录长度。

注意:字符串长度定义不是字节数,而是字符数;多字节字符集会需要更多的空间存储单个字符。

注意:字符集(Charset):是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称,包括各国家文字、标点符号、图形符号、数字等。,常见字符集名称:ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等;

注意:字符编码(Character Encoding):是一套法则,使用该法则能够对自然语言的字符的一个集合(如字母表或音节表),与其他东西的一个集合(如号码或电脉冲)进行配对。即在符号集合与数字系统之间建立对应关系,它是信息处理的一项基本技术。通常人们用符号集合(一般情况下就是文字)来表达信息。而以计算机为基础的信息处理系统则是利用元件(硬件)不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字,因此字符编码就是将符号转换为计算机可以接受的数字系统的数,称为数字代码。UTF8是编码方法;

注意:慷慨是不明智的,比如,使用VARCHAR(5)或VARCHAR(100)存储“hello”,空间开销一样,因为VARCHAR类型是可变长的,但因为MySQL通常会分配固定大小的内存块来存储内部值(意思是定义的长100>10,分配的内存块就大?),尤其是使用内存临时表进行排序或操作时会特别糟糕。在利用磁盘临时表进行排序时也同样糟糕。

BLOB和TEXT类型,BLOB以二进制存储(1、0数据流,搞硬件编程的比较熟悉),TEXT以字符形式存储,都是用来存储很大数据的类型,注意,他们也是字符串类型,只是存储形式不同。

BLOB和TEXT类型,在MySQL中会被作为对象处理,尽量避免使用。

使用枚举(ENUM)代替字符串类型,枚举会将列的长度压缩到1个或2个字节,内部都保存为整数,而在表的.frm文件中保存“数字-字符串”的映射关系查找表。

注意:避免使用数字作为枚举常量,比如 enum('1', '2', '3'),如果要枚举的真是数字,不如直接使用 TINYINT 来得直接,正确的使用情况类似于 enum('private', 'group', 'public')。

注意:枚举类型列排序时使用的是映射关系中的整数值,而不是按枚举的字符串排序。所以最好的办法是定义时就先排好序,如上面的例子,应写为 column_type enum('group', 'private', 'public') not null default 'private'。

注意:需要保证枚举列的字符串值能够确定,否则未来要扩展类别,就需要使用 ALTER TABLE。

注意:因为枚举保存为整数,因此查找时必须转换为字符串,所以枚举在执行查找时有一定开销,尤其是当前表的枚举列与其他表相同的VARCHAR列或CHAR列关联查询时,会较不使用枚举更慢。例如 关联条件为 ON A.ENUM_TYPE = B.CHAR_TYPE 时。但什么情况都需要一个平衡,使用枚举可以缩减表的大小,可能会缩减30%;当然关联后虽然慢,但可能会节省I/O。

==================================================================

1.1.4 日期和时间类型

MySQL提供许多类型保存日期和时间,最小粒度为秒。具体看看

DATETIME,存储范围1001年~9999年,封装格式为 YYYYMMDDHHMMSS,与时区无关,8个字节(64位?),使用ANSI标准定义的日期和时间表示方法显示,如“2014-01-11 22:05:33”,注意这是显示。

TIMESTAMP,时间戳,记录了一个累计秒数,从1970年1月1日午夜(格林尼治标准时间)以来。4个字节,与UNIXTIME相同。比DATETIME小很多了,最大记录从 1970年~2038年的时间。转换:FROM_UNIXTIME() 将时间戳转换为日期,UNIX_TIMESTAMP() 将日期转换为时间戳。

TIMESTAMP值与时区有关,DATETIME与时区无关,DATETIME记录的是客户端提交到数据库的当地时间字符串。如果提交数据时不指定TIMESTAMP的值,则MySQL默认提供当前时间赋值,且默认NOT NULL。

注意:以上优势,建议使用 TIMESTAMP,而不是 DATETIME,2038年以后怎么办?

==================================================================

1.1.5 位数据类型

主要有 BIT 和 SET,避免使用。

==================================================================

1.1.6 选择标识符(identifier)

标识列的数据类型,最好选择整数,且符合上面的讲的原则,能TINYINT的不INT;不要选用ENUM、SET、CHAR、VARCHAR,除非没有办法。

另外,标识列一般还与外键有关,所以记住,标识列不管在主表还是关联表中,选择的数据类型要完全一致,精确匹配,像 INT 和 UNSINGED INT 都会产生性能问题,即使没有性能问题,也可能导致难以发现的错误。因为如果不是精确匹配,MySQL需要进行隐式类型转换。

标识列不能使用字符型的原因,慢,消耗空间,对于MyISAM,字符型要使用压缩索引,导致查询慢6倍。且对于使用随机生成的字符串更要注意,如使用MD5()、SHA1()、UUID(),这些新产生的值会分布在很大的空间范围内,使得INSERT和SELECT都很慢,可能分布于不同的内存和磁盘不同位置,不会相邻,来回扫描,导致整个数据集都成为热数据。

==================================================================

1.1.7 特殊数据类型

两个例子,低于秒级的存储,IPv4的存储,人们经常错误使用 VARCHAR(15)存储IP地址,实际应使用32位 UNSIGNED INT存储,因为IP地址本身就是整数,小数点只是为了显示,因此应利用 MySQL提供的 INET_ATON()和INET_NTOA()切换。

==================================================================

1.2 MySQL Schema 设计中的陷阱

太多的列(上千个)、太多的关联(单个查询不要超过12个表)、全能的枚举、变相的枚举、非此发明的NULL(为避免不用NULL,不要乱给值如0000-00-00 00:00:00,给个0就好了)。

==================================================================

1.3 范式和反范式

一般都是先进行范式化,然后根据需要进行反范式化,取各自的有点进行折中。

范式的优点:表小、不重复、更新快;

范式的缺点:纯粹范式,查询基本都需要关联,代价昂贵。

反范式的优点:反范式恰当的话,不需要关联,快!

反范式的缺点:更新关联数据的难处。

混用:实际中是混用,部分的范式化schema、缓存表、以及其他技巧,貌似是除了有经验可以预先处理外,边开发可以边改动表的结构,将范式化的某些列,缓存到需要的主表中。

==================================================================

1.4 缓存表和汇总表(重要!!!)

缓存表:表示存储那些可以比较简单从schema其他表获取数据的表,而这样的数据每次获取的速度又比较慢,且在逻辑上有冗余的数据。缓存表需要开发者决定是实时维护还是定期重建,定期重建不仅节省资源,还可以保持表不会有很多碎片。定期重建注意使用“影子表”保持原表的可用性。

汇总表:保存的是使用 GROUP BY 语句聚合数据的表,例如,数据不是逻辑上冗余的。

物化视图:常被认为是一种功能,MySQL不提供这一功能;但实际上,物化视图指的就是缓存表,以及与之相关的一系列解决方案。使用 Justin Swanhart 开发的 Flexviews 可以实现自己的物化视图。实际使用中,只要你告诉 Flexviews 你希望从源数据库或表提前信息的 Select 语句,Flexviews自己将其转换,获取结果存储下来。开发者只需要面向 Flexviews查询就行了,再不用查询 数据库。Flexviews能做到这样,是因为 Flexviews 基于行的二进制日志更新数据,他的提前对象是数据库日志。

计数器表:创建独立计数器表记录网站访问量、用户朋友数字、文件下载次数等,是个好主意,这种表小且快。但有一个问题,如果是InnoDB会执行行级锁,如果是MyISAM会执行表级锁,会造成高并发串行执行问题。书中列出了 使用 InnoDB 会用到的技巧(随机槽、INSERT INTO...ON DUPLICATE KEY UPDATE)。

问题:以上内容,都在增加读操作速度,但会造成写操作变慢,甚至增加读操作和写操作的开发难度。

==================================================================

1.5 加快 ALTER TABLE 操作的速度

本节讲到两个重要技术,来通过速度,一是修改 .frm 文件,二是对于MyISAM表先载入数据,再创建索引。

==================================================================

1.6 总结

你可能感兴趣的:(高性能MySQL-Schema与数据类型优化)