Sublime Text 可高效编写 PL/pgSQL，但性能取决于逻辑合理性：避免隐式转换、循环替代集合操作、忽略事务与索引；需配置语法高亮、静态检查，并严守触发器铁律及协同调试技巧。
Sublime Text 本身不直接执行 PostgreSQL 函数或触发器，但它可以作为高效、轻量的 PL/pgSQL 编码环境——关键在于配置得当、语法准确、调试协同。真正提升数据库性能的不是编辑器，而是你写的逻辑是否合理、是否避免了隐式类型转换、是否误用循环替代集合操作、是否忽略了事务边界和索引配合。
安装 PL/pgSQL 语法高亮与智能提示
Sublime 默认不识别 plpgsql，需手动补充支持：
- 通过 Package Control 安装 “SQL” 或更精准的 “PostgreSQL Syntax” 插件（推荐后者，含 PL/pgSQL 关键字着色）
- 将文件保存为
.sql后缀后，右下角点击语法类型 → 选择 PostgreSQL/PLpgSQL，确保DECLARE、RAISE NOTICE、RETURN QUERY等被正确高亮 - 搭配 SublimeLinter + pgsql-lint（需本地安装
pgbadger或调用psql -c "EXPLAIN ..."的包装脚本），可初步检查语法错误和低效写法
编写函数时避开常见性能陷阱
PL/pgSQL 函数写得再顺滑，一旦踩中这些坑，反而拖慢查询：
-
不用 FOR 循环遍历结果集：例如
FOR r IN SELECT ... LOOP是逐行执行，应优先改写为RETURN QUERY SELECT ...让优化器全程处理 -
避免在循环内执行 SQL：如在
FOR i IN 1..100 LOOP PERFORM INSERT ...; END LOOP;应合并为单条INSERT INTO ... SELECT ... -
显式声明变量类型，别依赖 %TYPE：尤其是涉及 JSONB、ARRAY 或自定义域类型时，
%TYPE可能引入隐式转换开销；直接写my_id INT更可控 - 慎用 RAISE NOTICE/LOG：调试完务必删掉，它们会强制刷新日志缓冲区，在高频函数中显著拉低吞吐
触发器函数必须遵守的三条铁律
触发器是性能双刃剑，写错一个就可能让整张表变慢：
-
只在 NEW 或 OLD 上做必要校验：比如
BEFORE INSERT中只检查NEW.email ~* '^.+@.+\..+$'，别顺手查另一张用户表做关联验证（应走外键或应用层） -
禁止在触发器里调用非 IMMUTABLE 函数：像
CURRENT_TIMESTAMP、random()会让函数变成 VOLATILE，导致索引表达式失效、物化视图无法自动刷新 -
UPDATE 触发器返回值必须明确：若想跳过原 UPDATE，返回
NULL；若想修改数据，返回NEW；返回OLD会导致静默丢弃变更——这点极易被忽略
与 psql 协同调试的小技巧
Sublime 写完别急着粘贴进 psql，试试这些习惯：
- 在函数体开头加
RAISE NOTICE 'debug: enter, id=%', NEW.id;，执行后看 psql 终端输出，确认是否真被触发、参数是否符合预期 - 用
\set ON_ERROR_STOP on开启 psql 严格模式，避免因某个 CREATE FUNCTION 失败却继续执行后续语句 - 对复杂函数，先在 Sublime 中用
-- EXPLAIN (ANALYZE, BUFFERS)注释包裹主体 SELECT，复制到 psql 手动执行，观察实际执行计划 - 把常用模板存为 Sublime Snippet：比如
trg_before_insert自动生成标准触发器函数壳，减少手误
基本上就这些。Sublime 不是 IDE，但配好之后写 PL/pgSQL 干净利落；真正决定性能的，是你有没有把“集合思维”刻进条件判断里，而不是用游标一行行搬数据。
