关于explain结果的疑问

YoungCui 2008-05-22 07:53:14
有两个问题,希望知道的兄弟点拨一下!

+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 3 | Using temporary; Using file
| 1 | PRIMARY | T3 | eq_ref | PRIMARY | PRIMARY | 4 | T4.COMPANYID | 1 |
| 1 | PRIMARY | T2 | ref | PRIMARY,2 | PRIMARY | 4 | T4.COMPANYID | 727 | Using where
| 2 | DERIVED | mail_stat_tbl | index | 2 | PRIMARY | 11 | NULL | 2910 |
+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
1、对于最后一行有一个疑问。possible_keys里面只有2,为什么key里面却是PRIMARY?key里面还能出现possible_keys里面没有的?

+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 3 | Using temporary; Using file
| 1 | PRIMARY | T3 | eq_ref | PRIMARY | PRIMARY | 4 | T4.COMPANYID | 1 |
| 1 | PRIMARY | T2 | ref | PRIMARY | PRIMARY | 4 | T4.COMPANYID | 3105 | Using where
| 2 | DERIVED | mail_stat_tbl | index | NULL | PRIMARY | 11 | NULL | 6211 | Using where
+----+-------------+---------------+--------+---------------+---------+---------+--------------+------+----------------------------
2、上面是我把2这个index删掉后的结果。rows由2910增加到了6211,这是不是说明2这个index本来还是有用的?
...全文
162 16 打赏 收藏 转发到动态 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
YoungCui 2008-05-30
  • 打赏
  • 举报
回复
谢谢各位兄弟的回答!
hrb2008 2008-05-28
  • 打赏
  • 举报
回复
执行一次在history里面就可以看到精确的执行时间。
love_mysql 2008-05-28
  • 打赏
  • 举报
回复
各位的解释都很明显了,还不懂嘛?
YoungCui 2008-05-28
  • 打赏
  • 举报
回复
[Quote=引用 10 楼 hrb2008 的回复:]

possible_keys列指出MySQL能使用哪个索引在该表中找到行。该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
key列显示MySQL实际决定使用的键(索引)。
就是说possible_keys列可能使用索引,但实际执行的时候,不一定用possible里面的内容。2是常量,在type里面是index说明对索引树进行扫描,扫描条件为2的所有索引,比all要快。再理解一下,你的几表关联中用到了…
[/Quote]
2是个索引,我把子查询用到的字段提取出来作为了一个索引,名字起得不太好,呵呵。
我现在疑惑的是key里面显示两次查询都只用了PRIMARY作为索引,可为啥rows结果不一样。现在想想可能rows也许只是预先结果而已。

有啥办法可以精确知道这次查询使用了多少时间吗?
懒得去死 2008-05-28
  • 打赏
  • 举报
回复
[Quote=引用 14 楼 YoungCui 的回复:]
引用 12 楼 love_mysql 的回复:
各位的解释都很明显了,还不懂嘛?

我想在不明白的是这个:
我现在疑惑的是key里面显示两次查询都只用了PRIMARY作为索引,可为啥rows结果不一样。
[/Quote]

Mysql will use its own way to optimize this.
YoungCui 2008-05-28
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 love_mysql 的回复:]
各位的解释都很明显了,还不懂嘛?
[/Quote]
我想在不明白的是这个:
我现在疑惑的是key里面显示两次查询都只用了PRIMARY作为索引,可为啥rows结果不一样。
hrb2008 2008-05-27
  • 打赏
  • 举报
回复

possible_keys列指出MySQL能使用哪个索引在该表中找到行。该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
key列显示MySQL实际决定使用的键(索引)。
就是说possible_keys列可能使用索引,但实际执行的时候,不一定用possible里面的内容。2是常量,在type里面是index说明对索引树进行扫描,扫描条件为2的所有索引,比all要快。再理解一下,你的几表关联中用到了select xxx from tb where tb.indexcol=2
wwwwb 2008-05-26
  • 打赏
  • 举报
回复
MYSQL根据索引来决定搜索哪些行,没有索引搜索的行数>使用搜索的行数,查找时间要多一些。
YoungCui 2008-05-26
  • 打赏
  • 举报
回复
抛开possible_keys不说。key这边来看,两次查询走的索引都是PRIMARY,可是为什么两次查询rows的记录数不一样?
wwwwb 2008-05-26
  • 打赏
  • 举报
回复
[Quote=引用 8 楼 YoungCui 的回复:]
引用 7 楼 wwwwb 的回复:
MYSQL根据索引来决定搜索哪些行,没有索引搜索的行数>使用搜索的行数,查找时间要多一些。

可是两次查询的key里面都写着PRIMARY,我的理解是:两次查询都使用了主键作为索引。。。
[/Quote]
2 ¦ DERIVED ¦ mail_stat_tbl ¦ index ¦ 2 ¦ PRIMARY ¦ 11 ¦ NULL ¦ 2910

去掉索引
2 ¦ DERIVED ¦ mail_stat_tbl ¦ index ¦ NULL ¦ PRIMARY ¦ 11 ¦ NULL ¦ 6211 ¦ Using where

YoungCui 2008-05-26
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 wwwwb 的回复:]
MYSQL根据索引来决定搜索哪些行,没有索引搜索的行数>使用搜索的行数,查找时间要多一些。
[/Quote]
可是两次查询的key里面都写着PRIMARY,我的理解是:两次查询都使用了主键作为索引。。。
wwwwb 2008-05-23
  • 打赏
  • 举报
回复
possible_keys
The possible_keys column indicates which indexes MySQL can choose from use to find the rows in this table. Note that this column is totally independent of the order of the tables as displayed in the output from EXPLAIN. That means that some of the keys in possible_keys might not be usable in practice with the generated table order.

key

The key column indicates the key (index) that MySQL actually decided to use. If MySQL decides to use one of the possible_keys indexes to look up rows, that index is listed as the key value.

It is possible that key will name an index that is not present in the possible_keys value. This can happen if none of the possible_keys indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index. That is, the named index covers the selected columns, so although it is not used to determine which rows to retrieve, an index scan is more efficient than a data row scan.

上述是MYSQL的解释,也就是说possible_keys中的KEYS在实际是有些是没有用到的,
而KEY是实际用到的列。
wwwwb 2008-05-23
  • 打赏
  • 举报
回复
2、
在查询字段上建立索引,一般会减少查询时间,从你的结果可以看出
懒得去死 2008-05-23
  • 打赏
  • 举报
回复
The basic reslut is the fewer section Extra ,the result will be better.
wwoo_1105 2008-05-22
  • 打赏
  • 举报
回复
o
xbt746 2008-05-22
  • 打赏
  • 举报
回复
肯定啊,有索引肯定会提高你查询的速度
但是会浪费一定空间,将你查询多的字段设为索引是有必要的
关键字一般会自动生成索引

56,687

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧