MySQL index column size too large. the maximum column size is 767 bytes问题解决

背景

项目扩展需要，公司要在另一个新的环境搭建一套DolphinScheduler环境，由我负责对这个环境的搭建，接到任务后，果断开展工作；…猛敲键盘中…
一切准备就绪后，执行DolphinScheduler安装脚本，吭哧。。，报错了。无法相信自己的眼睛，果断重新执行，哇塞，毫无意外，果断报错。。。
复现报错信息发现，在初始化DolphinScheduler mysql元数据库表报错，报错信息：index column size too large. the maximum column size is 767 bytes。一脸懵…
果断停下手头工作进行定位，保证交付…

问题原因

以前部署环境在初始化这一步，毫无问题，一马平川，今天栽倒在平川的坑洼中，需要挣扎一波。报错信息一看是是与mysql的版本有关系，果断查询业务方提供的mysql版本，结果给出MySQL5.7，到此这就问题原因出来了。
MySQL5.7的版本对索引长度默认是767字节，超出会报错，以前公司部署环境是统一给的mysql版本是MySQL8,这个问题就没有暴露出来；
题外话：MySQL5.7限制索引长度是为了提高索引的查询效率和减少索引存储的空间，毕竟大的索引key查询和维护起来开销都比较大。到MySQL8.0版本中，对索引字段长度的限制由767扩展到了3072字节。

问题解决

平躺填坑路：
网上查询资料，需要对数据库进行设置把以下两个参数设置如下：
innodb_large_prefix=on
innodb_file_format=BARRACUDA
操作如下：
查看当前数据库这两个配置
show variables like ‘innodb_file_format’;
show variables like ‘innodb_large_prefix’;

执行下面脚本将它们改成以下状态
set global innodb_large_prefix=‘on’;
set global innodb_file_format=‘Barracuda’;
查询资料显示：说再次执行sql脚本即可，果断再次执行，果然没报错，当场就想说666；

出于职业态度感觉，不放心，果断去mysql数据库查询之前初始化报错的那个元数据库的那张表，desc tablename;执行，wc，没这张表；
当场觉得庆幸，辛亏检查了一波，要不然等交付后，出问题了，要背一个大龟壳，享受万夫所指…,想想复盘问题的场景现在还后怕。

果断还原业务方的mysql全局变量修改，一招回到原点进行问题解决；
-----正确方法：
对sql脚本进行修改，在出问题的建表语句后面，添加ROW_FORMAT=DYNAMIC，更改建表的行格式，来规避MySQL5.7索引长度的问题；
样例如下：
create table XXX (…
ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

重新回到部署脚本步骤，重新执行DolphinScheduler初始化脚本，果断一把过；到此问题解决；

题外话

1. MySQL的Dynamic、Compressed行格式介绍如下：
   MySQL默认的行格式为Compressed行格式；
   对于Dynamic、Compressed行格式而言，其和compact行格式比较相似。不同的在于，对待处理行溢出的处理及策略，Dynamic、Compressed行格式会把记录中数据量过大的字段值全部存储到溢出页中，而不会在该记录的数据内容的相应字段处存储该字段值前768个字节的数据了。而compressed相比较dynamic行格式来说，前者会使用压缩算法对所有页面(自然也包括溢出页)进行压缩以减少存储占用；
2. 遇见问题不可怕，要多检查，多验证；