DataGrip：把数据库访问纳入工程项目的完整指南
数据源、SQL 编辑器与数据库连接
DataGrip 把数据库对象树、SQL 文件和查询控制台组织在同一个项目中。一个 data source 保存数据库类型、JDBC 驱动、连接参数及可见 schema；console 使用它建立会话，执行 SQL 并显示结果。先用本地 PostgreSQL 完成一次查询和回滚，再配置远程网络与生产权限，比较容易分清客户端设置与数据库行为。
安装并连接一个独立实验库
操作环境为 Ubuntu 24.04 桌面、x86-64、DataGrip（版本标识 2026.2）与 PostgreSQL 18.6。需要普通桌面用户、可用 Docker 和 OpenSSL；DataGrip 自带 JetBrains Runtime，无需另装 Java。安装、许可和启动要求以 DataGrip 安装说明 为准。以下菜单按英文界面描述，图形流程未在此环境实际点击验证。
从 官方下载页 选择 Linux x86-64 包。解压到自己的独立应用目录，运行解压目录内 bin/datagrip.sh；不要用 root 启动 IDE。首次启动按用途选择符合条款的非商业许可、已有商业许可或试用，不把商业工作误选为非商业用途。
下载 数据库准备脚本，保存为空工作目录中的 prepare.sh，阅读后执行 bash prepare.sh。脚本创建独有容器、数据卷及三个合成账号，打印实验目录；端口默认只发布在宿主 127.0.0.1:15432。端口占用时先换用 CLIENT_LAB_PORT=15433 bash prepare.sh，不停止其他服务。
新建空项目。在 Database Explorer 点击 + → Data Source → PostgreSQL，名称填 client-postgres-local-rw，Host 127.0.0.1、Port 15432、Database client_lab、User lab_writer，密码取打印目录内 secrets/writer.password。本机实验不启用 SSH/TLS；这只适用于这个回环端口，跨机连接按后文配置验证完整的 TLS。
若提示缺驱动，点击 Download missing driver files；受限网络先在 Driver 页配置受信制品来源。点击 Test Connection，进入 Schemas 只选 lab，Apply 后在数据源右键选择 New → Query Console。入口说明见 DataGrip Quick start。
在 console 逐条执行：
SELECT current_database(), current_user, current_schema();
SELECT id,status FROM lab.client_guard_lab ORDER BY id;第一条应为 client_lab / lab_writer / lab；第二条是三行，状态依次为 CREATED、PAID、CREATED。连接被拒绝先检查脚本的容器状态和发布端口；认证失败核对 writer 密码及账号，缺表则核对 database/schema。不要把 postgres 管理账号填入日常连接。
在同一 console 撤销修改，再导出查询结果
确认工具栏事务模式为 Tx:Manual，在同一个 console 中分步执行以下语句。看到 PAID 后才执行 ROLLBACK，不把整段一次运行而略过中间观察；若已有别的未提交修改，先处理它们再开始实验。
UPDATE lab.client_guard_lab SET status='PAID' WHERE id=1;
SELECT status FROM lab.client_guard_lab WHERE id=1;
ROLLBACK;
SELECT status FROM lab.client_guard_lab WHERE id=1;两次读取分别为 PAID、CREATED。练习图形事务按钮时保持 Tx:Manual，在 Data Editor 修改 id=1，先检查待提交修改和生成 SQL，再点击 Submit；随后 Roll Back 并刷新，状态应恢复。Submit 将编辑发送到数据库，Submit and Commit 会进一步提交当前事务，不能在这次撤销实验中点击后者。退出前处理所有未提交修改，按钮语义见 事务与提交模式。
重新执行三行查询，在结果工具栏选择 Export Data，extractor 选择 CSV，启用列名、编码 UTF-8，保存到实验目录的 client-result.csv。文本编辑器打开后应只有 id,status 两列及三条数据，id=1 仍为 CREATED。此操作导出当前查询结果，不选择整张数据库树做批量导出。导出说明
复制数据源为 client-postgres-local-ro，改用 lab_reader 与 secrets/reader.password，建立新 console。SELECT 应成功，UPDATE lab.client_guard_lab SET status='X' WHERE id=1; 应由 PostgreSQL 返回权限拒绝；写账号再次查询仍为 CREATED。这样同时验证客户端选对连接和服务端拒写。
实验结束先关闭连接，下载 清理脚本 到打印的 client-lab.* 目录，进入该目录执行 bash cleanup.sh，输入本次容器名确认。它只删除本次合成容器与卷；密码和导出文件核对后另行清理。脚本的合成初始化密码会进入容器环境，拥有 Docker 管理权限的人能够读取，因此它不是生产凭据部署模板。
一个可交付的数据源应先有名字，例如 orders-postgres-prod-ro。名字至少表达系统、数据库类型、环境和权限级别；描述里写 owner、申请入口、网络路径和处置窗口。密码、私钥和客户端证书私钥不进入描述，也不进入项目仓库。DataGrip 提供 Never、Until restart、For session 等密码保存策略，生产连接优先选择短生命周期选项，并让企业凭据系统负责真正的 Secret 生命周期。
DataGrip 适合已经使用 JetBrains 工具、希望让 SQL、数据源和代码项目处在同一工作上下文的团队。它不是数据库权限平台，也不是批量数据交换系统。需要中央审批、短期授权、全量审计或大规模导出时，应把这些职责交给数据库代理、身份平台和受控任务，而不是继续给 IDE 加插件。
先固定驱动，再讨论“为什么我这里能连”
DataGrip 通过驱动把编辑器动作转换成数据库协议。驱动版本会影响 TLS 参数、认证插件、时区、字符集、数组和 JSON 等类型映射。团队如果只分享 host 和 port，却让每台机器自行下载最新驱动，同一条 SQL 可能得到不同的显示、参数绑定甚至连接行为。
在官方 Data Sources and Drivers 所示入口核对 driver class、驱动文件、下载来源和高级属性。项目基线记录坐标或文件哈希，不提交未知来源的 JAR。升级先在开发环境验证握手、服务端版本识别、复杂类型、批量读取、取消查询与 Explain，再向生产只读连接放行。出现兼容性回归时，先切回已验证驱动；关闭证书校验来迁就驱动，只会把兼容性问题改造成身份验证缺口。
连接参数也要按实际路径理解。启用 DataGrip 的 SSH tunnel 后，数据库 host 从 SSH 服务端一侧解析；本机能解析内部域名，不代表跳板机能解析。官方 SSH 与 SSL 配置说明 中的 Full Verification 同时检查信任链与主机名，CA、client certificate 和 client key 的职责不同。测试时临时降低校验只能帮助定位，结论必须是在目标校验模式下连接成功。
第一次接入只选业务所需的 database 和 schema。DataGrip 会 introspect 元数据，以支持对象树、补全、导航和静态分析。把整个实例的所有 schema 都勾上，会增加客户端缓存、后台查询和数据库负载，也扩大本地暴露的元数据范围。开发者真正维护的两个 schema，应该比“全选以后省事”更接近正确答案。
对象树与服务端不一致时，不要立刻下结论说“表被删了”或“权限失效”。先看数据源是否在线、目标 schema 是否在 introspection scope，再执行身份查询并刷新对应范围。DataGrip 启动时可以先加载缓存而不建立数据库连接，因此旧对象短时间仍可见。故障记录要区分 cached metadata、一次刷新结果和直接查询系统目录的结果；这三者混在一起，会把客户端状态误判成数据库变更。
用身份查询拆掉绿色 Test Connection 的假象
Test Connection 返回成功后，不要马上双击最大的一张表。打开新的 query console，先执行目标数据库对应的身份查询。PostgreSQL 可用：
SELECT current_database(), current_schema(), current_user;
SELECT current_setting('transaction_read_only'), current_timestamp;MySQL、Oracle、SQL Server 应换成自己的方言。验收记录包括服务端地址或实例标识、当前用户、默认 database/schema、只读状态与时区。绿色提示只证明某次握手完成；上述结果才开始回答“我是谁、我在哪里、这个 session 如何工作”。
再做一个无破坏性的反向实验：复制开发数据源，把 database 或 schema 改成不存在的名称。预期应是明确的 unknown database、schema 不存在，或连接后对象范围为空。若复制的数据源仍展示旧对象，先断开并刷新 introspection，区分缓存视图与服务端事实。恢复配置后重新运行身份查询，避免留下一个名字像开发、实际连向其他环境的副本。
Read-only 选项是第二道防误触，不是授权事实。官方文档明确说明：它可以阻止 Data Editor 修改；如果驱动不支持只读状态，query console 仍可能执行修改。真正的反证必须由数据库完成。用未来将进入生产的只读角色连接开发测试库，对专用测试 schema 尝试：
CREATE TABLE readonly_probe(id integer);正确结果是服务端拒绝，且对象没有产生。若创建成功，立即清理对象并修正角色授权。随后换厂商 CLI 使用同一账号复验。只有不依赖 DataGrip 的情况下仍无法写入，才能确认只读边界在服务端成立。
Console、session 与事务：关掉标签页不是 Rollback
DataGrip 的 session 包装一条数据库连接，console 在 session 中执行 SQL。Single session mode 会让数据源和多个 console 共享同一 session，临时表与事务可跨 console 可见，但也更容易让一个窗口留下的状态影响另一个窗口。除非确有共享临时对象或连续事务的需求，不应把它当团队默认值。
事务控制有 Auto 和 Manual。Auto 会在提交本地修改时自动提交；Manual 把修改积累在事务里，由操作者明确 Commit 或 Rollback。Manual 并不自动安全：未提交事务可能持锁，误点 Commit 会把同一 session 中积累的修改一起提交。进入生产前，应在标签和状态栏确认当前 session、transaction mode、隔离级别与 pending change，而不是凭记忆判断。
查询从小范围开始。先写明确列、选择性条件和 LIMIT，再查看结果网格。Data Editor 的分页与筛选也会生成 SQL，必要时检查 SQL log，避免一次图形操作触发全表计数或大结果抓取。取消按钮只发出取消请求；服务端是否停止，要通过活动会话或监控确认。
Explain 和 Explain Analyse 不能混为一谈。普通 Explain 通常只生成计划；Analyse 会真实执行语句。对写语句、存储过程、锁定读和高成本查询，Analyse 可能改变数据或制造负载。生产慢查询分析先拿估算计划、慢日志和等待证据，确需真实执行时，放到脱敏副本或批准窗口，并显式限定参数。
项目级 data source 可以共享什么
DataGrip 允许数据源只在当前项目可见，并把部分项目设置放入 .idea。这使代码、SQL 和连接契约能一起评审，也带来一个常被忽略的问题：可共享配置可能泄露内部域名、库名、用户名、驱动路径、启动脚本与网络拓扑。
仓库只保存不可直接登录的契约，例如：
name: orders-postgres-prod-ro
owner: platform-data
route: VPN -> database proxy
database/schema: orders/reporting
tls: verify-full; CA from enterprise PKI
credential: personal short-lived role from access portal
allowed: SELECT, safe EXPLAIN
forbidden: DML, DDL, full export提交前在干净 clone 中检查 .idea 变更，确认没有 password、token、private key、真实个人用户名和未审查的 startup script。SSH 配置如果标记为项目可见，也可能进入项目目录；团队需要明确它是否可共享。最稳妥的做法是共享连接约束和申请入口，让个人凭据在运行时注入。
SQL 文件本身同样可能包含数据。排障语句要参数化，样例值使用虚构数据，避免把手机号、订单号、token 或完整连接串写入 console scratch file。query history、SQL log、最近文件和本地索引不等于正式审计，它们既可能漏记，也可能长期保存敏感信息。
导出只服务于证据，不承担数据管道
结果网格导出适合小样本核对。导出前明确列、最大行数、编码、NULL 表示、时间格式和落盘目录；导出后重新读取，核对行列与脱敏结果。文件放在受控临时目录，禁止自动同步，事件结束后清理文件、回收站、最近文件和工单附件。
如果任务需要重复导出百万行、跨库搬运、定时运行或失败重试，DataGrip 已经越过合适边界。此时应改用受审计的数据平台、数据库原生工具或服务端作业，让身份、带宽、失败恢复和保留周期可控。把 IDE 导出流程录成“标准操作”，只会把个人电脑变成没有治理的数据节点。
架构师评审的不是编辑器偏好
DataGrip 上线评审至少要回答四件事。其一，驱动和 introspection 是否可复现、是否限制范围；其二，生产身份是否个人化、短期化并由服务端最小授权；其三，data source、console、history 和项目文件的本地暴露如何处理；其四，升级、离职、事件结束时，凭据、网络入口、项目配置和许可证如何回收。
卸载之前先断开数据源，明确处理未提交事务；清除保存密码、证书副本、SSH 引用、缓存元数据、导出物和临时 SQL。再从组织账户回收许可证并撤销数据库角色、代理会话与白名单。软件卸载只是最后一步，不是退出完成的证据。