??? 首先从一个问题说起。

??? 问题现象：
??? 查询语句如下：

-- sql1
    SELECT 
               w.wid, w.rid
      FROM warestock w JOIN product p ON w.wid = p.product_code
     WHERE w.rid IN (3, 4, 5, 6, 10)

?

??? warestock 在 wid ,rid上创建了联合主键，product_code是product的主键。我期望的输出结果能按照w.wid, w.rid的顺序排序。结果却没有按照这个w.wid, w.rid升序输出结果。

????? 按照以往的知识，sql执行时应该是直接索引扫描warestock，然后再关联product时用到主键关联。然后再用rid过滤数据。 结果却并没有按照w.wid, w.rid的顺序排序。

?? 分析原因：

??? 1.怀疑是查询缓存问题：加上SQL_NO_CACHE，输出结果和sql1完全一致，说明与查询缓存无关。
??? 2.warestock 和product执行顺序的原因。把sql1换成如下子查询，确实也能实现按照顺序wid，rid输出结果。

SELECT  
               w.wid, w.rid
          FROM warestock w where w.rid IN (3, 4, 5, 6, 10)
      and exists(select 1 from product p where p.product_code = w.wid)

??? 或者忽略warestock表的主键索引也能达到同样的效果，sql如下，但是根本原因还是没有找到。

SELECT  SQL_NO_CACHE
               w.wid, w.rid
      FROM warestock w  IGNORE INDEX (PRIMARY) JOIN product p  ON w.wid = p.product_code
     WHERE w.rid IN (3, 4, 5, 6, 10)

??? 3.再次分析执行计划，发现warestock并没有按照用到主键索引。而是index_pc，再查看索引： show index from product?? 不知道什么时候在product上的run_type字段建了索引。到此为止，查明原因：product并没有使用主键索引导致没有按照顺序输出结果。

??

?

?? 解决方案如下：

??????? 1.删除掉离散度较低的索引 或者
???????? 2.强制使用product的主键索引

SELECT  SQL_NO_CACHE
               w.wid, w.rid
      FROM warestock w   JOIN product p FORCE INDEX (PRIMARY) ON w.wid = p.product_code
     WHERE w.rid IN (3, 4, 5, 6, 10)

?? 结论、扩展：

?

?? 1.MyIsam和innodb数据和索引存储结构方式是不一样的。
??????? Innodb主键索引是主键和数据列放在一起，每个普通索引都带着主键列，并且索引顺序是按照普通索引列和主键列排序；MyIsam主键索引是和数据列放开存放的，普通索引和主键索引没有任何区别，普通索引也不会保存主键索引的信息。从以下sql的执行计划中也可以看出这一点：

  -- sql2
        CREATE TABLE test1 (
          `wid` bigint(20) NOT NULL COMMENT 'SKU代码(商品编号)',
          `orgid` int(11) NOT NULL DEFAULT '0',
          `topwpid` int(11) DEFAULT NULL,
          PRIMARY KEY (`wid` ),
         KEY k_orgid (`orgid`)
        ) ENGINE=Innodb DEFAULT CHARSET=utf8;

?

?

      insert into test1 values(12345,12345,111),

        (12346,12346,111) ;

        -- sql3:

        select wid from  test1 

?

??? 索引和主键存放在一起，用到了覆盖索引。执行计划如下：

???

?
??? 修改test1 的存储引擎为MyISAM，执行计划如下：
???

?
????? 上面的执行计划用到的索引不一样，原因是存储引擎是InnoDB时sql3用到了覆盖索引，而存储引擎是MyISAM时，只需主键索引扫描即可，因为主键索引和数据列是分开存放的。 这也从侧面验证了如上面所说的Innodb和MyIsam普通索引的存储方式。
? `?? 如此说来sql3执行时，存储引擎是Innodb时，如果暗示优化器忽略IGNORE INDEX普通索引k_orgid，则会按照PRIMARY扫描。
??????? 如果忽略PRIMARY，则会按照普通索引k_orgid扫描
??????? 存储引擎是MyIsam时,如果IGNORE INDEX普通索引k_orgid，则依然按照PRIMARY扫描。如果忽略PRIMARY，则会执行全表扫描。

?????? 2.根据统计信息分析后，优化器会合理选择小表驱动大表的执行计划。
??????? sql1 的执行计划可以看出这一点

?