VS Code 本身不连接数据库，性能瓶颈源于插件和查询行为；卡顿主因是SQLTools连接池堆积、全量查大数据、网络延迟及自动格式化；关键配置包括限制最大行数、禁用Node驱动、关闭新标签页展示结果。
VS Code 连接数据库本身不耗性能，真正吃资源的是插件和查询行为
VS Code 是编辑器，不是数据库客户端——它自己根本不“连接”数据库。所有连接动作都由扩展（如 SQLTools、Database Client 或 MySQL/MariaDB 官方扩展）完成。性能表现取决于你装了什么插件、怎么用、查什么数据。
常见卡顿/延迟场景及应对方式
卡顿通常不是 VS Code 本身的问题，而是以下几种典型组合触发：
-
SQLTools+ 大量未关闭的连接池：每个打开的 .sql 文件可能默认建一个连接，10 个标签页 = 10 个空闲连接，后端压力小，但插件解析 SQL 和渲染结果集时内存飙升 - 执行
SELECT *查百万行：插件把全部结果加载进内存再渲染表格，VS Code 主进程直接变卡，甚至无响应 - 使用
SSH 隧道或Cloud SQL 代理连远程库：网络延迟叠加插件序列化/反序列化 JSON 结果，响应明显滞后 - 启用了
auto-save+format on save的 SQL 文件：某些格式化插件（如sql-formatter）对复杂嵌套查询解析慢，保存即卡顿
比“能不能连”更关键的三个配置项
这些设置不显眼，但直接影响操作是否流畅：
-
"sqltools.maxRows"：默认常为1000或5000，建议调低到200—— 查数据先看结构和样本，真要导出再用EXPORT命令 -
"sqltools.useNodeDriver"：设为false（用 WebAssembly 驱动）可减少 Node.js 子进程开销，尤其在 M1/M2 Mac 上更稳 -
"sqltools.showQueryResultInNewTab"：关掉它，避免每次查完都新开标签页，积压太多会拖慢整个窗口响应
替代方案：什么时候该换工具
如果你频繁做这几件事，VS Code 就不是最优解：
- 需要实时看
EXPLAIN ANALYZE执行计划图形化节点 - 持续运行
pg_stat_activity或SHOW PROCESSLIST监控长事务 - 批量导入导出 >100MB 的 CSV/SQL 文件
- 调试存储过程或函数（断点、变量查看）
这时候 DBeaver（免费）、DataGrip（JetBrains）或云厂商控制台原生 SQL 编辑器反而更轻、更准、更少意外中断。VS Code 的优势始终在“写 SQL 顺手 + 贴近代码工程”，不在当专业 DBA 工具。
最容易被忽略的一点：插件更新后，~/.sqltools 目录下缓存的连接配置和历史查询可能引发兼容问题，删掉重配比硬扛卡顿更省时间。
