通常在优化SQL查询的时候，我们都会使用explain分析SQL执行计划，通常来说当用到组合索引的时候我们如何判断索引完全用上呢？当然高手看看表结构及SQL语句就知道到底用到了几个字段，对于不熟悉的同学呢？我们还是可以看看key_len的长度，当然这个计算还是有点复杂的，下面我们来谈谈explai...

【mysql】  【innodb】  【explain】  【key_len】  点击查看原文>

导读

EXPLAIN的结果中，有哪些关键信息值得注意呢？

MySQL的EXPLAIN当然和ORACLE的没法比，不过我们从它输出的结果中，也可以得到很多有用的信息。

总的来说，我们只需要关注结果中的几列：

导读

EXPLAIN中的key_len一列表示什么意思，该如何解读？

EXPLAIN执行计划中有一列 key_len 用于表示本次查询中，所选择的索引长度有多少字节，通常我们可借此判断联合索引有多少列被选择了。

在这里 key_len 大小的计算规则是：

• 一般地，key_len 等于索引列类型字节长度，例如int类型为4-bytes，bigint为8-bytes；

• 如果是字符串类型，还需要同时考虑字符集因素，例如：CHAR(30) UTF8则key_len至少是90-bytes；

• 若该列类型定义时允许NULL，其key_len还需要再加 1-bytes；

• 若该列类型为变长类型，例如 VARCHAR(TEXT\BLOB不允许整列创建索引，如果创建部分索引，也被视为动态列类型)，其key_len还需要再加 …

插图来自网络并作简单加工，如果觉得不当还请及时告知 ：）

我们使用EXPLAIN解析SQL执行计划时，如果有下面几种情况，就需要特别关注下了：

首先看下 type 这列的结果，如果有类型是 ALL 时，表示预计会进行全表扫描（full table scan）。通常全表扫描的代价是比较大的，建议创建适当的索引，通过索引检索避免全表扫描。此外，全索引扫描（full index scan）的代价有时候是比全表扫描还要高的，除非是基于InnoDB表的主键索引扫描。

再来看下 Extra 列的结果，如果有出现 Using temporary 或者 Using filesort 则要多加关注：

Using …

一.语法

   explain  select …

   例如: explain select * from user where name=’ranger’;

二.explain输出解释

   mysql> explain select * from user where name=’ranger’\G

   *************************** 1. row ***************************

   id: 1

   select_type: SIMPLE

   table: user

   type: const

   possible_keys: uniq_name

   key: uniq_name

   key_len: 152

   ref: const

   rows: 1

   Extra:

   1 row in set (0.01 sec)

1.id

   SELECT语句的ID编号,优先执行编号较大的查询,如果编号相同,则从上向下执行

   例如:

   mysql> explain select …

   问题

   用户工单疑问：相同的语句，只是最后的limit行数不同。奇怪的是，limit 10 的性能比limit 100的语句还慢约10倍。

   隐藏用户表信息，语句及结果如下

   SELECT f1 , SUM(`f2`) `CNT` FROM T WHERE f1 IS NOT NULL AND f3 = ’2014-05-12′ GROUP BY f1 ORDER BY `CNT` DESC LIMIT 10;

   执行时间3 min 3.65 sec

   SELECT f1 , SUM(`f2`) `CNT` FROM T WHERE f1 IS NOT NULL AND f3 = ’2014-05-12′ GROUP BY f1 ORDER BY `CNT` DESC LIMIT 100;

   执行时间1.24Sec.

   性能差距非常大！

   分析

   MySQL Tips：追查语句执行时最常用的方法，是通过explain来看语句的执行计划。

  …

Original post: http://anothermysqldba.blogspot.com/2014/04/mysql-explain-sqlnocache.html

所以今天我幫助的人與他們的數據庫的性能和過一些寫得不好的查詢就跑。 現在，肯定每個人都會犯錯，我們的目標是盡你所能，以避免它們。

因此，只是一對夫婦的有用的提示做你讓一個鬆散的查詢到您的環境之前。

通過首先解釋總是執行查詢。 這樣簡單的事情做的第一個解釋將確認沒有錯別字（因為它不會運行），並允許您優化查詢。
幾個環節已經存在有關如何使用說明：

• …

本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.penglixun.com/tech/database/data_distribution_on_mysql_explain.html

以前我一直以为，MySQL优化器只会根据数据的基数来判断执行计划的优化，在5.0时，基本上只要基数达不到要求，MySQL就不会选择索引。不过从今天优化一组SQL的情况来看，5.1早已不是这样，MySQL优化器考虑了数据分布的影响，使用不同的值，对同一条SQL可能产生完全不同的执行计划。可以做如下测试。

有一张表 A (id,c1)，假设采用“SELECT c1,count(*) FROM table GROUP BY c1”的方式来查看每一列每个值的数据量的结果如下：