当面试官问：怎么优化sql？

今天，我就来和你们讲讲要怎么回答这道问题。首先，咱们要稳住不要慌，本身是本身亲手作的项目，第一个问题应该都不大，第二个问题就须要在面试以前作好充分的准备啦…

在回答问题以前先要了解查询的流程：查询是由一系列的子任务组成的，包括从客户端，到服务器，而后在服务器上进行解析，生成执行计划，执行，并返回结果给客户端。其中“执行”能够认为是整个生命周期中最重要的阶段，这其中包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序、分组。为了完成这些任务，查询须要在不一样的地方花费时间，包括网络，CPU计算，生成统计信息和执行计划、锁等待操做。进行一些没必要要的额外操做时或者某些重复执行某些额外操做会消耗大量的时间。

查询性能低下最基本的缘由是访问的数据太多。某些查询可能不可避免地须要筛选大量的数据，大部分性能低下的查询均可以经过减小访问的数据量的方式进行优化。对于低效的查询，能够经过如下两个步骤来分析：

• 确认应用程序是否在检索大量超过须要的数据。
• 确认MySQL服务器是否在分析大量超过须要的数据行。

上面的都是理论，在实践中，MySQL的优化主要涉及SQL语句及索引的优化、数据表结构的优化这三个方面。

SQL语句的优化：

一、少用子查询
尽可能少用子查询，由于子查询会产生临时表；除非像count(*)临时表很小的。

二、少用SELECT *
每次看到SELECT *都须要用怀疑的眼光审视，是否真的须要返回所有的列？取出所有的列，会让优化器没法完成索引覆盖扫描这类优化，还会为服务器带来额外的I/O、内存和CPU的消耗。

三、查询必要的记录
一个常见的错误是经常会误觉得MySQL只会返回须要的数据，实际上MySQL倒是先返回所有结果集再进行计算，建议在查询后面加上LIMIT。

四、不要重复查询相同的数据
不断执行相同的查询，而后每次都会返回彻底相同的数据。能够采用的方案是初次查询的时候将这个数据缓存起来，须要的时候从缓存中取出，这样性能显然会更好。

五、COUNT查询优化
COUNT()聚合函数的做用：统计某一个列值的数量，也能够统计行数。须要注意的是统计列值时要求列值是非空的(不统计NULL)，COUNT()查询尽量少的行。

举个例子：若是咱们直接查 id>100 的记录，涉及到的有两千多万行记录扫描。可是因为COUNT()特性，咱们能够用 count() - (id<100)的作法，这样扫描的行就只有100行了。

六、Where子句中，where表之间的链接必须写在其余Where条件以前，那些能够过滤掉最大数量记录的条件必须写在Where子句的末尾.HAVING最后。

七、用EXISTS替代IN、用NOT EXISTS替代NOT IN。

八、避免在索引列上使用计算。

九、避免在索引列上使用IS NULL和IS NOT NULL。

十、对查询进行优化，应尽可能避免全表扫描，首先应考虑在 where 及 order by 涉及的列上创建索引。

十一、应尽可能避免在 where 子句中对字段进行 null 值判断，不然将致使引擎放弃使用索引而进行全表扫描。

十二、应尽可能避免在 where 子句中对字段进行表达式操做，这将致使引擎放弃使用索引而进行全表扫描。

索引优化

一、关联查询优化
确保ON 或则USING 子句的列上有索引。建立索引时就要考虑关联的顺序，当表A和表B用列c关联的时候，若是优化器关联顺序是B、A，就只须要在表A上创建索引，没用的索引会占用存储。

二、GROUP BY 和 DISTINCT优化
GROUP BY 和 DISTINCT的优化最有效的就是使用索引。全部对于分组的列必定要创建索引。好比：

select product, count(*) from orders group by product;
这样的一个查询，对product要创建索引。

三、LIMIT分页优化
进行分页操做时，一般都会经过偏移量来查询某些数据。而后再加上解释的order by，性能通常都不错。对于order by的列 必定要加上索引。可是对于limit 10000，10 这样检索目标10条记录必须先先查询前面的10000条记录。代价很高，这种时候优化最简单办法就是使用覆盖索引。

注意索引失效的状况，
1)以“%”开头的LIKE语句，模糊匹配
2)OR语句先后没有同时使用索引
3)数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型）

数据库优化

选择优化数据类型的几条建议：

• 更小的一般更好，尽可能使用能够正确存储数据的最小数据类型，由于占用更少的磁盘、内存和CPU缓存。
• 简单最好，选择整数而不是字符串，选择MySQL内建的类型而不是字符串来存储时间和日期，使用整数来存储IP地址。
• 尽可能避免NULL，不少表都包含可为NULL的列，这是由于NULL是列的默认值，须要指定列为NOT NULL。
• 整数类型数据通常用int，对于布尔类型的数据用tinyint，可是整数计算通常是使用64位的BIGINT整数。
• 在须要对小数进行精确计算时，好比说存储财务数据才使用DECIMAL（浮点存储的float和double类型计算不精确），可是DECIMAL计算的代价很高，能够考虑使用BIGINT代替DECIMAL，将小数的位数乘以相应的倍数便可。
• varchar和char
  当须要存储可变长的字符串用varchar，比使用char存储更节省空间，varchar使用1或者2个额外的字节来记录长度。至于用char来存储适用于下列几种状况，一是须要存储很短的字符串时（存储只有Y和N的值时），二是全部的值接近固定长度（存储MD5值），三是常常须要变动的值。
• BIT
  在MySQL5.0以前，BIT是TINYINT的同义词，在MySQL5.0以及更新的版本，是一个彻底不一样的数据类型。BIT类型的新行为：（1）可使用BIT列在一列中存储一个或者多个true/false值。MySQL把BIT当作字符串类型，而不是数字类型。当检索BIT(1)的值时，结果是一个包含二进制0或者1的字符串，而不是ASCII的“0”或“1”。
• SET
  若是须要保存不少的true/false值，能够考虑合并这些列到一个SET数据类型，它在MySQL内部是一系列打包的位的集合来表示的。
• 使用枚举代替经常使用的字符串类型，由于MySQL在存储枚举时很是紧凑，MySQL把每一个枚举的值保存为整数，而且在表的.firm文件中保存“数字-字符串”映射关系的“查找表”。
• DATATIME存储的范围更广，保存的值从1001年到9999年，精确到秒，与时区无关，使用8个字节的存储空间，使用一种可排序、无歧义的格式显示时间，TIMESTAMP类型保存了从1970年1月1日午夜以来的秒数，使用4个字节的存储空间，只能表示从1970年到2038年，依赖于时区，空间效率更高，推荐使用TIMESTAMP
• 对于BOLB和TEXT类型他们都是为了存储很大的数据而设计的字符串，分别采用二进制和字符串方式存储。
• 不能有太多的列
• 单个查询最好在12个表之内作关联
• 当遇到未知值的时候不要惧怕使用NULL
• 在实际的应用中须要混用范式和反范式，使用部分范式化的schema、缓存表、以及其余的技巧，最多见的反范式化数据的方法是复制或者缓存，在不一样的表中存储相同的特定列。
• 修改.frm文件来加快ALTER TABLE 操做的速度
• 选取最适用的字段属性，尽量减小定义字段宽度，尽可能把字段设置NOTNULL，例如’省份’、’性别’最好适用ENUM
• 使用链接(JOIN)来代替子查询
• 用联合(UNION)来代替手动建立的临时表
• 锁定表、优化事务处理