由于NDA，我很难提供实际样本，这也使得提交错误报告变得毫无用处。 这是一个完全正常的表，没有特色，每个 1-2 列上有 7 个简单的索引。
我遇到的问题是我必须定期在两个 Mysql 8.0.19 服务器(他们为 Docker 提供最新的 Percona 稳定版(之间传输一个表，并且每次都会在信号 11(段错误(上 mysql 崩溃。 我已经做了一年也没有问题，桌子几乎没有变化，最近开始崩溃。
我在 4 台服务器上遇到了这个问题，其中 3 台使用 Docker，一台 1 个普通的 Debian APT 软件包
我尝试过：1(我重建了整个表，以确保 IBD 文件没有内部损坏。 2(我试图将表分成多个部分，在这些情况下，段错误崩溃只发生一部分。虽然我没有时间进一步将其减少到一行。
06:55:37 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fee7cde6100
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ff03c0f4d80 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x559950e1380e]
/usr/sbin/mysqld(handle_fatal_signal+0x351) [0x55994ff2e641]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0) [0x7ff04770e0e0]
/usr/sbin/mysqld(lob::z_index_page_t::get_n_index_entries() const+0x8) [0x5599512a10f8]
/usr/sbin/mysqld(lob::z_index_page_t::import(unsigned long)+0x18) [0x5599512a1628]
/usr/sbin/mysqld(PageConverter::update_page(buf_block_t*, unsigned long&)+0x3e1) [0x559950ff8051]
/usr/sbin/mysqld(PageConverter::operator()(unsigned long, buf_block_t*)+0x322) [0x559950ff86a2]
/usr/sbin/mysqld(fil_tablespace_iterate(dict_table_t*, unsigned long, PageCallback&)+0x9ef) [0x55995122027f]
/usr/sbin/mysqld(row_import_for_mysql(dict_table_t*, dd::Table*, row_prebuilt_t*)+0xdc6) [0x559950ff9ad6]
/usr/sbin/mysqld(ha_innobase::discard_or_import_tablespace(bool, dd::Table*)+0x422) [0x559950ecf742]
/usr/sbin/mysqld(Sql_cmd_discard_import_tablespace::mysql_discard_or_import_tablespace(THD*, TABLE_LIST*)+0x1bc) [0x55994fe787cc]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x2645) [0x55994fe07b15]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*)+0x360) [0x55994fe0ae70]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1e93) [0x55994fe0d203]
/usr/sbin/mysqld(do_command(THD*)+0x168) [0x55994fe0deb8]
/usr/sbin/mysqld(+0xfcc9c8) [0x55994ff1f9c8]
/usr/sbin/mysqld(+0x23fdeb5) [0x559951350eb5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4) [0x7ff0477044a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7ff04578fd0f]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
我的主要问题：
1( 鉴于我有一个导出的 IBD 文件(使用刷新和 CFG 文件手动创建(并使用与"显示创建表"相同的语法 1：1 创建新表：有没有办法像 MyIsam 表一样访问它？
2( 鉴于MyIsam即将"弃用"，我不愿意为此目的使用它，使用它可能会容易得多。 有没有知道它还能用多久？
就像我一开始说的，我有局限性，我无法提供可重现的情况，并且找到导致这种情况的行太耗时了。
更新解压缩表解决了分段错误，我希望较大的表不会发生这种情况。 在这种情况下，我只列出了30GB的存储空间，这是一个可以接受的解决方案。
如果Mysql开发人员读到这个：blob的压缩似乎在某处有一个严重的错误。
一句话 - 不。
InnoDB 页面包含一个标头，节点 ID 在每个页面标头中编码。如果这与初始化节点时创建的主表空间中的内容不匹配，则它将无法工作。IMPORT TABLESPACE重写导入的表空间中每个页面的标头。
InnoDB根本无法满足您的要求。