优化步骤
观察分析状态
S1、观察服务器的状态Status
S2、开启慢查询，定位执行慢的SQL
S3、EXPLAIN查看执行计划，或者使用show profile来查看每步骤的时间成本
优化方向
A1、利用缓存，或者更改缓存失效策略的方式来解决
A2、如果是SQL等待时间长，可以调优服务器的参数，比如适当增加数据库缓冲池等
A3、如果是SQL执行时间长，考虑是否因为索引设计问题，还是查询关联的数据表过多，还是因为数据表字段设计问题等
A4、如果已经达到了性能瓶颈，考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库、垂直分表，水平分表等
慢查询定位
查询是否开启：show variables like '%show_query_log'
查询时间阈值：show variables like '%long_query_times%'
使用mysqldumpslow工具分析
-s: 采用order排序方式
-t: 返回N条数据
-g: 后面可以是正则表达式，对大小写不敏感
EXPLAIN查看执行计划
可以获得哪些信息
id: 数据表的读取顺序
select_type: SELECT子句的类型
type：数据表的访问类型
possible_key: 哪些索引可以使用
key: 实际使用的索引
key_len: 使用索引的长度
ref: 上一个表的连接匹配条件
rows: 有多少被优化器查询
Extra: 额外的信息
SQL执行的顺序是根据id从大到小顺序执行，当id相同时，从上到下进行执行
type字段
all: 全数据表扫描
index: 全索引表扫描
range: 对索引列进行范围查找
index_merge: 合并索引，使用多个单列索引搜索
ref: 根据索引查找一个或多个值
eq_ref: 搜索时使用primary_key 或 unique 类型，常用于多表联查
const: 常量，表量多有一个匹配行，因为只有一行，在这行的列值可被优化器认为是常数
system: 系统，表只有一行（一般用于MyISAM或Memory表）
效率从低到高一次为： all < index < range < index_merge < ref < eq_ref < const/system
show profile查看执行时间
查看是否开启：show varibales like 'profiling'
当前会话都有哪些profiles: show profiles
查看某Query_ID开销： show profiles for query xx
命令将被弃用，我们可以从information_schema中的profiling数据表进行查看
