FLUSH TABLES tb_user FOR EXPORT 会卡住或报错，是因为表被活跃事务、DML 或元数据锁（MDL）阻塞；需终止长事务、禁用 autocommit=0 连接并确保无未提交操作。
必须先将源表设为只读并加锁，否则 FLUSH TABLES ... FOR EXPORT 会失败，且导出的 .ibd 文件无法用于一致性恢复。
为什么 FLUSH TABLES tb_user FOR EXPORT 会卡住或报错
这个命令本质是让 InnoDB 将表的脏页刷盘、冻结写入，并生成校验用的 .cfg 文件。它要求：表不能被任何事务修改（包括隐式事务），也不能有活跃的 DML 或未提交的事务持有该表的元数据锁（MDL）。
- 常见错误现象：
ERROR 1099 (HY000): Table 'tb_user' was locked with a READ lock and can't be updated—— 实际是 MDL 冲突，不是你手动加了READ LOCK - 检查是否有长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; - 确认没人在用
mysqldump --single-transaction或其他工具连接中执行未提交操作 - 临时禁用
autocommit=0的客户端连接，或 kill 掉可疑会话：KILL <code>trx_mysql_thread_id;
ALTER TABLE ... DISCARD TABLESPACE 后目标表只剩结构，但 .ibd 导入仍失败
导入失败通常不是语法问题，而是文件状态或权限不匹配。MySQL 在 IMPORT TABLESPACE 时会严格校验 .ibd 和 .cfg 的页校验和、space_id、fil_page_type 等底层字段，任意一项不一致都会拒绝导入。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 必须确保源库与目标库的
innodb_file_per_table=ON，且表未使用系统表空间（即建表时没指定TABLESPACE = innodb_system） -
.cfg文件必须和.ibd同时拷贝，且不能用文本编辑器打开/保存——哪怕只换行也会破坏二进制结构 - 目标库执行
DISCARD后，务必确认ls -l /var/lib/mysql/db_test/tb_user.*中只剩.frm（5.7）或.sdi（8.0+），没有残留的.ibd - 权限必须由 MySQL 进程用户（如
mysql:mysql）完全拥有：chown mysql:mysql tb_user.ibd tb_user.cfg，不能仅改组
跨版本或跨平台迁移时 IMPORT TABLESPACE 报 Tablespace mismatch
表空间传输（TTS）不是“把文件扔过去就能用”的黑盒操作。InnoDB 的页格式、checksum 算法、space_id 分配逻辑在不同版本间有细微差异，尤其从 5.7 到 8.0+ 时更敏感。
- 官方明确支持的场景仅限：同版本、同
innodb_page_size、同innodb_log_file_size（非强制但建议）、同大小端架构（x86_64 → x86_64 可，ARM → x86 不行） - MySQL 8.0.23+ 引入了
innodb_directories配置，但仅用于查找路径，不解决兼容性 - 若必须跨版本，优先走
mysqldump+--no-create-info（跳过建表）+--skip-triggers组合，再手工补触发器 - 8.0 中
.frm已废弃，用.sdi存储序列化字典信息；若目标库是 8.0，而源是 5.7，.cfg无法替代.sdi，需先在目标库执行CREATE TABLE再导入
最易被忽略的一点：整个流程中，.cfg 文件的生命周期极短——它只在 FLUSH ... FOR EXPORT 后存在，且一旦执行 UNLOCK TABLES 或服务重启就自动删除。很多人拷贝完 .ibd 却忘了同步 .cfg，或者误以为目标库能自动生成，结果卡在 IMPORT 阶段报错却查不出原因。
