Sublime Text 打开大 SQL 文件卡顿的根源是默认启用语法解析等后台任务，关闭语法高亮、索引、行号等五项设置并设为纯文本模式即可秒开。
Sublime Text 打开 SQL 大文件（比如几十 MB 的迁移脚本或导出 dump）卡顿，不是编辑器不行，而是它默认把 SELECT、INSERT 当成可编辑代码在全力解析——而你只是想快速翻查、搜索或局部修改。关掉语法高亮、索引、行号这些“默认服务”，它就能秒开。
立刻恢复响应：Set Syntax: Plain Text + Toggle Word Wrap
文件已卡住、光标不动、Ctrl+Shift+P 无反应？别等，直接强退重开或用命令面板中断渲染流程：
- 按
Ctrl+Shift+P→ 输入Set Syntax: Plain Text回车：立刻停掉语法解析、符号树构建、括号匹配，这是最立竿见影的一步 - 再输
Toggle Word Wrap关闭自动换行：超长 SQL 行（比如单行百万字符的 INSERT）反复计算断点会拖垮滚动性能 - 右键状态栏右下角语言名（如显示
SQL或MySQL），选Open all with current extension as… → Plain Text：防止下次同后缀文件重复加载语法 - 如果命令面板已冻结，就用终端启动：
subl --safe-mode your_script.sql，跳过所有插件和用户设置，实测 150MB SQL 文件 6 秒内可滚动
用户设置里必须加的五项硬性降级
打开 Preferences → Settings – User，在 JSON 中加入以下配置。这不是“建议”，而是针对只读查看场景的底线设置：
-
"index_files": false：禁用后台全文索引，否则打开瞬间 CPU 拉满建倒排表，尤其对无结构的 SQL dump 杀伤力最大 -
"line_numbers": false和"gutter": false：行号区重绘是卡顿常见源头，光标悬停触发折叠按钮时更明显 -
"highlight_line": false：当前行高亮纯属渲染负担，对大 SQL 文件毫无实用价值 -
"draw_white_space": "none"：跳过空格/制表符可视化，避免大量字符串切片开销
注意："large_file_size_limit": 100（单位 MB）可以设，但真正起效的是上面五项；设为 0 或负数会被 Sublime 忽略。
按文件类型精准控制：用 syntax-specific 设置
你不需要永远关掉行号——日常写 SQL 脚本时仍需高亮和跳转，但打开 202610_prod_dump.sql 这种导出文件时就得静默加载。Sublime 支持按语法类型覆盖设置：
- 先打开一个目标 SQL 文件，确认右下角显示语法为
SQL或MySQL - 执行
Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如SQL.sublime-settings） - 在里面写入：
{ "line_numbers": false, "gutter": false, "highlight_line": false, "syntax": "Packages/SQL/SQL.tmLanguage" } - 语法路径不确定？在控制台运行
view.settings().get('syntax')查看实际值
插件和外部预处理才是卡死真凶
很多插件（如 GitGutter、BracketHighlighter、SublimeLinter-sql）根本不管“大文件”概念，一加载就扫全文件跑正则、调外部命令，导致界面冻结：
- 临时验证是否插件导致：启动时加
--safe-mode参数，或在命令面板中Package Control: Disable Package逐个关闭 - 对千万行级 SQL 文件，别硬开：用命令行先筛关键段落，比如
grep "CREATE TABLE users" prod_dump.sql > users_schema.sql，再用 Sublime 打开子文件 - 拆分超大文件更可靠：用
csplit -f part_ -n 3 prod_dump.sql '/^INSERT INTO/' '{*}'按INSERT拆块，避免内存映射失败
真正容易被忽略的点是：Sublime 对大 SQL 文件的“卡”，90% 发生在加载后 2–5 秒内——那段时间它正在默默构建语法树、索引符号、检测缩进、扫描换行符。你看到的“没反应”，其实是它在后台拼命干冗余活。关掉这些，它就只是个快得离谱的文本查看器。
