用 mysqldump 导出时无法直接替换表名前缀，推荐三种方案：1. 管道结合 sed/awk 边导出边替换（注意仅处理 create table 和 insert into 行中的反引号或无引号表名）；2. 在沙盒库中用 rename table 临时去前缀再导出，导出后立即还原；3. 用 python 的 sqlparse 库安全解析并重写 sql，避免正则误伤。
导出 sql 时用 mysqldump 替换表名前缀
直接改 mysqldump 输出不现实，它不支持运行时重写表名；但可以用管道组合 sed 或 awk 实现“边导出边替换”。注意只替换 create table 和 insert into 行里的表名，别误伤字段名或字符串内容。
- 先确认原始前缀（如
_sandbox_）和目标前缀（如空字符串或_prod_），避免替错 - 用
sed -E 's/`_sandbox_([a-zA-Z0-9_]+)`/`\1`/g'处理反引号包裹的表名，比盲目替换更安全 - 如果表名没加反引号（比如旧版导出），得额外加一条匹配无引号场景：
s/INSERT INTO _sandbox_([a-zA-Z0-9_]+)/INSERT INTO \1/g - 导出大库时，管道会增加延迟，且
sed不支持流式多行匹配——遇到带换行的INSERT可能切坏语句
用 MySQL 客户端执行前缀替换再导出
比纯文本处理更可靠：先连上沙盒库，用 SHOW TABLES 拿到所有带前缀的表，拼出 RENAME TABLE 语句临时去掉前缀，导出完再改回去。适合一次性、可控环境。
- 别在生产连接上试——
RENAME TABLE是 DDL，会锁表，沙盒里也要避开高峰 -
RENAME TABLE不支持通配符，必须显式列出每张表：RENAME TABLE _sandbox_users TO users, _sandbox_orders TO orders; - 导出后记得还原，否则下次同步或脚本执行会找不到原表名；建议把 rename 和 restore 命令写进同一脚本，用
trap保证异常时也能恢复 - 视图、存储过程里硬编码的表名不会被
RENAME影响，导出后仍含旧前缀，得单独处理
用 Python 脚本解析并重写 CREATE/INSERT 语句
当 sed 失效（比如含注释、嵌套反引号、JSON 字段值里有下划线）或需要条件替换时，正则已不够用，得用真正能 parse SQL 的方式。推荐 sqlparse 库，轻量、不依赖数据库连接。
-
sqlparse默认不验证语法，遇到非法 SQL 会静默失败，建议加if not stmt.token_first(): continue跳过空/坏语句 - 只修改
CREATE TABLE的表名和INSERT INTO后的第一个标识符，其他位置（如SELECT * FROM）按需开关 - 替换后必须调用
str(stmt)获取字符串，别直接 print token——会漏空格和换行，导致导入失败 - 对含中文或特殊字符的库名/表名，确保文件读写用
utf-8，否则sqlparse解析可能乱码
导出后导入时报 “Table doesn’t exist” 或 “Unknown database”
不是前缀没换对，而是忽略了数据库名本身也带前缀。比如沙盒库叫 sandbox_app_v2，而你只换了表名，USE sandbox_app_v2 这行还在，导致导入时试图切换到不存在的目标库。
- 检查导出文件开头是否有
USE `sandbox_app_v2`;，用sed '/^USE `/d'删掉，或替换成目标库名 - 如果目标环境库名固定（如总是
app_production），就别删，直接替换：sed 's/USE `sandbox_app_v2`/USE `app_production`/' -
mysqldump --no-create-db可跳过CREATE DATABASE和USE行，但无法控制USE是否出现，取决于源库是否为默认库 - 最稳的方式是导出时不带库上下文：
mysqldump --no-create-db --skip-triggers --compact sandbox_app_v2 > dump.sql，再手动处理
复杂点在于：表名前缀常和库名前缀、SQL 注释、触发器定义、分区表达式混在一起，单纯字符串替换极易漏或错。宁可多花十分钟写个带断点的 Python 脚本，也别信一行 sed 能通吃所有 dump 文件。
