MySQL-37:内存临时表 缺乏、安全感 2023-01-01 02:59 111阅读 0赞 #### 37.1 临时表的组织结构 #### **InnoDB引擎:** B+树方式的组织结构,前面是索引,节点是索引+数据,节点是有序的。 ![img][] **Memory引擎:** 索引是hash索引,数组以数组的方式存放,先来先插入到结尾,数组中有空洞,则下次的数据插入会补到该位置,数组中数据是无序,索引也是无序的。 ![img][img 1] 从上可见Memory引擎和InnoDB引擎的组织结构是不一样的: * Memory引擎采用数据和索引分开存放 * InnoDB引擎采用索引组织表的形式 Memory引擎和InnoDB引擎的不同点: * 数据和索引的组织方式 * 当数据出现空洞,因为是否有序决定插入数据时是否需要大变动 * 数据位置发生变化的时候,InnoDB 表只需要修改主键索引,而内存表需要修改所有索引; Memory引擎需要做范围查询的时候,它用不上索引,因为是无序的,需要走全表扫描。 #### 37.2 索引 #### 我们通过给Memory引擎下的数据添加B+数索引,可以达到目的,添加索引的效果如下: ![img][img 2] 我们通过如下语句: alter table t add index a_btree_index using btree (id); 当出现访问访问时,它会自动走B+树索引。 #### 37.3 Memory 临时表的问题 #### **锁粒度问题:** 内存表只支持表级锁,索引在事务并发的支持上会很低效,因为一旦有事务获取了该锁,就会导致整张表锁住。 **数据持久化问题:** 数据存放到内存中,如果数据库异常重启,就会导致所有的内存表清空。当数据库重启回来,他会在binlog中写入`delete from t`,以此来达到操作与记录一致的情况。 但是在两个库互为主备库的情况下,备库异常重启,binlog同步到主库,会导致主库的内存表莫名其妙的消失。 [img]: /images/20221120/671ef618d84d468abdd85280baa0e121.png [img 1]: /images/20221120/222ab2bc2c5b41d588b235db60cbcb05.png [img 2]: https://img-blog.csdnimg.cn/img_convert/dbc24d8aedb79ad01b4655fa9847060e.png
还没有评论,来说两句吧...