MySQL · 捉虫动态 · MySQL 外键异常分析

简介: 外键约束异常现象 如下测例中,没有违反引用约束的插入失败。 create database `a-b`; use `a-b`; SET FOREIGN_KEY_CHECKS=0; create table t1(c1 int primary key, c2 int) engine=inno

外键约束异常现象

如下测例中,没有违反引用约束的插入失败。

create database `a-b`;
use `a-b`;
SET FOREIGN_KEY_CHECKS=0;
create table t1(c1 int primary key, c2 int) engine=innodb;
create table t2(c1 int primary key, c2 int) engine=innodb;
alter table t2 add  foreign key(c2)  references `a-b`.t1(c1);
SET FOREIGN_KEY_CHECKS=1;
insert into t1 values(1,1);
select * from t1;
c1      c2
1       1
select * from t2;
c1      c2
insert into t2 values(1,1);
ERROR 23000: Cannot add or update a child row: a foreign key constraint fails (`a-b`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`c2`) REFERENCES `a-b`.`t1` (`c1`))
insert into t2 values(1,1); //预期应该成功实际失败了。子表插入任何数据都会报违反引用约束。

异常分析

首先我们会检查表结构是否正常

show create table t2;
Table   Create Table
t2      CREATE TABLE `t2` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`),
  KEY `c2` (`c2`),
  CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`c2`) REFERENCES `a-b`.`t1` (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

查看 innodb_sys_foreign 表

select * from information_schema.innodb_sys_foreign where id='a@002db/t2_ibfk_1';
+-------------------+------------+----------+--------+------+
| ID                | FOR_NAME   | REF_NAME | N_COLS | TYPE |
+-------------------+------------+----------+--------+------+
| a@002db/t2_ibfk_1 | a@002db/t2 | a-b/t1   |      1 |    0 |
+-------------------+------------+----------+--------+------+

select * from information_schema.innodb_sys_tables where name='a@002db/t1';
+----------+------------+------+--------+-------+-------------+------------+---------------+
| TABLE_ID | NAME       | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE |
+----------+------------+------+--------+-------+-------------+------------+---------------+
|      530 | a@002db/t1 |    1 |      5 |   525 | Antelope    | Compact    |             0 |
+----------+------------+------+--------+-------+-------------+------------+---------------+

表结构正常,表面上看外键在系统表中元数据库信息正常。仔细比较发现 innodb_sys_foreign 的REF_NAME字段”a-b/t1”实际应为”a@002db/t2”。

MySQL内部表名和库名存储格式

MySQL 内部用 my_charset_filename 字符集来表名和库名。

以下数组定义了 my_charset_filename 字符集需要转换的字符。数组下标为 ascii 值,1代表不需要转换。可以看到字母数字和下划线等不需要转换,同时字符’-‘是需要转换的, 转换函数参见my_wc_mb_filename

static char filename_safe_char[128]=
{
  1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* ................ */
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /* ................ */
  0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, /*  !"#$%&'()*+,-./ */
  1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0, /* 0123456789:;<=>? */
  0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* @ABCDEFGHIJKLMNO */
  1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,1, /* PQRSTUVWXYZ[\]^_ */
  0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, /* `abcdefghijklmno */
  1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0, /* pqrstuvwxyz{|}~. */
};

异常分析

由上节可知,字符’-‘作为库名或表名是需要转换的。innodb_sys_foreign 中 FOR_NAME 值是转换过的,只有 REF_NAME 未转换,而系统表 innodb_sys_tables 中存储的表名是转换后的。dict_get_referenced_table 根据未转换的表名 a-b/t1 去系统表 SYS_TABLES 查找会查找不到记录。于是会导致

 foreign->referenced_table==NULL

因此对子表的任何插入都会返回错误 DB_NO_REFERENCED_ROW,如下代码

row_ins_check_foreign_constraint:

 if (check_ref) {
         check_table = foreign->referenced_table;
         check_index = foreign->referenced_index;
 } else {
         check_table = foreign->foreign_table;
         check_index = foreign->foreign_index;
 }

if (check_table == NULL
    || check_table->ibd_file_missing
    || check_index == NULL) {

        if (!srv_read_only_mode && check_ref) {
                ……
                err = DB_NO_REFERENCED_ROW;
        }

        goto exit_func;

经过进一步调试分析发现,函数innobase_get_foreign_key_info中主表的库名和表名都没有经过转换,而是直接使用系统字符集。

回过头再看看bug的触发条件:

  1. 表名或库名包含特殊字符;
  2. 此表作为引用约束的主表;
  3. 增加引用约束是设置了SET FOREIGN_KEY_CHECKS=0;

这里强调下第3条, 如果上面的测例中去掉了SET FOREIGN_KEY_CHECKS=0,那么结果 REF_NAME会正常转换

SET FOREIGN_KEY_CHECKS=1;
create table t1(c1 int primary key, c2 int) engine=innodb;
create table t2(c1 int primary key, c2 int) engine=innodb;
alter table t2 add  foreign key(c2)  references `a-b`.t1(c1);
select * from information_schema.innodb_sys_foreign where id='a@002db/t2_ibfk_1';
+-------------------+------------+------------+--------+------+
| ID                | FOR_NAME   | REF_NAME   | N_COLS | TYPE |
+-------------------+------------+------------+--------+------+
| a@002db/t2_ibfk_1 | a@002db/t2 | a@002db/t1 |      1 |    0 |
+-------------------+------------+------------+--------+------+

online DDL 与 foreign key

MySQL 5.6 online DDL 是支持建索引的。而对于建外键索引同样也是支持的,条件是SET FOREIGN_KEY_CHECKS=0。

ha_innobase::check_if_supported_inplace_alter:
 if ((ha_alter_info->handler_flags
      & Alter_inplace_info::ADD_FOREIGN_KEY)
     && prebuilt->trx->check_foreigns) {
         ha_alter_info->unsupported_reason = innobase_get_err_msg(
                 ER_ALTER_OPERATION_NOT_SUPPORTED_REASON_FK_CHECK);
         DBUG_RETURN(HA_ALTER_INPLACE_NOT_SUPPORTED);
 }

SET FOREIGN_KEY_CHECKS=0时,prebuilt->trx->check_foreigns为false。

我们再来看出问题的函数innobase_get_foreign_key_info,只有online DDL的代码路径才会调用此函数:

#0  innobase_get_foreign_key_info
#1  ha_innobase::prepare_inplace_alter_table
#2  handler::ha_prepare_inplace_alter_table
#3  mysql_inplace_alter_table
#4  mysql_alter_table
......

而非online DDL的路径如下,函数 dict_scan_id 会对表名和库名进行转换:

#0  dict_scan_id
#1  dict_scan_table_name
#2  dict_create_foreign_constraints_low
#3  dict_create_foreign_constraints
#4  row_table_add_foreign_constraints
#5  ha_innobase::create
#6  handler::ha_create
#7  ha_create_table
#8  mysql_alter_table
......

修复

bug系统中虽然没有相关的bug信息,但从MySQL 5.6.26中我们看到官方Bug#21094069已经进行了修复,在innobase_get_foreign_key_info中对库名和表名进行转换。

参考commit:1fae0d42c352908fed03e29db2b391a0d2969269

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
2月前
|
存储 消息中间件 监控
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
蒋星熠Jaxonic,数据领域技术深耕者。擅长MySQL到ClickHouse链路改造,精通实时同步、数据校验与延迟治理,致力于构建高性能、高一致性的数据架构体系。
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
|
3月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
165 3
|
2月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
507 5
|
3月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
251 6
|
3月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
172 1
|
4月前
|
存储 关系型数据库 MySQL
深入理解MySQL索引类型及其应用场景分析。
通过以上介绍可以看出各类MySQL指标各自拥有明显利弊与最佳实践情墁,在实际业务处理过程中选择正确型号极其重要以确保系统运作流畅而稳健。
198 12
|
5月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理,这两种日志机制相互配合,能够有效地提升MySQL数据库的可靠性和稳定性。
206 10
|
5月前
|
SQL 关系型数据库 MySQL
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
|
8月前
|
SQL 关系型数据库 MySQL
【MySQL】SQL分析的几种方法
以上就是SQL分析的几种方法。需要注意的是,这些方法并不是孤立的,而是相互关联的。在实际的SQL分析中,我们通常需要结合使用这些方法,才能找出最佳的优化策略。同时,SQL分析也需要对数据库管理系统,数据,业务需求有深入的理解,这需要时间和经验的积累。
310 12
|
7月前
|
缓存 JSON 关系型数据库
MySQL 查询优化分析 - 常用分析方法
本文介绍了MySQL查询优化分析的常用方法EXPLAIN、Optimizer Trace、Profiling和常用监控指标。

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多