MySQL 经典案例分析:Specified key was too long

现在的时间是23:38,拖着疲惫的身躯,还是决定记录一下今天遇到的一个关于Mysql的”诡异”问题。(其实决定记录的原因:一是好久没有在KM上刷存在感了;二是星期五晚上的大好时光,竟然一晃又过去了,心中愤愤不平)

圆规正传,下面就详细的从问题的起因、发现、探索和解决,分享一下自己的心路历程。

一、 问题是这样来的

BG内部要进行数据库的容灾演习,需要模拟线上实际的环境进行测试,这就需要copy一份线上的数据库到测试库中,其实也就是重建一个线上数据库。要完成这个任务其实有N种不同的做法,但是我当时一想:“好久没有测试一下数据备份是否正常了。”就决定利用备份数据进行重建测试库,于是乎就导出了一份XXXX.sql文件,直接往测试库里面导入,由于线上库的实际数据量还不小,所以当我按完“Enter”后就决定下班回家,估计等我到家了就差不多完成了。

结果竟然出问题了,屏幕上出现:

ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes

二、 苦逼的探索

对于报错信息“ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes”,其实意思就是“索引字段长度太长,超过了767bytes”。

mysql的varchar主键只支持不超过767个字节或者768/2=384个双字节 或者767/3=255个三字节的字段 而GBK是双字节的,UTF8是三字节的。

那么问题来了,为什么线上业务库中正常的数据直接移植到另一个库,竟然会报设置表中字段不合法的错!

(1)字符集设置不同?

第一个想法是查看两个库的字符集设置是不是不一样,果然线上库的字符集character_set_database=lantin1,而测试库的字符集character_set_database= utf8。这时候,我很天真的以为可能是因为建表的时候没有指定字符集,所以在导入测试库的时候默认使用utf-8字符集,导致Specified key was too long。所以就更改了测试库中默认的字符集,但是导入数据的时候依然还是报同样的错误。而且我在建表的语句中发现了,其实原来就已经指定了字符集,都是UTF8(CHARSET=UTF8),所以字符集设置不同并不是问题的症结所在。

(2)更改索引字段长度?

定位到出错的建表语句,果然是使用UTF8字符集,而且长度是256(如下图所示)。

为了验证索引字段的字符集设置为utf8时,varchar(256)确实是超长了,做了如下的测试:

那么问题简单了,更改tagvarchar(256)为tagvarchar(255),然后再进行导入数据,竟然成功了。但是依然后两个困惑在我脑海里,

① 为什么线上库可以设置tagvarchar(256)?

② 要是tag字段刚好有256个字节的数据,那么转存的时候,数据不就丢失了?

(3)存储引擎惹的祸?

当我去检查刚刚那张被我手动修改过的表的状态时,意想不到的发现了一个问题,为什么建表的语句明明写的是“ENGINE=MYISAM”,但是导入后的表变成了“ENGINE=InnoDB”。(如下图所示)

再仔细一回想,刚刚竟然只记得索引字段长度不能超过768,但是忘了innodb和myisam的区别了。

① innodb存储引擎,多列索引的长度限制如下:

每个列的长度不能大于767 bytes;所有组成索引列的长度和不能大于3072 bytes

② myisam存储引擎,多列索引长度限制如下:

每个列的长度不能大于1000 bytes,所有组成索引列的长度和不能大于1000 bytes

原来是两张表的存储引擎不同,这样就解释了刚刚的两个疑问,但是又一个疑问就出现了,为什么建表语句中明明写的是MYISAM表,怎么导入之后就变成了INNODB。(经过对比,发现所有的MYISAM表都被转换成了INNODB表)

这个问题暂且先搁置,紧急的是要怎么规避。先分别查了下两个数据库的默认存储引擎,果然发现在线上库中default_storage_engine和storage_engine都是MYISAM,而测试库却均是INNODB。(如下图所示)

通过修改默认的存储引擎:

1)在my.cnf中的 [mysqld] 下加入default-storage-engine=INNODB ,保存(需重启)。

2)set global default_storage_engine="InnoDB"

通过这种方法终于保证了不修改源数据文件的情况下,能正确的重建线上数据至测试库,并且核对了数据和存储引擎,均与线上库一致。

(4)InnoDB存储优化选项?

问题虽然是解决了,但是难道InnoDB中单个索引字段的长度真的只能小于767?

又经过一番探索,发现在InnoDB中,可以启用启用innodb_large_prefix参数,来使得单个索引字段的长度突破767。

注意:

①启用innodb_large_prefix参数能够取消对于索引中每列长度的限制(但是无法取消对于索引总长度的限制)

②启用innodb_large_prefix必须同时指定innodb_file_format=barracuda,innodb_file_per_table=true,并且建表的时候指定表的row_format为dynamic或者compressed(mysql 5.6中row_format默认值为compact)

具体的操作如下:

① 查看innodb_large_prefix,innodb_file_format参数

mysql> show variables like 'innodb_large_prefix';

+-------------------------+---------------+

| Variable_name | Value |

+--------------------------+--------------+

| innodb_large_prefix | OFF |

+--------------------------+--------------+

② 查看mysql> show variables like 'innodb_file_format';

+-------------------------+---------------+

| Variable_name | Value |

+-------------------------+---------------+

| innodb_file_format | Antelope |

+-------------------------+---------------+

③ 建索引测试(innodb_large_prefix,innodb_file_format都为默认值的情况下)

mysql> create table test (id varchar(256),key (id));

mysql>create table test (id varchar(255),name varchar(255),name1 varchar(255),name2 varchar(255),name3 varchar(5),key (id,name,name1,name2,name3));

##索引列大于767 bytes时报错,组成索引列总长度大于3072 bytes时报错

④ 修改innodb_large_prefix,innodb_file_format参数

mysql> set global innodb_large_prefix=1;

mysql> set global innodb_file_format=BARRACUDA;

⑤ 对row_format为dynamic格式表创建索引测试

mysql>create table test(id varchar(256),key (id)) row_format=dynamic;

mysql>create table test(id varchar(255),name varchar(255),name1 varchar(255),name2 varchar(255),name3 varchar(5),key (id,name,name1,name2,name3)) row_format=dynamic;

##innodb_large_prefix=1并且innodb_file_format=BARRACUDA时,对于row_format为dynamic的表可以指定索引列长度大于767 bytes。但是索引列总长度的不能大于3072 bytes的限制仍然存在。

三、 有待深思的细节

相信大家一定还记得上面我们跳过的一个问题:为什么建表语句中明明写的是MYISAM表,怎么导入之后就变成了INNODB。于是乎我做个2组简单的测试:

① 设置数据库default_storage_engine="InnoDB",将含有InnoDB和MYISAM的库导入。

② 设置数据库default_storage_engine=”MYISAM",将含有InnoDB和MYISAM的库导入。

实验结果是,default_storage_engine设置成InnoDB时,不论建表语句指定的是InnoDB或MYISAM,最终生成的表均为InnoDB;设置成MYISAM时,最终生成的表与其建表语句中设置的一致。

这个问题暂且就当做经验来记吧,至于其中的原因估计对于我这样经验和学识不够老道的DBA来说,确实要慢慢研究和探索了。看了一看时间01:45,今天就分享到这里吧,各位晚安。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信公众号:Java团长

Java面试中常问的数据库方面问题

B+树是一个平衡的多叉树,从根节点到每个叶子节点的高度差值不超过1,而且同层级的节点间有指针相互链接,是有序的

893
来自专栏智能大石头

6,ORM组件XCode(撬动千万级数据)

有了前面的《动手》,基本上可以进行开发了。本篇我们来试试XCode的基本功功力如何,测试在单表一千万业务数据的环境下查询的速度,添删改等没什么可测试的。其实应...

1988
来自专栏逸鹏说道

SQL Server 使用全文索引进行页面搜索

全文引擎使用全文索引中的信息来编译可快速搜索表中的特定词或词组的全文查询。全文索引将有关重要的词及其位置的信息存储在数据库表的一列或多列中。全文索引是一种特殊类...

2785
来自专栏Python攻城狮

数据库 - MySQL1.MySQL内容简介2.安装管理(linux)window下安装Mysql3.数据的完整性4.脚本命令操作5.数据库查询

MySQL数据库,是当前应用非常广泛的一款关系型数据库 MySQL官网 数据库排名

1013
来自专栏Linyb极客之路

Java面试中常问的数据库方面问题

B+树是一个平衡的多叉树,从根节点到每个叶子节点的高度差值不超过1,而且同层级的节点间有指针相互链接,是有序的

913
来自专栏逸鹏说道

SQL Server 使用全文索引进行页面搜索

概述 全文引擎使用全文索引中的信息来编译可快速搜索表中的特定词或词组的全文查询。全文索引将有关重要的词及其位置的信息存储在数据库表的一列或多列中。全文索引是一...

3117
来自专栏杨建荣的学习笔记

简单分析shared pool(二) (r3笔记48天)

对于shared pool的学习,发现越尝试去了解,发现自己对它越不了解。里面的东西很杂。 自己想用几个问题来作为引子来说明更加会有条理一些。 shared ...

2834
来自专栏数据和云

一篇文章带你读懂 MySQL 和 InnoDB

原文地址 | http://draveness.me/mysql-innodb.html

1215
来自专栏Spark学习技巧

Java面试中常问的数据库方面问题

B+树是一个平衡的多叉树,从根节点到每个叶子节点的高度差值不超过1,而且同层级的节点间有指针相互链接,是有序的

982
来自专栏黑泽君的专栏

day28_Struts2综合案例

a、拷贝必要的jar包(图中黄色框框) 和 与数据库操作有关的jar包与配置文件(图中绿色框框)

511

扫码关注云+社区