?
mysql性能问题定位
??使用mysql作为基础数据库的应用，可能会遇到一些数据库方面的性能问题，我们可以通过一些方法进行问题定位。以下介绍可以定位性能问题的四种方法，欢迎拍砖。
一、开启慢查询日志：
记录执行查询时间大于long_query_time的sql，long_query_time默认为2s;
show variables like ‘%slow%’
?
?
得到图中所示信息，这里可以查看到慢查询日志是否开启，慢查询日志文件的存放目录。
开启慢查询日志的方法：
1、vi ?/etc/my.cnf(这个是mysql的默认读取配置文件目录，一般会将my.cnf文件放在这下面)
[mysqld]下添加
slow_query_log=ON
long_query_time=1(sql语句执行时间超过该参数值，则会打印在慢查询日志中），默认执行时间超过2s的sql会打印在慢查询日志中。
修改了my.cnf中的配置项，需要重启数据库。
2、不重启数据库的情况下，执行 set global slow_query_log=ON，可以开启慢查询日志。
开启慢查询日志后，跟踪慢查询日志文件中的慢查询sql，再具体分析，通过调整sql写法，或者添加正确的索引，可以看到意想不到的性能效果。
二、分析慢查询sql:
1、Explain 打印执行计划
执行的selcet语句前面加上explain，可以告诉你mysql如何执行该条语句。
?
这里需要额外注意type、key、rows 、extra列展示的内容。
其中，
Type=all，表示使用的是全表扫描，在数据量大的情况下，全表扫描是非常耗性能的，这个需要特别注意；
Type=index，表示使用索引扫描，只会遍历索引树；
Type=range,表示使用索引范围扫描，常见于between 、>、<等的查询。
Type=ref，非唯一性索引扫，返回匹配某个单独值得所有行
Type=eq_ref 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配
Type=const/system???读常量，最多只会有一条记录匹配，由于是常量，实际上只须要读一次
Type=null 不需要扫描表
访问类型从上到下由差变为最好。
key表示select中使用到的索引，如果为null，表示没有使用索引，从查询效率上讲，使用索引比不使用索引快。但并不是所有的都要加索引，索引也存在不足，这里就不详解。
rows表示执行该条sql所需要扫描的行数，这个没有绝对值可参考，一般来说越小越好，如果100万数据量的数据库，rows是70万，通过这个可以判断sql的查询性能很差，
