共计 2333 个字符，预计需要花费 6 分钟才能阅读完成。
1. 查看 sql 的执行频率
MySQL 客户端连贯胜利后，通过 show [session|global] status 命令能够提供服务器状态信息。show [session|global] status 能够依据须要加上参数“session”或者“global”来显示 session 级（以后连贯）的计后果和 global 级（自数据库上次启动至今）的统计后果。如果不写，默认应用参数是“session”。
2. 定位效率底下的 sql
能够通过以下两种形式定位执行效率较低的 SQL 语句。
慢查问日志 : 通过慢查问日志定位那些执行效率较低的 SQL 语句，用 –log-slow-queries[=file_name]选项启 动时，mysqld 写一个蕴含所有执行工夫超过 long_query_time 秒的 SQL 语句的日志文件。具体能够查看本 书第 26 章中日志治理的相干局部。
show processlist : 慢查问日志在查问完结当前才纪录，所以在利用反映执行效率呈现问题的时候查问慢查问 日志并不能定位问题，能够应用 show processlist 命令查看以后 MySQL 在进行的线程，包含线程的状态、是否 锁表等，能够实时地查看 SQL 的执行状况，同时对一些锁表操作进行优化。
3.explain 剖析执行打算
type 显示的是拜访类型，是较为重要的一个指标，可取值为：
一般来说，咱们须要保障查问至多达到 range 级别，最好达到 ref。
Mysql 从 5.0.37 版本开始减少了对 show profiles 和 show profile 语句的反对。show profiles 可能在做 SQL 优化时 帮忙咱们理解工夫都消耗到哪里去了。
4. 索引的应用
如果索引了多列，要恪守最左前缀法令。指的是查问从索引的最左前列开始，并且不跳过索引中的列。匹配最左前缀法令，走索引。
不要在索引列上进行运算操作，索引将生效。
字符串不加单引号，造成索引生效。
尽量应用笼罩索引（只拜访索引的查问（索引列齐全蕴含查问列）），缩小 select *。
用 or 宰割开的条件，如果 or 前的条件中的列有索引，而前面的列中没有索引，那么波及的索引都不会被用到。
以 % 结尾的 Like 含糊查问，索引生效。如果仅仅是尾部含糊匹配，索引不会生效。如果是头部含糊匹配，索引生效。通过笼罩索引可解决。
如果 MySQL 评估应用索引比全表更慢，则不应用索引。
in 走索引，not in 索引生效。
is NULL，is NOT NULL 有时索引生效。
尽量应用复合索引，而少应用单列索引。单列索引数据库会抉择一个最优的索引（辨识度最高索引）来应用，并不会应用全副索引。
5. 插入数据优化
对于 InnoDB 类型的表，有以下几种形式能够进步导入的效率：
因为 InnoDB 类型的表是依照主键的程序保留的，所以将导入的数据依照主键的顺序排列，能够无效的进步导入数 据的效率。如果 InnoDB 表没有主键，那么零碎会主动默认创立一个外部列作为主键，所以如果能够给表创立一个 主键，将能够利用这点，来进步导入数据的效率。
在导入数据前执行 SET UNIQUE_CHECKS=0，敞开唯一性校验，在导入完结后执行 SET UNIQUE_CHECKS=1，恢 复唯一性校验，能够进步导入的效率。
如果利用应用主动提交的形式，倡议在导入前执行 SET AUTOCOMMIT=0，敞开主动提交，导入完结后再执行 SET AUTOCOMMIT=1，关上主动提交，也能够进步导入的效率。
insert 优化：
如果须要同时对一张表插入很多行数据时，应该尽量应用多个值表的 insert 语句，这种形式将大大的缩减客户 端与数据库之间的连贯、敞开等耗费。使得效率比离开执行的单个 insert 语句快。
在事务中进行数据插入。
数据有序插入。
6.order by 语句优化：
两种排序形式
1). 第一种是通过对返回数据进行排序，也就是通常说的 filesort 排序，所有不是通过索引间接返回排序后果的排序 都叫 FileSort 排序。
2). 第二种通过有序索引程序扫描间接返回有序数据，这种状况即为 using index，不须要额定排序，操作效率高。
理解了 MySQL 的排序形式，优化指标就清晰了：尽量减少额定的排序，通过索引间接返回有序数据。where 条件 和 Order by 应用雷同的索引，并且 Order By 的程序和索引程序雷同，并且 Order by 的字段都是升序，或者都是 降序。否则必定须要额定的操作，这样就会呈现 FileSort。
如果查问蕴含 group by 然而用户想要防止排序后果的耗费，则能够执行 order by null 禁止排序。
7. 优化嵌套查问
Mysql4.1 版本之后，开始反对 SQL 的子查问。这个技术能够应用 SELECT 语句来创立一个单列的查问后果，而后把 这个后果作为过滤条件用在另一个查问中。应用子查问能够一次性的实现很多逻辑上须要多个步骤能力实现的 SQL 操作，同时也能够防止事务或者表锁死，并且写起来也很容易。然而，有些状况下，子查问是能够被更高效的连贯（JOIN）代替。连贯 (Join) 查问之所以更有效率一些，是因为 MySQL 不须要在内存中创立长期表来实现这个逻辑上须要两个步骤的 查问工作。
- 优化 OR 条件
对于蕴含 OR 的查问子句，如果要利用索引，则 OR 之间的每个条件列都必须用到索引，而且不能应用到复合索 引；如果没有索引，则应该思考减少索引。UNION 语句的 ref 值为 const，OR 语句的 type 值为 null，const 示意是常量值援用，十分快 这两项的差距就阐明了 UNION 要优于 OR。
9. 优化分页查问
个别分页查问时，通过创立笼罩索引可能比拟好地进步性能。在索引上实现排序分页操作，最初依据主键关联回原表查问所须要的其余列内容。也能够对于主键自增的表，能够把 Limit 查问转换成某个地位的查问。