SQL客户端中仅桌面GUI工具（如DBeaver、DataGrip等）支持书签功能，命令行工具本身不提供；DBeaver需通过右键连接→新建SQL脚本实现自动归集，DataGrip则区分Scratch File与项目内.sql文件，二者用途及执行机制不同。
SQL 客户端不支持书签？先确认你用的是哪个工具
绝大多数命令行或轻量客户端（比如 mysql 命令行、psql）压根没有内置书签功能——这不是你操作错了，是它本来就不提供。真正支持“保存查询”且带标签/分组/搜索能力的，集中在桌面 gui 工具里：dbeaver、datagrip、tableplus、azure data studio。如果你正对着终端敲 mysql -u root -p 想找「书签」菜单，那确实找不到。
实操建议：
- 用
DBeaver：左侧「数据库导航器」→ 右键连接 → 「新建」→ 「SQL 脚本」，后缀为.sql，自动归入该连接下，可重命名、拖拽分组 - 用
DataGrip：在 «Database» 工具窗口右键连接 → «New» → «Scratch File» → 选 «SQL»，文件名即标签，支持模糊搜索 - 命令行用户别硬扛：把常用语句存成
~/sql/active_users.sql这类路径，配合cat ~/sql/active_users.sql | mysql -u app db_name快速复用
在 DBeaver 中保存 SQL 后为什么查不到历史记录？
DBeaver 的「书签」本质是普通 SQL 文件，但它默认只显示当前连接下的脚本，且不会自动索引全局路径。如果你把脚本保存在桌面或下载目录，它不会出现在导航器里——不是丢了，是没挂载到项目结构中。
常见错误现象：
- 双击打开一个
.sql文件，编辑完点保存，但刷新导航器没变化 - 在 «File» → «Open File» 打开的脚本，关闭后就彻底消失，不进任何连接节点
- 用 «SQL Editor» 标签页写完语句，直接点磁盘图标保存，路径选错导致文件脱离项目树
正确做法：
- 务必通过右键连接 → «New» → «SQL Script» 创建，这样文件自动绑定到该连接，路径由 DBeaver 管理
- 如果已有外部
.sql文件想导入：右键连接 → «Import» → «File System»，勾选 «Add to project» - 所有脚本默认保存在
~/DBeaverData/workspace6/General/Scripts/（macOS/Linux）或%USERPROFILE%\DBeaverData\workspace6\General\Scripts\（Windows），别手动删这个目录
DataGrip 的 Scratch File 和普通 .sql 文件有什么区别？
Scratch File 是 DataGrip 的轻量临时载体，不绑定数据库连接，也不参与版本控制扫描；而普通 .sql 文件（比如放在项目目录里的）会被识别为源码，支持语法检查、表名跳转、甚至部署前 diff。两者用途完全不同，混用会导致执行环境错乱。
使用场景与参数差异：
-
Scratch File：适合快速测试、临时调试、跨库比对（手动切换数据源），右上角数据源下拉框可随时切换，但不记执行上下文 - 普通
.sql文件：必须放在项目内，右键 «Run» 时自动使用文件所在目录关联的数据源，支持 «Run context configuration» 设置默认 schema、参数化变量（如:schema） - 性能影响：Scratch 文件每次执行都重新解析连接信息；普通文件若开启 «Use database connection from context»，启动更快且事务行为更稳定
如何让 SQL 书签支持变量替换和环境切换？
纯静态 SQL 文件没法适配开发/测试/生产三套环境，硬编码 WHERE tenant_id = 123 改起来费劲还容易漏。真正能落地的方案，是结合客户端能力 + 极简模板逻辑，而不是自己写 shell 封装。
实操建议：
-
DBeaver：启用 «SQL Variables»（连接配置 → «Initialization Script» 页签），定义${env}、${limit}，在脚本中写SELECT * FROM users WHERE env = '${env}' LIMIT ${limit};，执行前弹窗填值 -
DataGrip：用:my_param占位符（注意冒号开头），执行时自动唤出参数输入框；配合 «Database Tools» → «User Parameters» 可预设常用值，比如:env = 'prod' - 避免踩坑：不要在变量名里用短横线（
${api-key}不合法），也不要嵌套（${${env}_table}不支持），所有变量值都是字符串，数字需手动转义
复杂点在于：不同客户端变量语法不互通，导出的 .sql 文件一旦含变量，在其他工具里会报错或静默忽略。如果团队共用脚本，优先选 ANSI 注释式伪变量（-- @env: prod），再靠小脚本预处理，而不是依赖 IDE 特性。
