source是mysql客户端内置命令，路径须相对于启动时的工作目录，不支持变量或通配符；大文件需调高max_allowed_packet等参数；遇错默认中断，可用–force忽略；生产环境应加drop if exists和禁用外键检查。
mysql命令行里SOURCE命令不认路径？
直接写 SOURCE 加相对路径经常失败，不是报错“File not found”，就是提示“Cannot execute this command inside stored procedure”，根本原因是：SOURCE 是 mysql 客户端的内置命令，不是 SQL 语句，它只在交互式命令行里生效，且路径是相对于你启动 mysql 时所在的**当前工作目录**，不是相对于数据库目录，也不是相对于脚本所在位置。
- 必须先用
cd切到 SQL 文件所在目录，再启动mysql -u root -p，否则SOURCE ./init.sql会找错地方 - 绝对路径可以，但 windows 下要用正斜杠或双反斜杠：
SOURCE C:/data/init.sql或SOURCE C:datainit.sql，单反斜杠会被当成转义符处理 -
SOURCE不支持变量、拼接路径或通配符，SOURCE *.sql会直接报错
导入大文件卡住或中断？
默认 mysql 客户端有 max_allowed_packet 和网络超时限制，遇到几百 MB 的 SQL 文件，常表现为执行几秒后静默退出、没报错但数据没全进、或者报 Packets larger than max_allowed_packet are not allowed。
- 启动时加参数绕过限制：
mysql -u root -p --max_allowed_packet=512M --net_read_timeout=3600 --net_write_timeout=3600 - 如果脚本里含大量
INSERT INTO ... VALUES (...),(...),(...)单条多值插入，比逐条插入快得多；但若每行一个 INSERT，导入速度会极慢，建议提前用 sed/awk 合并 - 避免在脚本开头写
SET autocommit = 0却忘了结尾COMMIT，会导致事务一直挂着，连接被占、磁盘空间暴涨
脚本执行一半报错就停了，怎么继续？
SOURCE 遇到任何 SQL 错误（比如重复建表、字段不存在、外键冲突）会立即中止，不会跳过错误继续往下跑。这不是 bug，是它的设计行为——它本质是把文件内容一行行喂给服务器执行，出错即停。
- 加
--force参数可让 mysql 忽略错误继续执行：mysql -u root -p --force ，但要注意：这会掩盖真实问题，比如表结构没创建成功，后面 INSERT 就全丢数据 - 更稳妥的做法是先用
mysql -u root -p -e "source init.sql" 2>&1 | grep -E "(Error|Warning)"快速扫一遍错误点 - 生产环境强烈建议脚本开头加
DROP table IF EXISTS和SET FOREIGN_KEY_CHECKS = 0，结尾再开回来，避免外键和残留表干扰
为什么用SOURCE不如mysql -e重定向？
很多人习惯 mysql -u root -p db_name ，这其实是 shell 重定向，和 <code>SOURCE 完全是两套机制：前者由 shell 把文件内容作为标准输入传给 mysql 客户端，后者是客户端自己读文件解析执行。区别在于——SOURCE 能识别 mysql 特有语法如 DELIMITER，而重定向方式在遇到存储过程定义时大概率报错。
- 含
CREATE PROCEDURE、DELIMITER $$的脚本，必须用SOURCE，不能用重定向 - 重定向方式无法控制连接参数（比如临时改
max_allowed_packet），所有参数得在命令行一次性写全 - 如果你在脚本里用了
USE db_name，用SOURCE时要确保已连上对应库，否则会报 “No database selected”；而重定向方式可以在命令行直接指定库名，更省心
实际用的时候，最麻烦的不是语法，是路径和错误恢复——文件放哪、从哪启动 mysql、出错后怎么定位第几行崩的，这些细节没对齐，十分钟能干完的事能拖一小时。