MySQL优化-基础优化
慢查询日志
如何发现有问题的SQL？
使用MySql慢查日志对有效率问题的SQL进行监控
-- 查看慢查日志是否开启
show variables like 'slow_query_log';
-- 开启慢查日志
set global slow_query_log=on;
-- 查看日志保存位置
show variables like 'slow_query_log_file';
-- 设置日志保存位置
set global slow_query_log_file = '/home/mysql/sql_log/mysql-slow.log';
-- 开启索引记录
set global log_queries_not_using_indexes=on;
-- 设置时间，查询时间超过1s就记录(设置后需要重新连接数据库)
set global long_query_time=1;日志内容分析
为了方便测试，我们可以把超时记录时间设置为0，这样就能保证有日志的记录。
当随便执行一个查询之后，打开log，观察文档最后输出
执行SQL的主机信息
# User@Host: root[root] @ localhost [] Id: 56
SQL的执行信息 执行时长，锁定时长，发送行数，扫描行数
# Query_time: 0.068822 Lock_time: 0.000372 Rows_sent: 997 Rows_examined: 24861
时间时间
SET timestamp=1528166127;
具体的语句
select * from film_list;日志分析工具
虽然可以直接慢查询的数据都记录在了日志中，但是我们直接查看日志是不直观的，需要通过工具来快速的得到一些信息，比如：平均的查询时间，最耗时的查询语句等。
这里就介绍两款常用的日志分析工具
mysqldumpslow
mysqldumpslow是安装mysql时自带的一个工具，我们可以通过mysqldupmslow -h查看相关的帮助文档，这里我们就列举一些最常用的参数：
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]
Parse and summarize the MySQL slow query log. Options are
-s ORDER what to sort by (al, at, ar, c, l, r, t), 'at' is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time 比如我们想查询耗时最长的前十条语句，可以通过
mysqldumpslow -t 10 xxx.log输出如下：
-- count表示该语句的执行次数
Count: 1 Time=0.07s (0s) Lock=0.00s (0s) Rows=997.0 (997), root[root]@localhost
select * from film_listpt-query-digest
pt-query-digest 安装
直接分析慢查日志
pt-query-digest xxx.log 输出的分析内容还是较多的，这里可以参考MySQL慢查询（二） - pt-query-digest详解慢查询日志
explain分析执行计划
在查找到执行较慢的SQL后，我们可以通过explain来分析sql的执行计划，比如：
explain select customer_id, first_name, last_name from customer;结果如下：
+—-+————-+———-+——+—————+——+———+——+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——+—————+——+———+——+——+——-+
| 1 | SIMPLE | customer | ALL | NULL | NULL | NULL | NULL | 599 | NULL |
+—-+————-+———-+——+—————+——+———+——+——+——-+
1 row in set (0.00 sec)
- table:：显示这一行的数据是关于哪张表的
- type： 显示连接使用了何种类型，从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL。
- const：表明是常数查找，一般对于主键或者唯一索引，因为只有一行符合条件
- eq_reg：是一种范围查找，对于主键或者唯一索引范围里的查找
- ref：常见于联接的查询中，一个表基于某个索引的查找
- rang：基于索引的范围查找
- index：索引的扫描
- ALL：表扫描
- possible_keys：显示可能应用在这张表中的索引。如果为NULL，表示没有可用的索引
- key：实际使用的索引。如果为NULL，则没有使用索引
- key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好 。MySQL explain中key_len的计算
- ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
- rows：MySql认为必须检查的用来返回请求数据的行数 ，数值越大越不好，说明没有用好索引
- extra：关于mysql如何解析查询的额外信息。using temporary和using filesort是最差的情况，意思mysql根本不能使用索引，结果是检索会很慢
- Using filesort：看到这个的时候，查询就需要优化了。MySql需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
- Using temporary：MySql需要创建一个临时表来存储结果，这通常发生在对不同的列集进行order by上，而不是group by上
Profile
Profile是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量
默认情况下，参数处于关闭状态，并保存最近15次的运行结果
-- 查看是否开启profile
SHOW variables like 'profiling';
-- 开启profile
set profiling=on;查看profile
show profiles
进一步分析
show profile cpu,block io for query 上一步前面的问题SQL数字号码;
重点需要关注的几个项：
converting HEAP to MyISAM：查询结果太大，内存都不够用了往磁盘上搬了
create tmp table：创建临时表，要注意
Copying to tmp table on disk：把内存临时表复制到磁盘
Count()
首先说明一下count(*)和count(1)，它们俩在是没有什么不同的。
高性能MySQL——Count(1) OR Count(*)？
MySQL伪科学之count(1)好快
Count()中是可以加条件的：
-- 一条sql同时查出2006和2007年的电影数量
SELECT COUNT(release_year='2006' OR NULL) AS '2006年电影数量', COUNT(release_year='2007' OR NULL) AS '2007年电影数量' FROM film;