VSCode崩溃源于SQL插件依赖的Node.js数据库驱动全量加载大文件导致内存溢出，而非编辑器自身问题；应通过终端直连、禁用自动执行、分块处理、启用流式执行或调高Node内存限制来解决。
SQL 文件过大导致 VSCode 崩溃，不是语法问题，是驱动加载策略问题
VSCode 本身不执行 SQL，但当你用插件（如 vscode-sqltools、SQL Server Tools 或 Database Client）连接数据库并执行大 SQL 文件时，崩溃往往发生在「驱动进程」而非编辑器主进程。根本原因是：这些插件底层依赖 Node.js 的数据库驱动（如 mssql、pg、mysql2），而它们默认使用同步或全量加载模式读取文件内容，再传给驱动解析 —— 一个 200MB 的 .sql 文件被一次性读入内存，直接触发 Node.js 的 JavaScript heap out of memory 错误。
为什么改 files.maxMemoryForLargeFilesMB 没用
这个设置只影响 VSCode 自身的文本编辑器行为（是否启用高亮、折叠等），对插件调用的外部驱动完全无效。你看到的「内存不足」弹窗可能来自 VSCode，但实际崩溃日志里会明确出现类似：
RangeError: Maximum call stack size exceeded FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
这类错误说明是插件启动的 Node.js 子进程溢出了，必须从驱动层入手：
-
vscode-sqltools默认用tedious（SQL Server）或pg（PostgreSQL），它们不自动分块； -
Database Client插件在执行前会把整个文件内容作为字符串传给mysql2，后者默认不支持流式执行； - 即使你禁用了所有其他插件，只要 SQL 插件在运行，它自己的 Node 进程就独立受
--max-old-space-size限制。
绕过驱动内存限制的实操路径
别硬扛全量加载，优先走「不加载」或「分块加载」：
- 对纯 DDL/DML 脚本（无变量、无逻辑），用终端直连：比如
psql -f huge.sql或mysql -e "source /path/to/huge.sql"，完全绕过 VSCode 和插件； - 在插件配置中关闭「自动执行全文」：例如
vscode-sqltools的sqltools.executeOnFileOpen设为false，避免一打开就崩； - 手动拆分文件：用
split -l 5000 big.sql part_切成小块，再逐个执行（注意检查BEGIN TRANSACTION/COMMIT是否被切开）； - 启用插件的流式执行开关（如果支持）：
Database Clientv5.0+ 支持"databaseclient.executeInChunks": true，配合"databaseclient.chunkSize": 1000可按语句分批提交； - 强制插件使用更高内存上限：在插件启动命令中注入参数 —— 以
vscode-sqltools为例，需修改其插件主机进程的 Node 启动参数，但 VSCode 不开放该入口；更可行的是，在系统级设置环境变量VSCODE_NODE_OPTIONS="--max-old-space-size=4096"，影响所有插件子进程。
容易被忽略的关键点
SQL 文件里的注释、空行、BOM 头、长字符串字面量（比如插入百万行 JSON）会显著放大内存占用 —— 驱动解析时不会跳过它们。一个 80MB 的 .sql 文件，实际在内存中可能膨胀到 1.2GB。与其反复调大内存，不如先用 head -n 1000 huge.sql | wc -c 看前 1000 行体积，确认是否真需要全量执行；很多所谓「大 SQL」其实只是导出时没加 --skip-extended-insert，导致单条 INSERT 写了上万列 —— 这种情况，用 sed 或 Python 脚本重写成批量插入，比调内存参数管用十倍。
