mysql修行练级之字符集，数据类型与存储引擎选择

如何选择合适的存储引擎

几个常用存储引擎的特点

下面我们重点介绍几种常用的存储引擎并对比各个存储引擎之间的区别和推荐使用方式。

特点 Myisam BDB Memory InnoDB Archive

存储限制 没有 没有 有 64TB 没有

事务安全 支持 支持  

锁机制 表锁 页锁 表锁 行锁 行锁

B树索引 支持 支持 支持 支持  

哈希索引 支持 支持  

全文索引 支持  

集群索引 支持  

数据缓存 支持 支持  

索引缓存 支持 支持 支持  

数据可压缩 支持 支持

空间使用 低 低 N/A 高 非常低

内存使用 低 低 中等 高 低

批量插入的速度 高 高 高 低 非常高

支持外键 支持  

最常使用的2种存储引擎：

Myisam是Mysql的默认存储引擎。当create创建新表时，未指定新表的存储引擎时，默认使用Myisam。每个MyISAM在磁盘上存储成三个文件。文件名都和表名相同，扩展名分别是.frm（存储表定义）、.MYD (MYData，存储数据)、.MYI (MYIndex，存储索引)。数据文件和索引文件可以放置在不同的目录，平均分布io，获得更快的速度。   

InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比Myisam的存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。

选择标准：根据应用特点选择合适的存储引擎，对于复杂的应用系统可以根据实际情况选择多种存储引擎进行组合。

下面是常用存储引擎的适用环境：

MyISAM：默认的MySQL插件式存储引擎，它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一

InnoDB：用于事务处理应用程序，具有众多特性，包括ACID事务支持。

Memory：将所有数据保存在RAM中，在需要快速查找引用和其他类似数据的环境下，可提供极快的访问。

Merge：允许MySQL DBA或开发人员将一系列等同的MyISAM表以逻辑方式组合在一起，并作为1个对象引用它们。对于诸如数据仓储等VLDB环境十分适合。

选择数据类型的基本原则

前提：使用适合存储引擎。

选择原则：根据选定的存储引擎，确定如何选择合适的数据类型。

下面的选择方法按存储引擎分类：

MyISAM 数据存储引擎和数据列：MyISAM数据表，最好使用固定长度(CHAR)的数据列代替可变长度(VARCHAR)的数据列。

MEMORY存储引擎和数据列：MEMORY数据表目前都使用固定长度的数据行存储，因此无论使用CHAR或VARCHAR列都没有关系。两者都是作为CHAR类型处理的。

InnoDB 存储引擎和数据列：建议使用 VARCHAR类型。

对于InnoDB数据表，内部的行存储格式没有区分固定长度和可变长度列（所有数据行都使用指向数据列值的头指针），因此在本质上，使用固定长度的CHAR列不一定比使用可变长度VARCHAR列简单。因而，主要的性能因素是数据行使用的存储总量。由于CHAR平均占用的空间多于VARCHAR，因 此使用VARCHAR来最小化需要处理的数据行的存储总量和磁盘I/O是比较好的。

下面说一下固定长度数据列与可变长度的数据列。

char与varchar

CHAR和VARCHAR类型类似，但它们保存和检索的方式不同。它们的最大长度和是否尾部空格被保留等方面也不同。在存储或检索过程中不进行大小写转换。

下面的表显示了将各种字符串值保存到CHAR(4)和VARCHAR(4)列后的结果，说明了CHAR和VARCHAR之间的差别：

值 CHAR(4) 存储需求 VARCHAR(4) 存储需求

‘‘ ‘    ‘ 4个字节 ‘‘ 1个字节

‘ab‘ ‘ab  ‘ 4个字节 ‘ab ‘ 3个字节

‘abcd‘ ‘abcd‘ 4个字节 ‘abcd‘ 5个字节

‘abcdefgh‘ ‘abcd‘ 4个字节 ‘abcd‘ 5个字节

请注意上表中最后一行的值只适用不使用严格模式时；如果MySQL运行在严格模式，超过列长度不的值不保存，并且会出现错误。

从CHAR(4)和VARCHAR(4)列检索的值并不总是相同，因为检索时从CHAR列删除了尾部的空格。通过下面的例子说明该差别：

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));

Query OK, 0 rows affected (0.02 sec)

mysql> INSERT INTO vc VALUES (‘ab  ‘, ‘ab  ‘);

Query OK, 1 row affected (0.00 sec)

mysql> SELECT CONCAT(v, ‘+‘), CONCAT(c, ‘+‘) FROM vc;

+----------------+----------------+

| CONCAT(v, ‘+‘) | CONCAT(c, ‘+‘) |

+----------------+----------------+

| ab  +          | ab+            |

+----------------+----------------+

1 row in set (0.00 sec)

text和blob

在使用text和blob字段类型时要注意以下几点，以便更好的发挥数据库的性能。

①BLOB和TEXT值也会引起自己的一些问题，特别是执行了大量的删除或更新操作的时候。删除这种值会在数据表中留下很大的"空洞"，以后填入这些"空洞"的记录可能长度不同,为了提高性能,建议定期使用 OPTIMIZE TABLE 功能对这类表进行碎片整理.

②使用合成的（synthetic）索引。合成的索引列在某些时候是有用的。一种办法是根据其它的列的内容建立一个散列值，并把这个值存储在单独的数据列中。接下来你就可以通过检索散列值找到数据行了。但是，我们要注意这种技术只能用于精确匹配的查询（散列值对于类似<或>=等范围搜索操作符 是没有用处的）。我们可以使用MD5()函数生成散列值，也可以使用SHA1()或CRC32()，或者使用自己的应用程序逻辑来计算散列值。请记住数值型散列值可以很高效率地存储。同样，如果散列算法生成的字符串带有尾部空格，就不要把它们存储在CHAR或VARCHAR列中，它们会受到尾部空格去除的影响。

合成的散列索引对于那些BLOB或TEXT数据列特别有用。用散列标识符值查找的速度比搜索BLOB列本身的速度快很多。

③在不必要的时候避免检索大型的BLOB或TEXT值。例如，SELECT *查询就不是很好的想法，除非你能够确定作为约束条件的WHERE子句只会找到所需要的数据行。否则，你可能毫无目的地在网络上传输大量的值。这也是 BLOB或TEXT标识符信息存储在合成的索引列中对我们有所帮助的例子。你可以搜索索引列，决定那些需要的数据行，然后从合格的数据行中检索BLOB或 TEXT值。

④把BLOB或TEXT列分离到单独的表中。在某些环境中，如果把这些数据列移动到第二张数据表中，可以让你把原数据表中 的数据列转换为固定长度的数据行格式，那么它就是有意义的。这会减少主表中的碎片，使你得到固定长度数据行的性能优势。它还使你在主数据表上运行 SELECT *查询的时候不会通过网络传输大量的BLOB或TEXT值。

浮点数与定点数

为了能够引起大家的重视，在介绍浮点数与定点数以前先让大家看一个例子：

mysql> CREATE TABLE test (c1 float(10,2),c2 decimal(10,2));

Query OK, 0 rows affected (0.29 sec)

mysql> insert into test values(131072.32,131072.32);

Query OK, 1 row affected (0.07 sec)

mysql> select * from test;

+-----------+-----------+

| c1        | c2        |

+-----------+-----------+

| 131072.31 | 131072.32 |

+-----------+-----------+

1 row in set (0.00 sec)

从上面的例子中我们看到c1列的值由131072.32变成了131072.31，这就是浮点数的不精确性造成的。

在mysql中float、double（或real）是浮点数，decimal（或numberic）是定点数。

浮点数相对于定点数的优点是在长度一定的情况下，浮点数能够表示更大的数据范围；它的缺点是会引起精度问题。在今后关于浮点数和定点数的应用中，大家要记住以下几点：

浮点数存在误差问题；

对货币等对精度敏感的数据，应该用定点数表示或存储；

编程中，如果用到浮点数，要特别注意误差问题，并尽量避免做浮点数比较；

要注意浮点数中一些特殊值的处理。

字符集概述

字符集是一套符号和编码的规则，不论是在oracle数据库还是在mysql数据库，都存在字符集的选择问题，而且如果在数据库创建阶段没有正确选择字符集，那么可能在后期需要更换字符集，而字符集的更换是代价比较高的操作，也存在一定的风险，所以，我们推荐在应用开始阶段，就按照需求正确的选择合适的字符集，避免后期不必要的调整。

Mysql支持的字符集简介

mysql服务器可以支持多种字符集（可以用show character set命令查看所有mysql支持的字符集），在同一台服务器、同一个数据库、甚至同一个表的不同字段都可以指定使用不同的字符集，相比oracle等其他数据库管理系统，在同一个数据库只能使用相同的字符集，mysql明显存在更大的灵活性。

mysql的字符集包括字符集（CHARACTER）和校对规则（COLLATION）两个概念。字符集是用来定义mysql存储字符串的方式，校对规则则是定义了比较字符串的方式。字符集和校对规则是一对多的关系, MySQL支持30多种字符集的70多种校对规则。

每个字符集至少对应一个校对规则。可以用SHOW COLLATION LIKE ‘utf8%‘;命令查看相关字符集的校对规则。

Unicode简述

Unicode是一种编码规范。我们在这里简述一下Unicode编码产生的历史。

先从ASCII码说起，ASCII码也是一种编码规范，只不过ASCII码只能最多表示256个字符，是针对英文产生的，而面对中文、阿拉伯文之类的复杂文字，256个字符显然是不够用的。于是各个国家或组织都相继制定了符合自己语言文字的标准，比如gb2312、big5等等。但是这种各自制定自己的标准的做法显然是有很多弊端的，于是Unicode编码规范应运而生。

Unicode也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

Unicode有两套标准UCS-2和UCS-4，前者用2个字节表示一个字符，后者用4个字节表示一个字符。以目前常用的UCS-2为例，它可以表示的字符数为2^16=65535，基本上可以容纳所有的欧美字符和绝大多数亚洲字符。

怎样选择合适的字符集

我们建议在能够完全满足应用的前提下，尽量使用小的字符集。因为更小的字符集意味着能够节省空间、减少网络传输字节数，同时由于存储空间的较小间接的提高了系统的性能。

有很多字符集可以保存汉字，比如utf8、gb2312、gbk、latin1等等，但是常用的是gb2312和gbk。因为gb2312字库比gbk字库小，有些偏僻字（例如：洺）不能保存，因此在选择字符集的时候一定要权衡这些偏僻字在应用出现的几率以及造成的影响，不能做出肯定答复的话最好选用gbk。

Mysql字符集的设置

mysql的字符集和校对规则有4个级别的默认设置：服务器级、数据库级、表级和字段级。分别在不同的地方设置，作用也不相同。

服务器字符集和校对，在mysql服务启动的时候确定。可以在my.cnf中设置：

    [mysqld]

    default-character-set=utf8

或者在启动选项中指定：

    mysqld --default-character-set=utf8

或者在编译的时候指定：

    ./configure --with-charset=utf8

如果没有特别的指定服务器字符集，默认使用latin1作为服务器字符集。上面三种设置的方式都只指定了字符集，没有指定校对规则，这样是使用该字符集默认的校对规则，如果要使用该字符集的非默认校对规则，则需要在指定字符集的同时指定校对规则。

可以用show variables like ‘character_set_server‘;命令查询当前服务器的字符集和校对规则。

本文出自 “运维者说：从菜鸟到老鸟” 博客，请务必保留此出处http://liuqunying.blog.51cto.com/3984207/1560964