技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> MySQL --> 数据库的堆表与索引组织表的数据存储格式讨论

数据库的堆表与索引组织表的数据存储格式讨论

浏览:4671次  出处信息

汪洋@tiptop(967409) 2012/8/29 21:48:48

InnoDB存储引擎为mysql数据库快速小巧这一特点做的,就是你按有序主键去查找,不要更新主键

汪洋@tiptop(967409) 2012/8/29 21:49:57

二级索引的更新,需要overflow segment的问题在rdbms都避免不了吧

文科@EC(101800844) 2012/8/29 22:03:13

不知道分形索引是如何实现的

汪洋@tiptop(967409) 2012/8/29 22:05:31
oracle数据库实现关系型数据库rdbms的来说:大 全 精

mysql数据库实现rdbms的来说: 小 轻 快

文科@EC(101800844)  20:09:17

大家怎么看 SELECT xxx FROM TABLE1 WHERE id IN(xxx, yyy, zzz…)  , IN 里面有数千个值的查询?

毛剑@金山<iammao@vip.qq.com> 2012/8/29 22:11:50

1、IOT因为是有序的,所以对IOT的频繁无序的插入操作会导致索引块的分裂,这会严重影响插入操作的性能;而堆表不存在这个问题;

2、IOT因为是有序的,所以在批量导入大量无序数据方面,IOT的速度要比堆表差很多;

3、IOT因为是有序的,所以对IOT表主键的更新涉及到可能要移动数据到另外一个块,堆表一般不存在这个问题;

4、IOT因为是有序的,所以随着数据的插入和索引块的分裂,每条记录所在的物理存储位置可能会发生变化,这样如何维护在IOT上建立的二级索引的效率就是个问题,Oracle是通过physical guess来解决的,InnoDB存储引擎是如何做的?

5、即便是对IOT中非主键的更新,也可能会导致更新后的数据要挪到overflow segment,这样实际上是发生了row chain,这会影响查询IOT中数据的速度(很显然是因为查询所需要的IO次数的增加)。

在Oracle数据库中,IOT一般适合于那些不怎么频繁更新且又需要快速按主键访问的数据库表。

1、如果表大量顺序扫描 ,heap table 就大哭了。。。,尤其经常UPDATE 主键 ,ORDER BY 之类;

2、batch insert 的时候可以优先考虑对插入结果集进行排序;

3、大量无序插入 可以 使用id 自增seq uuid 等方式顺序插入,

  那堆表鸡肋的顺序扫描依然暴露无遗;

4、你见过谁 没事 更新主键的吗?

5、 堆表 可耻的 先插入一条记录,然后另外的表大量占用PAGE 再插入一条,,堆表的  index scan 即可 大量随机IO 读heap 劣势其实很大…;哥们怎么想的。。。

毛剑@金山<iammao@vip.qq.com> 2012/8/29 22:24:54

HEAP 要依赖IAM 和PFS来 定位写入,很多问题的,经典的就是被我这样折腾过,写满第一页,再大量插入另外一个表,然后刚才哪个表的下一页就悲剧了…

建议继续学习:

  1. Oracle cluster使用场景分析    (阅读:2582)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1