数据库建表键长度问题

今天从服务器将数据库的数据拷贝到本地，结果sql执行一直报错，总结一下遇到的几个问题：

1. sql导入时报错，日志内容记录的片段不一定是有错的那一个语句

   • 感觉很奇怪，但是确实导入时发现那个日志的定位并不准确。

   • 解决：主要是当时日志记录的错误语句我通过查询（控制台）单独执行，并没有报错

   • 因此，在数据量相对还可以接受的时候想要准确的定位，还是通过控制台执行验证吧

2. 这次导入我的主要报错信息为：

   Specified key was too long; max key length is 767 bytes
   

   通过上网搜，说是在低版本（MySQL5.7 以下）有这个限制，但是之后的版本可以设置 innodb_large_prefix=ON 来增加索引键前缀的限制到 3072 字节，且需要同时设置 innodb_file_format=Barracuda 和 ROW_FORMAT=DYNAMIC 或 ROW_FORMAT=COMPRESSED。

   我想着设置呗，结果好家伙，系统中根本找不到该系统变量

   又说是更高的版本中（我的是8.0.35）直接移除了该变量，默认就支持，我就蒙蔽了...这我还怎么排错啊

​ 好在，之前导入过很多次这个库的表结构，之前从没有遇到这个问题啊。于是我打开之前的备份文件进行逐一对比！欸之前的确实 没有问题，最后发现主要的问题在于ROW_FORMAT 这个参数，服务器上的tidb导出的值都是Compact，但是只有Dynamic才能正确导 入。

​ 于是我一键替换了所有的Compact => Dynamic，成功导入~

3. 问题解决了，但是这两个参数值到底有什么区别呢？

   在 MySQL 中，ROW_FORMAT 是用来指定行存储格式的选项，它影响数据在表空间中的存储方式，进而影响表的存储效率和查询性能。InnoDB 存储引擎提供了几种不同的行格式，其中包括 Compact、Dynamic、Redundant 和 Compressed。在 MySQL 5.7 及更高版本中，Compact 和 Dynamic 是两种常用的行格式。以下是它们的主要区别：

   1. Compact:

      • Compact 行格式是为了向后兼容而保留的，它在存储行时会将变长字段的长度信息存储在行的末尾。
      • 这种格式适用于旧版本的 MySQL，但可能不是最高效的存储方式，因为它在存储变长字段时会占用额外的空间来存储长度信息。
      • Compact 行格式不支持行格式的动态转换，这意味着一旦表被创建为 Compact 格式，就不能动态转换为其他行格式。
      • 支持的最大索引键前缀长度为 767 字节。

   2. Dynamic(InnoDB默认):

      • Dynamic 行格式是 MySQL 5.7 引入的，它提供了更灵活的存储方式，允许行中的每个列都有更多的存储空间，并且可以动态地调整。
      • 在 Dynamic 行格式中，变长字段的长度信息是存储在每个列的末尾的，这样可以减少存储长度信息所需的空间，从而提高存储效率。
      • Dynamic 行格式支持更大的索引键前缀长度，如果启用了 innodb_large_prefix 选项，可以达到 3072 字节，而 Compact 行格式则限制在 767 字节。
      • Dynamic 行格式通常更适合存储大型数据行和使用大的索引键前缀，因为它可以更有效地利用空间。

   3. REDUNDANT：

      • 这是最早的 InnoDB 行格式，主要用于与旧版本的 MySQL 兼容。它存储更多的元数据，如额外的系统信息和字段长度信息，使得每行数据占用更多的空间。REDUNDANT 行格式支持的最大索引键前缀长度为 767 字节。

   4. COMPRESSED：

      • 结合了 DYNAMIC 格式的特性，并引入了数据压缩功能，旨在进一步减少磁盘占用和提高 I/O 效率。这种格式特别适合磁盘空间较为昂贵或 I/O 速度较慢的环境。COMPRESSED 行格式也支持索引键前缀长度为 3072 字节。

至于内部具体的细节我就不深究了，这就涉及数据库底层原理了，到我学习完OB之后看看是否能够理解