MySQL加非聚簇索引造成core dump及简单分析-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

MySQL加非聚簇索引造成core dump及简单分析

简介:

本文从5.1.48下的一个bug说起。前提是新特性fast index creation.

1、现象

5.1.48 (InnoDB plugin 1.0.9)

Session1

Session2

create table tb(a int)engine=innodb;

insert into tb values(1),(2),(3),(4),(5);

Begin;

select * from tb where a=3;

a

3

alter table tb add index a(a);

select * from tb where a=3;

ERROR 2013 (HY000): Lost connection to MySQL server during query

说明:session1提示lost connection,实际上MySQL已经dump了。

2、分析

这个结果还是比较好理解的。有fast index creation,默认不需要重作表,因此没有表锁。

Session1开始于加索引之前,第一个select语句使用的是全表扫描,第二个select语句执行时,索引已经建好,所以查询时候使用索引a。这在实现上就可能触发诸多雷区(实际上概念上都已经错误,下文描述)。

在这个版本的实现中,由于新建索引导致第二次select时候使用了prebuilt-> search_tuple. 这个结构在事务开始前没有初始化,因此在尝试使用时类型判断错误直接abort(row0sel.c)

3、最新版本的实现

由于5.1.48在我们线上用的比较普遍,因此特别查了这个版本的实现和原因。在5.1最新版本中已经避免了这个问题;5.5最新版本也避免了,但有趣的是,两个版本的实现机制完全不同。

我们先列出两个版本的效果再讨论。

5.1.61的效果

5.1.61 (InnoDB plugin 1.0.17)

Session1

Session2

create table tb(a int)engine=innodb;

insert into tb values(1),(2),(3),(4),(5);

Begin;

select * from tb where a=3;

a

3

alter table tb add index a(a);

select * from tb where a=3;

ERROR 1412 (HY000): Table definition has changed, please retry transaction

5.5.19的效果

5.5.19

Session1

Session2

create table tb(a int)engine=innodb;

insert into tb values(1),(2),(3),(4),(5);

Begin;

select * from tb where a=3;

alter table tb add index a(a);

lock here

select * from tb where a=3;

a

3

可以看到,两个版本的实现方法不同。5.1里面通过判断索引生成时间与事务开始时间的差别,提示用户需要重启事务。

5.5则是作了个锁升级,锁住加索引操作。并且这个操作不影响session1的一致性读。(当然很容易想到在session1执行一个更新操作是什么效果)。

策略上5.5的实现更符合repeatable-read的概念。

4、其他

说明下,5.1的其他版本未试验。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: