Mysql 基础和优化

1、字段类型

Mysql字段类型

2、索引

2.1、分类

MySQL索引分为普通索引、唯一索引、主键索引、组合索引、全文索引。索引不会包含有null值的列，索引项可以为null（唯一索引、组合索引等），但是只要列中有null值就不会被包含在索引中。

1、普通索引：create index index_name on table(column)；
或者创建表时指定，create table(..., index index_name column);

2、唯一索引：类似普通索引，索引列的值必须唯一（可以为空，这点和主键索引不同）
create unique index index_name on table(column)；或者创建表时指定unique index_name column

3、主键索引：特殊的唯一索引，不允许为空，只能有一个，一般是在建表时指定primary key(column)

4、组合索引：在多个字段上创建索引，遵循最左前缀原则。alter table t add index index_name(a,b,c);

5、全文索引：主要用来查找文本中的关键字，不是直接与索引中的值相比较，
像是一个搜索引擎，配合match against使用，现在只有char，varchar，text上可以创建全文索引。
在数据量较大时，先将数据放在一张没有全文索引的表里，然后再利用create index创建全文索引，比先生成全文索引再插入数据快很多。

2.2、何时使用索引

MySQL每次查询只使用一个索引。与其说是“数据库查询只能用到一个索引”，倒不如说，和全表扫描比起来，去分析两个索引B+树更加耗费时间。所以where A=a and B=b这种查询使用（A，B）的组合索引最佳，B+树根据（A，B）来排序。

1、主键，unique字段；

2、和其他表做连接的字段需要加索引；

3、在where里使用＞，≥，＝，＜，≤，is null和between等字段；

4、使用不以通配符开始的like，where A like 'China%'；

5、聚集函数MIN()，MAX()中的字段；

6、order by和group by字段；

2.3、何时不使用索引

1、表记录太少；

2、数据重复且分布平均的字段（只有很少数据值的列）；

3、经常插入、删除、修改的表要减少索引；

4、text，image等类型不应该建立索引，这些列的数据量大（假如text前10个字符唯一，也可以对text前10个字符建立索引）；

5、MySQL能估计出全表扫描比使用索引更快时，不使用索引；

2.4、索引何时失效

1、组合索引未使用最左前缀，例如组合索引（A，B），where B=b不会使用索引；

2、like未使用最左前缀，where A like '%China'；

3、搜索一个索引而在另一个索引上做order by，where A=a order by B，只使用A上的索引，因为查询只使用一个索引 ；

4、or会使索引失效。如果查询字段相同，也可以使用索引。例如where A=a1 or A=a2（生效），where A=a or B=b（失效）

5、如果列类型是字符串，要使用引号。例如where A='China'，否则索引失效（会进行类型转换）；

6、在索引列上的操作，函数（upper()等）、or、！=(<>)、not in等；

2.5、explain字段解释

explain字段解释

3、Mysql 语句优化

3.1、优化目标

1、减少 IO 次数

IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，
大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，
当然，也是收效最明显的优化手段。

2、降低 CPU 计算

除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。
order by，group by，distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。
当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标

3.2、优化方法

1、改变 SQL 执行计划

明确了优化目标之后，我们需要确定达到我们目标的方法。
对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，
让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标。

3.3、常见误区

1、count(1)和count(primary_key) 优于 count(*)

很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count() ，
他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，因为数据库对 count() 计数操作做了一些特别的优化。

2、count(column) 和 count(*) 是一样的

这个误区甚至在很多的资深工程师或者是 DBA 中都普遍存在，很多人都会认为这是理所当然的。
实际上，count(column) 和 count(*) 是一个完全不一样的操作，所代表的意义也完全不一样。

count(column) 是表示结果集中有多少个column字段不为空的记录
count(*) 是表示整个结果集有多少条记录

3、select a,b from … 比 select a,b,c from … 可以让数据库访问更少的数据量

这个误区主要存在于大量的开发人员中，主要原因是对数据库的存储原理不是太了解。

实际上，大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位，一般为4KB，8KB…
大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。

所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。

当然，也有例外情况，那就是我们的这个查询在索引中就可以完成，
也就是说当只取 a,b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。
在这样的情况下，二者的IO量会有较大差异。

3.4、基本原则

1、尽可能对每一条运行在数据库中的SQL进行 explain

优化 SQL，需要做到心中有数，知道 SQL 的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。
在对数据库中运行的 SQL 进行了一段时间的优化之后，很明显的问题 SQL 可能已经很少了，大多都需要去发掘，
这时候就需要进行大量的 explain 操作收集执行计划，并判断是否需要进行优化。

2、尽量早过滤

这一优化策略其实最常见于索引的优化设计中(将过滤性更好的字段放得更靠前)。

在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。
比如我们在多个表进行分页数据查询的时候，我们最好是能够在一个表上先过滤好数据分好页，
然后再用分好页的结果集与另外的表 Join，这样可以尽可能多的减少不必要的 IO 操作，大大节省 IO 操作所消耗的时间。

3、尽量少排序

排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。

对于MySQL来说，减少排序有多种办法，比如：

上面误区中提到的通过利用索引来排序的方式进行优化

减少参与排序的记录条数

非必要不对数据进行排序

…

4、尽量少 join

MySQL 的优势在于简单，但这在某些方面其实也是其劣势。
MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。
对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。
但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。

5、尽量用 join 代替子查询

虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。
MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，
但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。
虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。

6、尽量少 or

当 where 子句中存在多个条件以“或”并存的时候，MySQL 的优化器并没有很好的解决其执行计划优化问题，
再加上 MySQL 特有的 SQL 与 Storage 分层架构方式，造成了其性能比较低下，
很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。

7、尽量用 union all 代替 union

union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作，
这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。
所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。

8、避免类型转换

这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换：

人为在column_name 上通过转换函数进行转换

直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引，如果非要转换，应该在传入的参数上进行转换

由数据库自己进行转换

如果我们传入的数据类型和字段类型不一致，同时我们又没有做任何类型转换处理，
MySQL 可能会自己对我们的数据进行类型转换操作，也可能不进行处理而交由存储引擎去处理，这样一来，就会出现索引无法使用的情况而造成执行计划问题。

4、Mysql 从设计上优化

Mysql 分表和表分区详解

5、Mysql 其他优化

优化 Mysql 从硬件和数据库参数设置等上进行优化的建议

对 Mysql 的配置文件 my.cnf 中的各项参数进行优化调整

6、相关知识

Mysql的MVCC