mysqldump 备份含空格、短横线、中文或保留字的表名时会报 error 1064，因未自动加反引号导致语法解析错误；必须手动用反引号包裹表名或通过 information_schema 生成安全命令，并验证还原过程。
mysqldump 备份时遇到表名含空格、短横线、中文或 MySQL 保留字（如 order、group）会直接报错，典型错误是：ERROR 1064 (42000) 或 Unknown column 'xxx' in 'field list' —— 实际不是列问题，而是解析器把带特殊字符的表名当成了语法碎片。必须用反引号包裹，但 mysqldump 默认不自动加。
mysqldump 对含特殊字符表名的默认行为
mysqldump 在生成 SQL 语句时，只对含关键字的标识符做反引号转义，对含空格、短横线（-）、中文、点号（.）等不处理，导致还原时语法错误。
比如表名叫 user-info 或 订单表，备份出来的 CREATE TABLE user-info 会被 MySQL 解析为 CREATE TABLE user - info，立刻触发 ERROR 1064。
- 不会报
ERROR 1054，但常被误判为列名错误（因后续查询失败时才暴露） -
--skip-quote-names会禁用所有反引号，绝对不能开 -
--quote-names（默认开启）只覆盖部分情况，不保证全覆盖
手动加反引号：备份前确认并修正表名引用
最稳妥的做法，是在备份命令中显式指定带反引号的表名，绕过 mysqldump 的自动识别缺陷：
- 导出单个特殊表：
mysqldump -u root -p `database_name` `user-info` > backup.sql - 导出多个：
mysqldump -u root -p `database_name` `user-info` `订单表` `group` > backup.sql - 注意：反引号在 shell 中需用
`（英文键盘左上角），不是单引号' - 如果表名含反引号本身（极罕见），需双写：
``，但应避免这种命名
批量处理含特殊字符的表：用 INFORMATION_SCHEMA 生成安全命令
当数据库里有几十个带短横线或中文的表时，人工加反引号易漏。可用以下 SQL 生成带转义的 mysqldump 命令：
SELECT CONCAT('mysqldump -u root -p `', table_schema, '` `', table_name, '`')
FROM information_schema.tables
WHERE table_schema = 'your_db'
AND (table_name REGEXP '[[:punct:][:space:]\u4e00-\u9fff]'
OR table_name IN ('order', 'group', 'key', 'limit'));
执行后得到一串可复制粘贴的命令。关键点：
-
REGEXP '[[:punct:][:space:]\u4e00-\u9fff]'匹配标点、空白、中文 - 额外检查常见保留字，避免仅靠正则漏掉
order这类纯字母但非法的表名 - 输出不含换行，方便逐条执行或拼成一行用
xargs
还原时仍报 Unknown column 错误？检查备份文件是否被二次破坏
即使备份正确，还原时出现 ERROR 1054 (42S22): Unknown column 'xxx' in 'field list'，大概率是备份文件被编辑器或脚本“好心”处理过：
- Windows 记事本或某些 IDE 会把反引号
`自动转成中文顿号、直角引号或删除 -
sed/awk脚本未设-r或未转义反引号，导致替换丢失 - Git 提交时启用了
core.autocrlf，间接损坏了含反引号的行尾 - 验证方法：用
hexdump -C backup.sql | grep '60'确认反引号字节60是否完整存在
实际操作中最容易忽略的，是备份后没验证还原流程——哪怕命令跑通、文件生成，只要没用 mysql -e "source backup.sql" 实际执行一次，就无法确认反引号是否真正生效。
