实际上，聚集索引（akagen_clustre_index）的填充顺序除了rowid顺序之外没有任何规律或原因。实际上不可能按id顺序对rowid进行排序。
在InnoDB中，非聚集索引（也称为辅助索引）中的记录包含辅助索引中没有的行的主键列。InnoDB使用此主键值在聚集索引中搜索行。
次索引控制顺序。但是，每个次索引条目都有一个指向正确行的主键条目。另外，考虑一下您提到的k_name的覆盖索引场景。
现在，让我们换个主题，讨论一下PRIMARY KEY和k_name：

问题：主键和k_name中，谁的原始查询请求的列更多？
答复：k_name，因为它包含name和id（id是内部的，因为它是PRIMARY KEY）覆盖索引k_name比主键更能满足查询。

现在，如果查询是SELECT * FROM ORDER BY id，您的EXPLAIN PLAN应该如下所示：

mysql> explain select * from lookup order by id;
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+
| id | select_type | table  | type  | possible_keys | key     | key_len | ref  | rows | Extra |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+
|  1 | SIMPLE      | lookup | index | NULL          | PRIMARY | 4       | NULL |    6 |       |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.00 sec)

MySQL查询优化器不会指定顺序，而是选择最适合查询的索引。

• 表中的每一列都是单独索引的
• 表中的每一列都是候选键
  *k_name不是辅助索引，因为它是候选键，就像主键一样。
• 用户定义聚集索引一旦建立就不能更改行顺序

您根本无法操纵行的顺序。下面是这一点的证明：

mysql> alter table lookup order by name;
Query OK, 6 rows affected, 1 warning (0.23 sec)
Records: 6  Duplicates: 0  Warnings: 1

mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------+
| Level   | Code | Message                                                                           |
+---------+------+-----------------------------------------------------------------------------------+
| Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 'lookup' |
+---------+------+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> alter table lookup order by id;
Query OK, 6 rows affected, 1 warning (0.19 sec)
Records: 6  Duplicates: 0  Warnings: 1

mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------+
| Level   | Code | Message                                                                           |
+---------+------+-----------------------------------------------------------------------------------+
| Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 'lookup' |
+---------+------+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)

这是因为InnoDB二级索引也包含主键列，因此MySQL能够直接从二级索引中获取所有相关数据，而无需接触数据行，因此节省了磁盘IO。
参考文献：

• 覆盖指数
• Clustered and Secondary Indexes
• 次要索引
• 聚簇索引（又名按索引组织的表）

两种索引在获取查询数据方面都是同样有效的，所以我猜优化程序只是放弃了“这就行了”
添加另一个唯一索引，可能是因为它们都同样有效，一些“FindBestIndex”例程在读取最后一个索引时退出。
这也不是我所期望的行为，尽管如果我关心顺序，我会添加一个按id排序的命令，让优化器选择主键，而不是进行两次传递和排序。

我想你没有理解类型列。类型列'index'意味着一个完整的索引扫描。当这种情况下，如果'extra'列有'using index'，这意味着mysql可以从索引中获得查询所需的所有数据，而不需要求助于实际的表行。所以这里的引擎，而不是去看那些行（这通常代价很高）会使用包含查询所需的所有数据的索引。（id，在你的例子中）作为数据，也就是说，如果你在二级索引中查找一个键，你就得到了表记录的主键，因为你只是要求所有的值，这就足够迭代二级索引来得到你需要的了。
如果引擎选择遍历主键，主键会直接指向实际的表行，Mysql会尽量避免这种行为，因为这样做通常效率很低，因为行包含的数据通常比索引包含的数据多，可能需要执行更多的IO。
http://dev.mysql.com/doc/refman/5.0/en/explain-output.html