Description:
When an InnoDB table with an FTS index is exported and imported using
ALTER TABLE table DISCARD/IMPORT TABLESPACE
The index is not re-created on the IMPORT query, hence it's corrupted:
mysql > check table opening_lines;
+-------------------+-------+----------+------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------------+-------+----------+------------------------------------------+
| db2.opening_lines | check | Warning | InnoDB: Index idx is marked as corrupted |
| db2.opening_lines | check | error | Corrupt |
+-------------------+-------+----------+------------------------------------------+
2 rows in set (0.08 sec)
A regular noop-ALTER or OPTIMIZE will fix that, but for big tables, we would want to avoid rebuilding the whole table.
So, to just recreate the full text index alone, we'd expect the innodb_optimize_fulltext_only would help. Unfortunately, OPTIMIZE TABLE crashes the instance when this approach is attempted.
How to repeat:
Create a table with FTS, like:
CREATE TABLE opening_lines (
id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
opening_line TEXT(500),
author VARCHAR(200),
title VARCHAR(200),
FULLTEXT idx (opening_line)
) ENGINE=InnoDB;
insert into opening_lines set opening_line=UUID();
Then export its table space with:
flush tables opening_lines for export;
and backup the .ibd and .cfg files.
Then, try to import the table into another database:
CREATE TABLE opening_lines...
ALTER TABLE opening_lines DISCARD TABLESPACE;
-- copy .ibd and .cfg files to the database folder
ALTER TABLE opening_lines IMPORT TABLESPACE;
The import works, but there is a warning:
mysql > show warnings;
+---------+------+----------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------------------------------+
| Warning | 1817 | InnoDB: Index corrupt: Index idx not found or corrupt, you should recreate this index. |
+---------+------+----------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
We can read from the table, but the FTS index does not exist, and reports as corrupted.
To avoid a full table rebuild, we try this, in order to re-create the FTS index alone:
SET GLOBAL innodb_optimize_fulltext_only=ON;
OPTIMIZE TABLE opening_lines;
Unfortunately, it crashes:
2026-03-04T11:35:09.283194Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: pars0pars.cc:734:sym_node->table != nullptr thread 139721061754560
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.4/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2026-03-04T11:35:09Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=a22afa1f464d3d259376cee7b468ee6dec69ebbc
Thread pointer: 0x7f12f8000fd0
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 = 7f135840dba0 thread_stack 0x100000
#0 0x10643b6 print_fatal_signal at mysql-8.4.8/sql/signal_handler.cc:319
#1 0x10647ff _Z15my_server_abortv at mysql-8.4.8/sql/signal_handler.cc:447
#2 0x21d2279 _Z8my_abortv at mysql-8.4.8/mysys/my_init.cc:267
#3 0x2414df6 _Z23ut_dbg_assertion_failedPKcS0_m at mysql-8.4.8/storage/innobase/ut/ut0dbg.cc:100
#4 0x2341193 pars_retrieve_table_def at mysql-8.4.8/storage/innobase/pars/pars0pars.cc:734
#5 0x2341193 pars_retrieve_table_def at mysql-8.4.8/storage/innobase/pars/pars0pars.cc:712
#6 0x23413d3 pars_retrieve_table_list_defs at mysql-8.4.8/storage/innobase/pars/pars0pars.cc:750
#7 0x23413d3 _Z21pars_select_statementP10sel_node_tP10sym_node_tPvP15pars_res_word_tS5_P12order_node_t at mysql-8.4.8/storage/innobase/pars/pars0pars.cc:860
#8 0x25e6d1a _Z7yyparsev at ./obj/storage/innobase/pars0grm.y:319
#9 0x233fbbd _Z8pars_sqlP11pars_info_tPKc at mysql-8.4.8/storage/innobase/pars/pars0pars.cc:1708
#10 0x25bc8dd _Z13fts_parse_sqlP11fts_table_tP11pars_info_tPKc at mysql-8.4.8/storage/innobase/fts/fts0sql.cc:233
#11 0x25a9334 fts_cmp_set_sync_doc_id at mysql-8.4.8/storage/innobase/fts/fts0fts.cc:2857
#12 0x25a973a fts_sync_commit at mysql-8.4.8/storage/innobase/fts/fts0fts.cc:4292
#13 0x25aa107 fts_sync at mysql-8.4.8/storage/innobase/fts/fts0fts.cc:4464
#14 0x224217d _ZN11ha_innobase8optimizeEP3THDP12HA_CHECK_OPT at mysql-8.4.8/storage/innobase/handler/ha_innodb.cc:18372
#15 0x1405c0e mysql_admin_table at mysql-8.4.8/sql/sql_admin.cc:1158
#16 0x1406b31 _ZN22Sql_cmd_optimize_table7executeEP3THD at mysql-8.4.8/sql/sql_admin.cc:1935
#17 0xee5bd0 _Z21mysql_execute_commandP3THDb at mysql-8.4.8/sql/sql_parse.cc:4739
#18 0xee9d0f _Z20dispatch_sql_commandP3THDP12Parser_state at mysql-8.4.8/sql/sql_parse.cc:5406
#19 0xeec764 _Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command at mysql-8.4.8/sql/sql_parse.cc:2136
#20 0xeed405 _Z10do_commandP3THD at mysql-8.4.8/sql/sql_parse.cc:1465
#21 0x105402f handle_connection at mysql-8.4.8/sql/conn_handler/connection_handler_per_thread.cc:304
#22 0x28e97d4 pfs_spawn_thread at mysql-8.4.8/storage/perfschema/pfs.cc:3061
#23 0x7f1386e9caa3 start_thread at ./nptl/pthread_create.c:447
#24 0x7f1386f29c6b clone3 at sysdeps/unix/sysv/linux/x86_64/clone3.S:78
#25 0xffffffffffffffff <unknown>
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f12f80e2b70): OPTIMIZE TABLE opening_lines
Connection ID (thread ID): 8
Status: NOT_KILLED
Suggested fix:
For very big tables, rebuilding the imported table is very expensive and could be avoided if we could just re-create the full-text index files instead.
It should be done during the ALTER TABLE ... IMPORT TABLESPACE stage.
Alternatively, it should be possible with the innodb_optimize_fulltext_only setting.
© 2026, Oracle Corporation and/or its affiliates