1.Order by与Group by优化

1.1Case1

        employees表中建立了name，position和age索引，并且使用了order by age进行排序操作：

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' and position = 'dev' order by age

        最终explain的结果发现使用了idx_name_age_position索引，并且Extra中显示Using index condition，并不是Using filesort，所以执行该语句时，使用到了索引进行优化，而不是使用外部排序。但是需要注意的是，ORDER BY走索引的时候，不会体现到key_len中，只要Extra中不是Using Filesort，是Using Index就代表ORDER BY使用了索引。

        分析：利用最左前缀法则，中间字段不能断，因为查询使用到了name索引，从key_len = 74也能看出，age索引列用在排序过程中，因为Extra字段里没有using filesort，展示的时Using index。

1.2Case2

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY position;

        这个SQL语句经过EXPLAIN进行分析，发现name确实是走索引了，但是Extra是Using Filesort，所以代表ORDER BY没有走索引。

        其主要原因是：Case1中，name确定时，由于age是有序的，所以是可以走索引的，Case2中，name确定时，position是没有顺序的，所以无法走索引，只能Using Filesort走外部排序。

1.3Case3

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY position,age

        这个SQL语句经过EXPLAIN进行分析，发现name确实走索引了，但是Extra是Using Filesort，所以代表ORDER BY没有走索引。

        究其原因是因为建立联合索引树时，position在age后面，但是使用ORDER BY进行排序时，两者颠倒了。

1.4Case4

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' AND age = 18 ORDER BY position,age;

        这个SQL语句经过EXPLAIN进行分析之后，name走了索引，Extra也是Using Index condition，所以代表ORDER BY也走索引了。

        主要原因是age当前是常量，ORDER BY后面的age其实形同虚设。

1.5Case5

EXPLAIN SELECT * FROM employees WHERE name = 'CC' ORDER BY age asc, position desc;

        这个SQL语句经过EXPLAIN进行分析之后，name走了索引，但是Extra是Using Filesort，所以就代表了ORDER BY没有使用索引进行排序。

        主要的原因是因为position在索引树中是按照升序排序进行构建的，但是这里使用ORDER BY进行排序时，采用的是降序排序，所以无法使用索引。

        注意点：该案例在MySQL5.6，5.7的版本中确实是成立的，但是在MySQL8的版本中，MySQL官方引入了降序索引进行优化，desc也可以使用索引了。

1.6Case6

EXPLAIN SELECT * FROM employees WHERE name in ('LiLei', 'CC') ORDER BY age,position;

        这个SQL语句经过EXPLAIN进行分析之后，name走了索引，但是Extra是Using Filesort，即ORDER BY排序没有走索引。

        主要的原因是name进行查询出的两部分数据组合起来时，按照age和position就不是有序的了，所以ORDER BY排序并不能走索引。

1.7Case7

EXPLAIN SELECT * FROM employees WHERE name > 'a' ORDER BY name;

        这个SQL语句经过EXPLAIN进行分析之后，name没有走索引，且Extra是Using Filesort，即ORDER BY排序没有走索引，并且查看type的时候，可以发现type中显示的是ALL，即该SQL语句进行了全表扫描。

        主要的原因在于，该数据表中name > 'a'的数据量太大，MySQL在底层进行计算时认为使用索引进行排序是比较麻烦的，所以决定使用全表扫描。

        可以使用覆盖索引进行优化：

EXPLAIN SELECT name,age,position FROM employees WHERE name > 'a' ORDER BY name;

1.8优化总结

1.MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序（因为索引构建的索引树本身就是有序的）。index效率很高，filesort效率低。

2.ORDER BY满足两种情况会使用Using index。

1）ORDER BY语句使用索引最左前列。

2）使用WHERE子句与ORDER BY子句条件列组合满足索引最左前缀法则。

3.尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。

4.如果ORDER BY的条件不在索引列上，就会产生Using filesort。

5.能用覆盖索引尽量使用覆盖索引。

6.GROUP BY与ORDER BY很类似，其是指时先排序分组，遵照索引创建顺序的最左前缀法则。对于GROUP BY的优化如果不需要排序的可以加上ORDER BY NULL禁止排序。注意，WHERE优先于HAVING，能写在WHERE中的限定条件就不要去HAVING中进行限定了。

1.9Using filesort文件排序原理详解

        Using filesort是MySQL中重点的概念，主要在ORDER BY排序中进行体现。

1.9.1filesort文件排序方式

        单路排序：是一次性取出满足条件行的所有字段，然后再sort buffer中进行排序。使用trace工具（MySQL自带的性能分析工具）可以看到sort-mode信息里显示<sort_key, additional_fields>或者<sort_key, packed_additional_fields>，单路排序其实就是将聚簇索引根据条件查询出来的数据，放到sort buffer中进行排序（比较占用内存）

        双路排序（又被称之为回表排序模式）：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行ID，然后在sort buffer中进行排序，排序完后需要再次取回其它需要的字段。使用trace工具可以看到sort_mode信息里显示<sort_key, rowid>，双路排序其实就是将二级索引根据条件查询出来数据，进行条件筛选后，再统一回表到聚簇索引中进行数据查询，将真正的数据进行返回。

1.9.2排序方式选择的依据

        MySQL通过比较系统变量max_length_for_sort_data（默认1024字节）的大小和需要查询的字节总大小来判断使用哪种排序模式。

        1.如果字段的总长度小于max_length_for_sort_data，使用单路排序模式。

        2.如果字段的总长度大于max_length_for_sort_data，使用双路排序模式，

        不建议自己去修改MySQL底层的参数。

1.9.3内存排序和磁盘排序

        MySQL在进行Using Filesort的时候，会根据数据量的规模来选择是否要调度磁盘进行排序。

        MySQL进行排序时，会先在内存中开辟一个名为sort_buffer的空间，将数据载入到sort_buffer空间中进行排序，但是如果MySQL发现数据量过大，就会在磁盘中开辟临时文件进行排序，MySQL会进行分析要在磁盘中开辟多少个临时文件用于排序。

        注意：如果全部使用sort_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增大sort_buffer（默认1M），MySQL很多参数都是做过优化的，不要轻易调整。

2.索引设计原则

2.1代码先行，索引后上

        错误的打开方式：建完表之后马上建立索引。

        正确的打开方式：主体业务功能开发完毕后，将涉及到该表的相关SQL语句都需要拿出来分析之后再建立索引。

2.2尽量建立联合索引，少建立单值索引

        在实际的项目中，一般不会建立多个单值索引，会使用多个字段建立联合索引，一方面是索引是占用空间的，建立多个单值索引会导致占用大量的存储空间，而且项目中一般查询数据时都是使用多个字段一起进行搜索查询的。

        那么为什么要建立主键单值索引呢？

        因为需要建立一个主键单值索引，保证每条数据具备一个全局唯一性。

2.3联合索引尽量覆盖条件

        比如可以设计一个或者两三个联合索引，让每一个联合索引都尽量去包含SQL语句里的WHERE、ORDER BY、GROUP BY的字段，还要确保这些联合索引的字段顺序尽量满足SQL查询的最左前缀原则。

2.4不要在小基数上建立索引

        索引基数是指这个字段在表中总共有多少个不同的值，比如一张表总共100万行记录，其中有个性别字段，其值不是男就是女，那么改字段的基数就是2。

        如果对这种小基数字段建立索引的话，还不如全表扫描了，因为你的索引树里就包含男和女两种值，根本无法进行快速的二分查找，那用索引就没有太大意义了。

        一般建立索引，尽量使用那些基数比较大的字段，那么才能发挥出B+树快速二分查找的优势来。

2.5长字符串我们可以采用前缀索引

        尽量对字段类型较小的列设计索引，比如说扫描tinyint之类的，因为字段类型较小的话，占用磁盘空间也会比较小的，此时你在搜索的时候性能也会好一点。

        当然，这个所谓的字段类型小一点的列，也不是绝对的，很多时候你就是要针对varchar(255)这种字段建立索引，哪怕多占用一些磁盘空间也是有必要的。

        对于这种varchar(255)的大字段可能会比较占用磁盘空间，可以稍微优化下，比如针对这个字段的前20个字符建立索引，即是对这个字段按里的每个值的前20个字符放在索引树中，类似于KEY index(name(20), age, position)

        此时的WHERE条件里搜索的时候，如果是根据name字段来搜索，那么此时就会先到索引树里根据name字段的前20个字符去搜索，定位到之后前20个字符的前缀匹配的部分数据之后，再回到聚簇索引提取出来完整的name字段值进行对比。

        但是假如你要是order by name，那么此时你的name因为在索引树里仅仅包含了前20个字符，所以这个排序是没法用上索引的，group by也是同理。

3.实战场景优化

3.1整体场景

3.2范围查询数据索引建立在最后

        age这种数据是经常要进行范围查询的，所以这种数据一般是直接放在最后的，索引也会建立到最后，因为如果将age索引建立到=值前面，在age符合的范围中，后面的=值数据可能不是顺序性的，就无法完全利用建立的联合索引。

3.3in优化

        为什么在不筛选sex的时候，要使用sex in ('female', 'male')呢？对于in来说，在数据量大的时候，in是会走索引的，在数据量小的时候，是不会走索引的，但是在生产环境下，数据量一般都是比较大的，所以in一般都会走索引的，出于索引设计原因，当性别不进行筛选时，采用这种方案可以使得联合索引可以被完全利用。

3.4时间字段范围查询与age冲突的解决方案

        如果时间字段也需要进行范围查询的话，这样范围查询就与age发生了冲突，无法将联合索引所有的字段都利用上。我们可以将时间字段修改为一个标志，来满足我们的需求。

4.分页场景优化

4.1分页SQL问题分析

        很多时候我们业务系统实现分析功能可能会用如下SQL实现：

SELECT * FROM employees LIMIT 10000,10;

        表示从表employees中取出10001行开始的10行记录，看似只查询了10条记录，实际这条SQL是先读取10010条记录，然后抛弃前10000条记录，然后督导后面10条想要的数据。因此要查询一张大表比较靠后的数据，执行效率是非常低的。

4.2根据自增且连续的主键排序的分页查询

        如果数据的主键确实是连续的，可以使用WHERE条件查询ID实现：

SELECT * FROM employees WHERE id > 90000 LIMIT 5;

        但是主键如果是非连续自增，就无法使用这种方式，这也是其中的局限性。

        局限性：1.主键自增且连续。2.结果是按照主键排序的。

4.3根据非主键字段排序的分页查询

        再看一个根据非主键字段排序的分页查询，SQL如下：

SELECT * FROM employees ORDER BY name LIMIT 90000, 5;

        但是这个过程中查询的数据比较多，所以name字段可能放弃使用索引。原因是：扫描整个索引并查找到没索引的行（可能要遍历多个索引树）的成本比扫描全表的成本更高，所以优化器放弃使用索引。

        知道不走索引的原因，那么怎么优化呢？

        其实关键是让排序时返回的字段尽量可能少，让覆盖索引可以覆盖到，无需回表查询，所以可以让排序和分页操作先查出主键，然后根据主键查到对应的记录，SQL改写如下：

SELECT * FROM employees e INNER JOIN (SELECT id FROM employees ORDER BY name LIMIT 90000, 5) ed ON e.id = ed.id;

        这条语句的查询过程中，内连接里面的查询是会走索引的，因为排序查询时仅仅查询了id，此时整条语句会走覆盖索引的，所以整条索引的查询效率是比较高的。

5.Join关联查询优化

5.1MySQL的表关联常见的两种算法

        MySQL表进行关联查询的时候，主要是采用了以下两种算法：

        1.Nested-Loop Join 算法。

        2.Block Nested-Loop Join 算法。

5.2嵌套循环连接Nested-Loop Join(NLJ) 算法

        一次一行循环地从第一张表（称之为驱动表）中读取行，在这行数据中取到关联字段，根据关联字段另一张表（被驱动表）里取出满足条件的行，然后取出两张表的结果合集。

        触发点：这种情况一般是两个表进行连接时，使用索引连接时会使用NLJ这种算法。

        看下面这个SQL语句：

EXPLAIN SELECT * FROM t1 INNER JOIN t2 JOIN t2 ON t1.a = t2.a;

        从执行计划中可以看到这些信息：

        先执行了t2表的查询，type是ALL说明采取的方案是全表查询，后又查询的是t1表，走了索引（因为t1表的a字段建立了索引），这种情况一共会扫描200次（驱动表中的数据量100时），所以性能还是比较高的。

        1.驱动表是t2，被驱动表是t1，驱动表是连接符号后面的表。先执行的就是驱动表（执行计划结果的id如果一样则按从上到下顺序执行SQL），优化器一般会优先选择小表作为驱动表。所以使用inner join时，排在前面的表不易i的那个是驱动表。

        2.当使用left join时，左表是驱动表，右表是被驱动表，当受用right join时，右表是驱动表，左表是被驱动表，当使用join时，MySQL会选择数据量比较小的表作为驱动表，大表作为被驱动表。

        3.使用了NLJ算法。一般Join语句中，如果执行计划Extra中未出现Using join buffer则表示使用的join算法时NLJ。

        上面SQL的大致流程如下：

        1.从表t2中读取一行数据（如果t2表有查询过滤条件的，会从过滤结果里取出一行数据）

        2.从第1步的数据，取出关联字段a，到表t1中查找。

        3.取出表t1中满足条件的行，跟t2中获取到的结果合并，作为结果返回给客户端。

        4.重复上面3步。

        整个过程会读取t2表中的所有数据（扫描100行），然后遍历这每行数据中字段a的值，根据t2表中a的值索引扫描t1表中的对应的的行（扫描100次t1表的索引，1次扫描可以认为最终只扫描t1表一行完整的数据，也就是总共t1表也扫描了100行）。因此整个过程扫描了200行。

5.3基于块的连接循环连接Block Nested Loop Join（BNL）算法

        把驱动表的数据读入到join_buffer中，然后扫描被驱动表，把被驱动表每一行取出来跟join_buffer中的数据作对比。

        触发点：这种情况一般出现在两个表进行连接时，不使用索引连接时会使用BNL这种算法。

        看下面这个SQL语句：

EXPLAIN SELECT * FROM t1 INNER JOIN t2 ON t1.b = t2.b;

        触发这种情况时，Extra中会显示使用了BNL这种算法。

        上面SQL的大致流程如下：

        1.把t2（驱动表）的所有数据放入到join_buiffer中。

        2.把表t1中的每一行取出来，跟join_buffer中的数据做对比。

        3.返回满足join条件的数据。

        整个过程中对表t1和t2都做了一次全表扫描，因此扫描的总行数为10000（表t1的数据总量）+ 100（表t2的数据总量）= 10100。并且join_buffer里的数据是无序的，因此对表t1中的每一行，都要做100次判断，所以内存中的判断次数是100 * 10000 = 100万次。

        这个例子中的表t2才100行，如果表t2是一个大表，join_buffer放不下肿莫办呢？

        join_buffer的大小是由参数join_buffer_size设定的，默认值是256kb。如果放不下表t2的所有数据，策略很简单，就是分段放。

        比如t2表中有1000行记录，join_buffer一次只能放800行数据，那么执行过程中就是先往join_buffer里放800行数据，然后从t1表中取出数据跟join_buffer中数据进行对比得到部分结果，然后清空join_buffer，再放入t2表剩余200行记录，再次从t1表中取出数据跟join_buffer中数据对比得到部分结果，然后清空join_buffer，再放入t2表剩余200行记录，再从t1表中取数据跟join_buffer中数据对比。所以就多扫了一次t1表。

5.4表连接时连接字段没有索引为什么采用BNL算法而不是NLJ算法

        如果表连接时连接字段没有索引，使用NLJ算法的话，磁盘扫描次数就会是100万次。

        很显然，使用BNL算法磁盘扫描的次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。

        因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用BNL算法。如果有索引一般选择NLJ算法，有索引的情况下NLJ算法比BNL算法性能更高。

5.5对于关联SQL的优化

        1.关联字段加索引：让MySQL做join操作时尽量选择NLJ算法。

        2.小表驱动大表：写多表连接SQL时如果明确知道那张表是小表可以用straight_join写法固定连接驱动方式，省去MySQL优化器自己判断的时间。

        straight_join解释：straight_join功能同join类似，但能让坐标的表来驱动右边的表，能改优化器对于联表查询的执行顺序。

        比如下面这条SQL语句：

SELECT * FROM t2 straight_join t1 ON t2.a = t1.a

        这条SQL语句代表着指定MySQL选择t2表作为驱动表。

        1.straight_join只适用于inner join，并不适用于left join，right join（因为left join，right join已经代表指定了表的执行顺序）

        2.尽可能让优化器去判断，因为大部分情况下MySQL优化器是比人要聪明的。使用straight_join一定要慎重，因为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

6.in和exists优化

        原则：小表驱动大表，即小的数据集驱动大的数据集。

6.1in优化

        in：当B表的数据集小于A表的数据集，in优于exists。

        看下面的SQL语句：

SELECT * FROM A WHERE id IN (SELECT id FROM b);

        这个SQL语句的执行流程：先执行IN后面的SQL语句，从b表中查询中一个id数据集，再根据查询出的id数据集去A中查询数据。

        等价于下面的代码：

for (SELECT id FROM B) {SELECT * FROM A WHERE A.id = B.id
}

        其实就是外循环B表，每次循环查询到的ID数据都需要A表去查询一次等价数据。

        此时如果B表是小表，数据量比较小，所以就会使得查询的数据比较少，优化整体性能。

6.2exists优化

        exists：当A表的数据集小于B表的数据集时，exists优于in。将主查询A的数据，放到子查询B中做条件验证，根据验证结果（true或者false）来决定主查询的数据是否保留。

        看下面这条SQL语句：

SELECT * FROM A WHERE EXISTS (SELECT 1 FROM B WHERE B.id = A.id)

        这个SQL语句的执行流程：先执行前面的SQL语句，从表A中查询出所有的数据，然后执行EXISTS后面的查询语句，再进行筛选数据。

        等价于下面的代码：

for (SELECT * FROM A) {SELECT * FROM B WHERE B.id = A.id
}

        1.EXISTS（subquery）只返回TRUE或者FALSE，因此子查询中的SELECT * 也可以SELECT 1替换，官方说明是实际执行时会忽略SELECT清单，因此没有区别。

        2.EXISTS子查询的实际执行过程可能进行了优化，而不是我们理解上的逐条对比。

7.Count(*)优化

7.1执行原理

        Count关键字有下面四种用法：

EXPLAIN SELECT COUNT(1) FROM employees;
EXPLAIN SELECT COUNT(id) FROM employees;
EXPLAIN SELECT COUNT(NAME) FROM employees;
EXPLAIN SELECT COUNT(*) FROM employees;

        四个SQL最终的执行计计划如下：

        type为index，且Extra为Using index，代表均走了索引，key索引字段都走的是idx_name_age_position二级索引（非聚簇索引）

        四个SQL的执行计划一样，说明这四个SQL的执行效率都应该差不多。

        字段有索引时：count(*) ≈ count(1) > count(字段) > count(主键ID)

        分析：

        count的整体执行的流程是将对应的数据取出进行累加计算出一个值，计算出后返回。对于COUNT(1)和COUNT(字段)来说，两者的执行流程是类似的，不过COUNT(1)不需要取出字段统计，只需要统计常量1即可，COUNT(字段)还需要取出字段，理论上COUNT(1)比COUNT(字段)会快一些。

        COUNT(*)是例外，MySQL并不会将全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用COUNT(列名)或者COUNT(常量)来替代COUNT(*)。

        COUNT(id)之所以会在字段有索引时慢于COUNT(字段)，因为字段建立的是二级非聚簇索引，id的叶节点是聚簇索引，聚簇索引的数据量相对于二级非聚簇索引是更大的，所以COUNT(id)的性能会较差一些。但是在MySQL5.7时针对这个进行了对应的优化，当表中建立了二级索引时，使用COUNT(id)时，就会走二级索引树，来优化提升性能。

        字段没有索引时：count(*) ≈ count(1) > count(主键ID) > count(字段)

        因为字段没有索引时，count(字段)是无法走索引的，只能ALL全表扫描，但是count(主键ID)仍然可以走索引，所以性能会更高一些。

7.2优化方案

7.2.1查询MySQL自己维护的总行数

        对于myisam存储引擎的表做不带WHERE条件的COUNT查询性能是很高的，因为myisam存储引擎的表的总行数会被mysql存储在磁盘上，查询不需要计算。

        看下面这个SQL查询语句：

EXPLAIN SELECT COUNT(*) FROM test_myisam;

        这个SQL语句的执行计划中Extra是Select table optimized away，type是null，即代表这条SQL语句的执行速度特别快，性能特别高。

        对于innodb存储引擎的表，MySQL不会存储表的总记录行数（因为有MVVC机制），查询count需要实时计算。

7.2.2 show table status

        如果只需要知道表总行数的估计值可以使用如下SQL查询，性能很高：

SHOW TABLE STATUS LIKE 'employees';

        MySQL会在表中维护一个STATUS作为总行数的估计值，虽然不是很准确但是在很多场景下也足够使用了。

7.2.3将总数维护到Redis中

        插入或者删除数据行的时候同时维护Redis中的表总行数key的计数值（用incr和decr命令），但是这种方式可能不准，很难保证表操作和Redis操作的事务一致性。

7.2.4增加数据库计数表

        插入或者删除数据行的时候同时维护计数表，让他们在同一个事务里操作，这种情况下不会出现数据不一致的情况。

8.MySQL数据类型选择

8.1数据类型

        在MySQL中选择正确的数据类型，对于性能至关重要，一般应该遵循下面两部：

        （1）确定合适的大类型：数字、字符串、时间、二进制。

        （2）确定具体的类型：有无符号、取值范围、变长定长登。

        MySQL数据类型设置方面，尽量用更小的数据类型，因为它们通常有更好的性能，花费更少的硬件资源。并且尽量把字段定义为NOT NULL，避免使用NULL。

        尽量参考对应的数据表。

        优化建议：

        1.如果整形数据没有负数，如ID号，建议指定为UNSIGNED无符号类型，容量可以扩大一倍。

        2.建议使用TINYINT代替ENUM、BITENUM、SET。

        3.避免使用整数的显示宽度，也就是说，不要使用INT(10)类似的方法指定自动福安显示宽度，直接用INT。

        4.DECIMAL最适合保存准确度要求高，而且用于计算的数据，比如价格。但是在使用DECIMAL类型的时候，注意长度设置。

        5.建议使用整形类型来运算和存储实数，方法是，实数乘以相应的倍数后再操作。

        6.整数通常是最佳的数据类型，因为它速度快，并且能使用AUTO_INCREMENT。

8.2日期和时间

        小公司建议使用TIMESTAMP，因为TIMESTAMP相对于DATETIME更加节省内存。

        大公司建议使用DATETIME，因为TIMESTAMP有2038危机。

        优化建议：

        1.MySQL呢个存储的最小时间粒度为秒。

        2.建议使用DATE数据类型来保存日期。MySQL中默认的日期格式是yyyy-mm-dd。

        3.用MySQL的内建类型DATE、TIME、DATETIME来存储时间，而不是使用字符串。

        4.当数据格式为TIMESTAMP和DATETIME时，可以使用CURRENT_TIMESTAMP作为默认值（MySQL5.6以后），MySQL会自动返回记录插入的确切时间。

        5.TIMESTAMP是UTC时间戳，与时区相关。

        6.DATETIME的存储格式时一个YYYYMMDD HH:MM:SS的整数，与时区无关，存储了什么，读出来就是什么。

        7.除非有特殊需求，一般的公司建议使用TIMESTAMP，相比与DATETIME更加节约空间，但是像阿里这种大公司一般会使用DATETIME，因为无需考虑TIMESTAMP的2038危机。

        8.有时人们把Unix的时间戳保存为整数值，但是这样通常没有任何好处，而且这种格式处理起来也不是很方便。

8.3字符串

        只需要简单了解以下存储字符的格式即可，其他无需了解了：

        优化建议：

        1.字符串的长度相差较大用VARCHAR；字符串短，且所有值都接近一个长度用CHAR。

        2.CHAR和VARCHAR适用于包括人名、邮政编码、电话号码和不超过255个字符长度的任意字母数字组合。那些要用来计算的数字不要用VARCHAR类型保存，因为可能会导致一些与计算相关的问题。换句话说，可能会影响到计算的准确性和完整性。

        3.尽量少用BLOB和TEXT，如果实在要用可以考虑将BLOB和TEXT单独存储到一张表中，用ID关联。主要是因为TEXT和BLOB字段中存储的数据是比较大的，并且TEXT和BLOB的数据可能是不经常需要去查询的，如果不需要去查询，还在表的聚簇索引中跟随扫表，就会出现性能下滑的现象，所以将其单独存到一张表中有利于提高性能。

        4.BLOB系列存储二进制字符串，与字符集无关。TEXT系列存储非二进制字符串，与字符集相关。

        5.BLOB和TEXT都不能有默认值。