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 条评论
登录 后参与评论

相关文章

来自专栏跟着阿笨一起玩NET

Sql Server 2005 CLR实例

本文转载:http://www.cnblogs.com/yongfa365/archive/2010/04/26/SQL-Server-CLR.html

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

简单分析shared pool(三) (r5笔记第94天)

提到shared pool,都会不由得和sql语句的解析过程联系起来,因为shared pool所做的主要工作就是解析sql语句,生成执行计划,在之前的两篇中...

2727
来自专栏大内老A

创建代码生成器可以很简单:如何通过T4模板生成代码?[上篇]

在《基于T4的代码生成方式》中,我对T4模板的组成结构、语法,以及T4引擎的工作原理进行了大体的介绍,并且编写了一个T4模板实现了如何将一个XML转变成C#代码...

4018
来自专栏JackieZheng

Java豆瓣电影爬虫——减少与数据库交互实现批量插入

  节前一个误操作把mysql中record表和movie表都清空了,显然我是没有做什么mysql备份的。所以,索性我把所有的表数据都清空的,一夜回到解放前……...

2767
来自专栏别先生

JDBC操作数据库,第一:jsp插入mysql数据库,坎坷摸索分享

JSP连接数据库,坎坷摸索了好久,现在终于做好了,分享一下,希望对更多热爱编程学习的人有所帮助!!!谢谢  第一:首先准备的就是已经安装好Mysql,这里不做...

1967
来自专栏PingCAP的专栏

十分钟成为 Contributor 系列:重构内建函数进度报告

为了方便社区同学更好地参与 TiDB 项目,本文一方面对继上一篇文章发布后参考社区的反馈对表达式计算框架所做的修改进行详细介绍,另一方面对尚未重写的 built...

1030
来自专栏鸿的学习笔记

python源码阅读笔记之字典对象

663
来自专栏同步博客

MySQL注入与防御

  在一个应用中,数据的安全无疑是最重要的。数据的最终归宿都是数据库,因此如何保证数据库不被恶意攻击者入侵是一项重要且严肃的问题!

712
来自专栏SpringBoot 核心技术

第六章:使用QueryDSL的聚合函数

1312
来自专栏JackieZheng

把玩爬虫框架Gecco

如果你现在接到一个任务,获取某某行业下的分类。 作为一个非该领域专家,没有深厚的运营经验功底,要提供一套摆的上台面且让人信服的行业分类,恐怕不那么简单。 找不到...

4774

扫码关注云+社区