关于join

Question

select * from i, r where i.id = r.id and r.rid = 439 and r.id > 1000 order by r.id desc limit 10;
select * from i, r where i.id = r.id and r.rid = 439 and r.id > 1000 and i.name="netxuning" order by r.id desc limit 10;
i表中id是主键，r表中在r(rid, id)上建立了索引，两条语句的不同之处就在于，第二条语句多了一个i表上name字段的判断，
在数据量巨大的时候，多出的条件导致了查询速度的巨大差别！第二条会相当慢！
我估计，其原因应该是第二条语句要列出结果就要判断i表的name字段，所以在判断的过程中就要join大量的字段，
而第一条语句则没有这样的顾虑，它的join时机是在r表上r.rid = 439， r.id > 1000 这两个条件都满足后，直接将最新的10条与i表join即可！不知道我分析的对不对！
还有就是，这样的两条语句explain的结果是一模一样的，一直误导了我！

Answer 1

呵呵 ，基本是这样，因为name上没有 索引，查找费时间 
EXPLAIN只能做参考，网上有文章说EXPLAIN也会撒谎

Answer 2

explain select * from i, r where i.id = r.id and r.rid = 439 and r.id > 1000 and i.name="netxuning" order by r.id desc limit 10;看一下，另外show index from xx 一下。
理论上应该不会。应该不是。

Answer 3

那我就先在i(id, name)上建立个索引试试。

Answer 4

不对啊，在i(id, name)上建索引根本没用，因为id本身就是主键了！

Answer 5

在i(name)或i(name, id)上建立索引应该也没有作用，mysql优化器应该还是首选id主键作为索引！

Answer 6

id 已经是主键了，所有MYSQL不可以去选 (id,name) 这个索引，这个索引也是毫无意义的。1,'AA'
2, 'CC'这种索引还不如直接的1,
2

Answer 7

这个是MySQL的索引特性，应当建立name索引，而MySQL索引中又会自动包含PK

Answer 8

版主是说在name上建索引没用？

Answer 9

是的，建一个单独的NAME索引。

Answer 10

如果用name上的索引的话，在join过程中没有索引可依据，必定更慢！

Answer 11

不一定，要看你的数据分布。
JOIN中总有一个表上是用不了索引的关键是如果让你人为的决定，你会如何计划这个SQL语句的执行方案。根据这个，然后再看需要添加什么索引，或者使用索引HINT.

Answer 12

错，看我7F回复，MySQL索引的特性

Answer 13

MySQL索引，比如用BTree，节点上保存记录行信息（相当于Oracle的rowId)的时候，
首先看这张表是不是单一字段做PK，
如果没有，在找单一字段的Unique Key
如果还没有的话，处理方式忘记了，但肯定会让索引效率降低很多