使用sqlcmd导入MariaDB导出文件时提示"Killed"问题求助

1. 系统资源不足被强制终止 #

如果SQL Server运行在Linux环境，最常见的是**OOM Killer（内存不足终止器）**触发——当系统可用内存耗尽时，内核会强制杀死占用内存较多的进程（比如sqlcmd或SQL Server数据库引擎进程）。Windows环境下则可能是系统资源监视器因进程占用过高CPU/内存而终止程序。

排查方法：

• Linux：查看dmesg日志或/var/log/syslog，搜索"Out of memory"或"Killed process"关键词，确认是否是OOM Killer所为。
• Windows：打开事件查看器，检查系统日志中是否有关于进程被终止的警告或错误信息。
• 实时监控导入时的内存、CPU、磁盘IO占用情况，确认是否存在资源瓶颈。

2. SQL文件存在语法/兼容性问题 #

即使使用了--compatible=mssql参数，MariaDB与SQL Server仍存在不少语法差异，这些差异可能导致sqlcmd执行时出现致命错误，进而被终止：

• 特有的函数：比如MariaDB的GROUP_CONCAT()、UNIX_TIMESTAMP()在SQL Server中无直接对应，需替换为STRING_AGG()、DATEDIFF()等。
• 数据类型差异：如MariaDB的TEXT、BIGINT UNSIGNED在SQL Server中需调整为VARCHAR(MAX)、BIGINT（或处理无符号范围）。
• 注释/引号问题：MariaDB允许#开头的单行注释，SQL Server默认不支持；双引号在MariaDB中可用于引用标识符，SQL Server需开启QUOTED_IDENTIFIER才能识别。
• 无效语句：导出文件中可能包含MariaDB特有的命令（如SET @@SESSION.sql_mode=...），SQL Server无法解析。

排查方法：

• 截取SQL文件的前1000行左右，单独用sqlcmd导入，看是否能成功。如果成功，逐步扩大测试范围，定位到导致错误的具体语句。
• 用文本编辑器搜索文件中的MariaDB特有语法，逐一替换为SQL Server兼容写法。

3. 事务日志耗尽磁盘空间 #

默认情况下，SQL Server的完整恢复模式会记录所有事务操作。导入600MB的SQL文件时，如果整个导入作为单个大事务，事务日志会快速膨胀，若日志所在磁盘空间不足，系统会强制终止导入进程。

排查方法：

• 检查SQL Server数据库所在磁盘及事务日志文件所在磁盘的剩余空间。
• 临时将数据库恢复模式改为简单模式（导入完成后再改回），避免事务日志无限制增长：

  ALTER DATABASE MyDB SET RECOVERY SIMPLE;
  

• 修改导出的SQL文件，在每N条INSERT语句后添加COMMIT; BEGIN TRANSACTION;，拆分大事务，减少日志压力。

4. sqlcmd编码或参数问题 #

• 编码不兼容：MariaDB导出的SQL文件可能是UTF-8编码，而sqlcmd默认使用系统编码（如Windows的GBK），导致解析时出现乱码或错误，进而触发终止。
• 参数缺失：比如未指定正确的编码参数，或超时设置仍不足以完成导入。

排查方法：

• 使用file mssql3.sql（Linux）或文本编辑器查看文件编码，导入时用-f参数指定编码，例如UTF-8编码使用：

  sqlcmd -U sa -P 'NotMyRealPassword' -S localhost -i mssql3.sql -d MyDB -t 65534 -f 65001
  

• 添加-r 1参数让sqlcmd显示错误信息，-o import_log.txt将输出写入日志文件，便于排查具体错误：

  sqlcmd -U sa -P 'NotMyRealPassword' -S localhost -i mssql3.sql -d MyDB -t 65534 -r 1 -o import_log.txt
  

5. SQL Server的安全/权限限制 #

部分环境下，SQL Server的安全策略可能限制了大文件导入操作，或者sa账号的权限被限制（比如无法执行批量插入、磁盘写入权限不足等），导致进程被终止。

排查方法：

• 确认sa账号拥有目标数据库的db_owner权限，以及磁盘写入权限（针对事务日志和数据文件）。
• 检查SQL Server的错误日志（默认路径：C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\MSSQL\Log或Linux下的/var/opt/mssql/log），查看是否有相关权限或安全错误记录。

内容的提问来源于stack exchange，提问作者Cade