导出文件名必须含时间戳和数据库名，不可用backup.sql等通用名；应手动重命名或用mysqldump命令生成规范文件名，且需确认左侧高亮库名、禁用快速导出多库混包，并检查SQL文件头尾FOREIGN_KEY_CHECKS开关。
导出文件名必须含时间戳和数据库名，不能只叫 backup.sql
phpMyAdmin 本身不提供自定义文件名模板功能，backup.sql 这类通用名是它默认 fallback 的命名方式——但实际使用中极易覆盖、无法回溯、CI 流程里也找不到关联依据。你看到的文件名，本质是浏览器根据响应头 Content-Disposition: attachment; filename="backup.sql" 决定的，phpMyAdmin 后端没做动态拼接。
真正可控的命名方式只有两条路：
- 手动在下载弹窗里重命名：点击“执行”后，浏览器弹出保存对话框时，直接输入类似
myapp_production_202609141404.sql（年月日时分） - 用脚本+命令行兜底：如果要自动化，别依赖 phpMyAdmin 界面，改用
mysqldump -u user -p database_name > myapp_production_$(date +%Y%m%d%H%M).sql
注意：文件名里别用中文、空格或冒号（:），某些 CI 工具或容器内 shell 解析路径会失败；Git commit hash 可以加在后面，比如 myapp_production_202609141404_abc1234.sql，但得靠你自己拼，phpMyAdmin 不生成。
导出前必须确认左侧高亮的才是真实数据库名
很多人导出后发现文件名对了，但内容错库了——根源是 phpMyAdmin 左侧导航栏里高亮的那个库名，才是当前上下文生效的库。你点的是 information_schema 或 mysql 系统库，却以为自己在导 myapp，结果导出的全是权限表或视图定义。
立即学习“PHP免费学习笔记（深入）”；
操作时盯住三点：
- 左侧列表中，目标库名背景色明显加深（通常是蓝灰底），不是文字加粗或图标变化
- 顶部面包屑显示路径如
phpMyAdmin → myapp → 导出，中间那个才是当前库 - 导出页顶部大字显示 “导出数据库
myapp”，这个值不可信——它可能缓存或继承上一次操作，以左侧高亮为准
多 schema 场景下不能用“快速导出”，否则文件名再规范也没用
如果你的 MySQL 实例里有多个业务库（比如 myapp、analytics、logs），而你误点了“快速导出”，phpMyAdmin 默认会把所有被勾选的库一起打包进一个 SQL 文件，文件名还是按主库命的（比如 myapp_20260914.sql），但里面混着三个库的结构和数据。
后果很直接：
- 导入时必须先建好全部目标库，否则
CREATE TABLE analytics.users会报错 Unknown database - 版本控制里一个文件对应多个逻辑库，语义混乱，diff 失效
- 想只恢复
myapp，还得手动切分 SQL，容易漏掉SET FOREIGN_KEY_CHECKS=0等关键头尾
正确做法是：进“自定义”导出 → 展开“导出方法”→ 取消“全选”，只勾你要的那个库 → 每个库单独导出、单独命名。
导出后第一件事：用文本编辑器打开，搜前 20 行有没有 SET FOREIGN_KEY_CHECKS=0
这个语句不是装饰，是导入能否成功的关键开关。phpMyAdmin 默认会加，但某些定制版、Docker 镜像或旧配置可能漏掉。一旦缺失，导入中途遇到外键依赖就卡住，报错 Cannot add or update a child row: a foreign key constraint fails。
检查方法很简单：
- 用 VS Code / Notepad++ 打开刚导出的
myapp_production_202609141404.sql - Ctrl+F 搜
FOREIGN_KEY_CHECKS，确认开头有SET FOREIGN_KEY_CHECKS=0; - 再搜结尾有没有对应的
SET FOREIGN_KEY_CHECKS=1;（虽然不严格必需，但配对更稳妥）
这步看似琐碎，却是很多“明明导出了却导不回去”问题的最终答案——名字再规范、编码再对，缺了这一行，整个文件就等于废片。
