1.MySQL常见瓶颈
1.CPU ：
SQL中对大量数据进行比较、关联、排序、分组 最大的压力在于 比较
2.IO：
1.实例内存满足不了缓存数据或排序等需要，导致产生大量 物理 IO。
2。查询执行效率低，扫描过多数据行。
3.锁
**1.不适宜的锁的设置，导致线程阻塞，性能下降。**<br /> **2.死锁，线程之间交叉调用资源，导致死锁，程序卡住。**
4.服务器硬件的性能瓶颈：top,free, iostat和vmstat来查看系统的性能状态
2.是什么(查看执行计划)
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是 如何处理你的SQL语句的。 分析你的查询语句或是表结构的性能瓶颈
官网介绍 http://dev.mysql.com/doc/refman/5.5/en/explain-output.html
2.能干嘛
1.表的读取顺序
2.哪些索引可以使用
3.数据读取操作的操作类型
4.哪些索引被实际使用
5.表之间的引用
6.每张表有多少行被物理查询
3.怎么玩
1.Explain + SQL语句
2.执行计划包含的信息
3.建表脚本
CREATE TABLE t1 (
id INT ( 10 ) AUTO_INCREMENT,
content VARCHAR ( 100 ) NULL,
PRIMARY KEY ( id )
);
CREATE TABLE t2 (
id INT ( 10 ) AUTO_INCREMENT,
content VARCHAR ( 100 ) NULL,
PRIMARY KEY ( id )
);
CREATE TABLE t3 (
id INT ( 10 ) AUTO_INCREMENT,
content VARCHAR ( 100 ) NULL,
PRIMARY KEY ( id )
);
CREATE TABLE t4 (
id INT ( 10 ) AUTO_INCREMENT,
content VARCHAR ( 100 ) NULL,
PRIMARY KEY ( id )
);
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));
4.各字段解释
1.id
1.select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序
2.三种情况
1.id相同，执行顺序由上至下
explain select * from t1,t2,t3 where t1.id=t2.id and t2.id=t3.id;
2.id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
3.id相同不同，同时存在
3.关注点
id号每个号码，表示一趟独立的查询。一个sql 的查询趟数越少越好。
2. select_type
1.有哪些
2. 查询的类型，主要是用于区别 普通查询、联合查询、子查询等的复杂查询
1. SIMPLE
**简单的 select 查询,查询中不包含子查询或者UNION**<br />
2. PRIMARY
**查询中若包含任何复杂的子部分，最外层查询则被标记为Primary**<br />
3. DERIVED 获得;取得;得到; (使)起源;(使)产生;
在FROM列表中包含的子查询被标记为DERIVED(衍生) MySQL会递归执行这些子查询, 把结果放在临时表里。<br />
4.SUBQUERY 子查询
**在SELECT或WHERE列表中包含了子查询**<br />
5。DEPENDENT SUBQUERY 依靠的; 依赖的 子查询
**在SELECT或WHERE列表中包含了子查询,子查询基于外层**<br />
6.UNCACHEABLE SUBQUREY 可缓存的 子查询
·
SHOW VARIABLES LIKE '%lower_case_table_names%';
SELECT @@lower_case_table_names FROM DUAL;
7. UNION
**若第二个SELECT出现在UNION之后，则被标记为UNION； 若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED**<br />
8.UNION RESULT
**从UNION表获取结果的SELECT**<br />
3.table
4.partitions
代表分区表中的命中情况，非分区表，该项为null
5.type
1. 访问类型排列
type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
system>const>eq_ref>ref>range>index>ALL
2.显示查询使用了何种类型，
从最好到最差依次是： system>const>eq_ref>ref>range>index>ALL
6.possible_keys
显示可能应用在这张表中的索引，一个或多个。 查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用
7.key
1.实际使用的索引。如果为NULL，则没有使用索引
2.查询中若使用了覆盖索引，则该索引和查询的select字段重叠
8.key_len
1.表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。
2.key_len字段能够帮你检查是否充分的利用上了索引
9.ref
显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值
10.rows
rows列显示MySQL认为它执行查询时必须检查的行数。越少越好
11.filtered
这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数
12.Extra
1.Using filesort
说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。 MySQL中无法利用索引完成的排序操作称为“文件排序”
出现filesort的情况：
优化后，不再出现filesort的情况：
查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
2 Using temporary
优化前存在 using temporary 和 using filesort
使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。
3.USING index
1.表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！ 如果同时出现using where，表明索引被用来执行索引键值的查找; 如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找。
2.利用索引进行了排序或分组
4.Using where
5.using join buffer
6.impossible where
7.select tables optimized away
在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者 对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算， 查询执行计划生成的阶段即完成优化。
在innodb中：
在Myisam中：
若有收获，就点个赞吧
0 人点赞
