| 您的当前位置:首页 --> MYSQL教程 --> Innodb表select查询顺序 |
| MYSQL教程 Innodb表select查询顺序 |
| 浏览次数:856 关键词 ( ) |
| 查看使用该CPU的产品 查看CPU天梯 |
| CPU型号:Innodb表select查询顺序 |
| 主频:Ghz |
| 睿频:Ghz |
| 核心数:个 |
| 不支持超核心 |
| 制作工艺: |
| 插槽类型: |
| 功耗:0W |
| L3缓存:0MB |
| 支持最大内存: 0GB |
| CPU详细参数 |
|
今天知数堂一个学生反馈说在优化课中老师讲Innodb是以主键排序存储,读取的时间以主键为顺序读取,但发现个例外,如下: CREATE TABLE zst_t1 ( uid int(10) NOT NULL AUTO_INCREMENT, id int(11) NOT NULL, PRIMARY KEY ( uid ), KEY idx_id ( id ) ) ENGINE=InnoDB;' 写入数据: INSERT INTO zst_t1 VALUES (1,1),(12,1),(22,1),(23,1),(33,1),(2,2),(3,2),(10,2),(11,2),(4,4),(13,4),(14,4); 执行查询:
为什么这个顺序是乱的,不按顺序排列呢?难道Innodb表并不是全按主键存储? 使用innodb_ruby这个工具查看一下存储结构什么样
看样子存储还是按主键排序存储的。没毛病。 再来看一下该表的索引:
看到这里应该明白了怎么会事了吧,原来这个查询是走的索引覆盖,没有在进行回表读取原数据。另外,也在此说明,Innodb二索索引包含了主键存储。 来继续证明一下:
看到using index 吧,表示这个查询利用索引查询出来结果,不用读取原表。 那么我们给造一个通过主键读取数据操作:
总结: 这个其实就是一个索引包含的查询案例。 如果静下来思考一下,也许很快就明白了。也不用这样去查问题。 技术在于折腾,多搞搞就明白了:)。 |
| 下一个产品 SQL计算timestamp的差值的方法 上一个产品 centos 6下安装innodb_ruby |