2.1.2 尽量少排序

排序操作会消耗较多的CPU资源，所以减少排序可以在缓存命中率高等IO能力足够的场景下会较大影响SQL的响应时间。对于MySQL来说，减少排序有多种办法，比如：通过利用索引来排序的方式进行优化,减少参与排序的记录条数,非必要不对数据进行排序.

2.1.3 尽量避免select *

一方面select *的性能不好，显而易，它比select xx，yy from tt多花费的是获得表中各属性的性能。例外，我们在查询一张表获取一组数据的时候，大多数的时候并不需要这张表中的所有项，这时候简单地使用select *就会造成获得冗余的数据和浪费额外的IO。

2.1.4 尽量用join代替子查询

我们刚才讲到尽量少使用join，但是join在有的时候是必须要使用的，特别是几张表一起处理的时候。而相对于join，子查询更加消耗性能。这个也很容易理解，因为子查询的时候会在内存中内子查询的结果生成一张表然后再经过父查询得出最终结构，相当于经历了多次查询而且浪费了一定的内存空间。

2.1.5 尽量少 or

因为很多时候使用 union all 或者是union（必要的时候）的方式来代替“or”会得到更好的效果。

2.1.6 尽量用 union all 代替 union

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

2.1.7 尽量早过滤

这一优化策略其实最常见于索引的优化设计中，将过滤性更好的字段放得更靠前。在SQL编写中同样可以使用这一原则来优化一些Join的SQL。比如我们在多个表进行分页数据查询的时候，我们最好是能够在一个表上先过滤好数据分好页，然后再用分好页的结果集与另外的表 Join，这样可以尽可能多的减少不必要的 IO 操作，大大节省 IO 操作所消耗的时间。

2.1.8 避免类型转换

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

人为在column_name 上通过转换函数进行转换，直接导致 MySQL（实际上其他数据库也会有同样的问题）无法使用索引，如果非要转换，应该在传入的参数上进行转换，由数据库自己进行转换如果我们传入的数据类型和字段类型不一致，同时我们又没有做任何类型转换处理，MySQL可能会自己对我们的数据进行类型转换操作，也可能不进行处理而交由存储引擎去处理，这样一来，就会出现索引无法使用的情况而造成执行计划问题。

2.1.9 优先优化高并发的 SQL

对于破坏性来说，高并发的 SQL 总是会比低频率的来得大，因为高并发的 SQL 一旦出现问题，甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量IO而且响应很慢的SQL，由于频率低，即使遇到，最多就是让整个系统响应慢一点，但至少可能撑一会儿，让我们有缓冲的机会。

2.1.10 从全局出发优化，而不是片面调整

SQL 优化不能是单独针对某一个进行，而应充分考虑系统中所有的SQL，尤其是在通过调整索引优化SQL的执行计划的时候，千万不能顾此失彼，因小失大。尽可能对每一条运行在数据库中的SQL进行explain。优化 SQL，需要做到心中有数，知道 SQL的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后，很明显的问题 SQL 可能已经很少了，大多都需要去发掘，这时候就需要进行大量的 explain 操作收集执行计划，并判断是否需要进行优化。

2.2 SQL优化误区

在我们生活中有很多我们想当然的事情，但是事实却正好相反。在SQL优化的过程中也有这样的误区。

2.2.1 关于count() 的一些误区

通常我们会认为count(1)和count(primary_key)要优于 count(*)。

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

但是count(column) 和 count(*) 是一样的吗？

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

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

count(*) 是表示整个结果集有多少条记录。

2.2.2 关于select 的一些误区

同样一般我们会认为select a,b from … 比 select a,b,c from … 可以让数据库访问更少的数据量，因而效率会更高。

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

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

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

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

2.2.1 使用order by一定需要排序操作？

我们知道索引数据实际上是有序的，如果我们需要的数据和某个索引的顺序一致，而且我们的查询又通过这个索引来执行，那么数据库一般会省略排序操作，而直接将数据返回，因为数据库知道数据已经满足我们的排序需求了。

实际上，利用索引来优化有排序需求的 SQL，是一个非常重要的优化手段。

第三章 存储引擎的优化

MySQL的存储引擎是关系型数据库产品中最具有特色的了，不仅可以同时使用多种存储引擎，而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。在应对不同场景的处理的时候，选择不同的存储引擎能够有效地提高存储效率。

3.1 MyISAM

3.1.1 MyISAM的特性

MyISAM存储引擎不支持事务，所以对事务有要求的业务场景不能使用。其锁定机制是表级索引，这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能。

不仅会在写入的时候阻塞读取，MyISAM还会在读取的时候阻塞写入，但读本身并不会阻塞另外的读。MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO，但是这个缓存区只会缓存索引，而不会缓存数据。

3.1.2 MyISAM的适用性

MyISAM适用于不需要事务支持、并发性相对较低、数据修改相对较少的场景下。一般这类的系统会以读为主，对数据一致性要求不是很高。