装数据库客户端这件事，很多人觉得是"点下一步"就完事的活儿，但我见过太多人卡在驱动下载不了、连接超时、结果集一打开就卡死、中文注释全变问号这几个坎上，最后又退回命令行。这篇就围绕DBeaver这个通用数据库客户端，把我这些年从安装、调参、连库、日常查询到排障的整套流程完整拆一遍。它是什么、能干什么先给个直白的定义：一个基于 Java 的跨平台数据库管理工具，支持主流关系型数据库和一部分 NoSQL，能写 SQL、看表结构、改数据、画 ER 图、做跨库数据迁移。适合刚入行的数据开发、后端、运维、测试，也适合需要偶尔查库的产品和运营。下面所有内容都是可照着复现的操作，参数、路径、报错都写清楚，收藏起来按需翻。

1. 为什么我把散落的数据库客户端统一成了它

1.1 一个很常见的场景：五个客户端同时躺在任务栏

以前接手一个稍大的系统，任务栏里常年挂着五六个图标：连 MySQL 的一个，连 PostgreSQL 的一个，连 Oracle 的又一个，做数据迁移的时候还得开着命令行的客户端。每个工具的快捷键不一样，导出 SQL 的格式不一样，看表结构的方式不一样。最要命的是切换成本——刚在 A 工具里写好的语句，换个库就得重新适应另一套补全逻辑，一天下来光是"找按钮"就耗掉不少注意力。

后来我把这些东西统一到一个客户端里，评分标准只有四条：支持的数据源够不够多、驱动管理能不能自己解决、结果集操作够不够顺、出问题的时候日志能不能看懂。DBeaver 在这四条上都没有明显短板，尤其是"一个界面管所有库"这点，对需要频繁跨库比对的人来说，省下的不是一点半点时间。

这里要说清一个认知：它不是"最快的"客户端，启动比很多轻量工具慢，内存占用也更大。它的价值在于通用性和可扩展性，用一次学习成本换掉后面所有的切换成本。如果你的日常只碰一种数据库、只做简单的增删改查，那确实没必要上它；但凡涉及到两种以上数据源、需要看执行计划、需要导出结构文档、需要跨库搬数据，它就值得花半小时配好。

1.2 它到底替你干了哪些活

把功能掰开看，日常真正高频用到的其实就这几块：

这张表建议对着自己的日常工作过一遍，哪一行你现在还在用土办法，就把对应的功能点记下来，后面章节我会挨个拆。

1.3 三个版本怎么选，别一上来就选错

官方分社区版（Community）、企业版（Enterprise）和 Lite 版。社区版免费、开源，功能覆盖 95% 的日常需求，本文所有操作都基于社区版。企业版多出来的是对特定商用数据库的支持、部分高级安全特性和技术支持服务，个人和中小团队基本用不上。Lite 版是精简过的，砍掉了一些重量级组件，启动快，但驱动和功能也少，不太适合当主力。

提示：不要为了"功能全"去下载来路不明的"绿色增强版"或第三方打包版。这类包可能被塞了额外组件，也可能版本落后好几个大版本，出了问题日志都对不上。只从官方发布页取包，这条在任何一个工具上都成立。

选版本还有一个容易忽略的点：版本号和 JDK 版本是强绑定的。较新的版本要求 Java 17 及以上，老版本可能还停在 Java 11 甚至 Java 8。如果你在一台受管控的机器上工作，系统自带的 JDK 版本动不了，那就得反过来挑一个匹配的客户端版本，而不是硬上最新版——这个坑我在后面"启动闪退"那一节会展开讲。

2. 安装前的环境盘点，这几步别跳过

2.1 JDK 到底要不要单独装

先给结论：Windows 和 macOS 的安装包通常自带运行环境，Linux 的压缩包版本才需要自己准备 JDK。但"自带"不等于"一定能用"，有几个判断方法。

第一步，看安装包类型。带installer或setup字样的包，一般都把运行环境打包进去了，装完直接能起。下载下来是一个.zip或.tar.gz的免安装包，里面只有程序本体，启动脚本会去系统里找 Java。

第二步，动手验证。Windows 上开命令行敲java -version，macOS 和 Linux 敲同样的命令。输出的版本号要满足目标客户端的最低要求。如果提示"不是内部或外部命令"，就是没配环境变量或者根本没装。

第三步，也是最容易被忽略的一步：机器上可能装了多个 JDK，客户端启动时未必用的是你想的那个。这种情况在装了各种开发环境的机器上特别常见。解决办法不是在系统环境变量里反复改，而是直接告诉客户端用哪个——打开安装目录下的dbeaver.ini，在文件最前面加两行：

-vm C:/Java/jdk-17/bin/javaw.exe

注意-vm和路径必须分成两行写，路径里尽量别有中文和空格，这行的位置必须在-vmargs之前，否则不生效。Linux 和 macOS 同理，把路径换成本机的java可执行文件绝对路径即可。

注意：路径带空格是 ini 文件解析失败的高频原因。真躲不开空格，就用 8.3 短路径，或者干脆把 JDK 挪到没有空格的目录，别在这儿跟它较劲。

2.2 安装包怎么取、怎么验

取包只有一条原则：从发布页拿，别从聚合下载站拿。聚合站的问题不是"可能有病毒"这么简单，更常见的是版本错配——页面上写的是新版本，实际给的是两年前的包，你按照新文档操作，界面上根本找不到对应菜单。

拿到包之后，做一次完整性校验。发布页一般会给出安装包的哈希值，Windows 上用certutil -hashfile 包名 SHA256，Linux 和 macOS 上用sha256sum 包名或shasum -a 256 包名，把输出和页面上的值对一下。这一步看着麻烦，但能避免"下了半天装不上，结果是包没下完整"这种低效排查。

磁盘空间也要提前看一眼。程序本体不大，但工作空间目录会随着使用不断膨胀，里面存着查询历史、脚本、执行计划缓存、结果集导出记录。用久了几个 G 很正常，常年不清理的能到十几 G。给系统盘留点余量，或者后面把工作空间挪到数据盘。

2.3 目录规划：程序目录和工作空间目录要分开想

这是我认为最值得在安装阶段就定下来的一件事。程序目录是安装位置，工作空间目录是数据位置，两者默认都在系统盘上。

• 程序目录：建议放在一个固定、路径无空格无中文的位置，比如D:/Tools/dbeaver。后面升级时覆盖这个目录就行，配置不会丢。
• 工作空间目录：Windows 默认在%APPDATA%\DBeaverData，macOS 在~/Library/DBeaverData，Linux 在~/.local/share/DBeaverData。这里面有workspace6子目录，你的所有脚本、连接配置、偏好设置都在里面。

想换位置有两种方式：启动时加-data 路径参数，或者在dbeaver.ini里配。我个人的做法是把工作空间放到一个会被定期备份的盘上，理由很实在——那些零散攒下来的 SQL 片段，价值比程序本身高得多，程序随时能重装，脚本丢了是真找不回来。

3. 各平台安装实操，跟着点就行

3.1 Windows：安装版与免安装版的选择

安装版双击运行，一路下一步。中途会问安装路径和是否创建桌面快捷方式，路径按上一节的原则选。有一个选项容易被忽略：是否安装额外的驱动组件，默认勾选的话会顺带装一批常用驱动，好处是第一次连库不用等下载，坏处是安装时间变长、体积变大。网络条件一般的话建议勾上，能省掉后面最烦的一步。

免安装版解压后直接找dbeaver.exe启动。这种方式的好处是可以放 U 盘里带走、多版本共存互不干扰；坏处是没有开始菜单项，卸载就是删目录，但删目录之前一定要确认工作空间在哪，否则脚本一起没了。

首次启动会弹一个初始化向导，问你要不要创建示例数据库。新手可以选是，会建一个内置的示例库，跟着练手不会误伤生产数据。老手直接跳过。

3.2 macOS：拖进 Applications 之后的两个坑

下载.dmg，打开后把图标拖到 Applications 里，这是标准流程。坑在后面：

第一个坑是首次打开被系统拦下，提示"无法验证开发者"。这不是包有问题，是系统的默认策略。解决办法是在"系统设置 - 隐私与安全性"里找到那条拦截记录，点"仍要打开"。不要去网上找什么"关闭系统完整性保护"的偏方，那是杀鸡用牛刀。

第二个坑是JDK 版本不匹配导致启动后立刻退出，界面上什么都不显示。macOS 上查已安装的 JDK 用/usr/libexec/java_home -V，会列出所有版本和路径。想指定某一个，编辑DBeaver.app/Contents/Eclipse/dbeaver.ini，同样是加-vm两行，指向/Library/Java/JavaVirtualMachines/.../Contents/Home/bin/java。

芯片架构也得注意。带 Apple Silicon 的机器优先用 arm64 包，用 x86 包虽然能靠转译跑，但启动和查询都会慢一截，尤其是打开大结果集的时候差别明显。

3.3 Linux：压缩包方式与包管理器方式

Linux 上分两条路。桌面发行版自带软件仓库的，直接用包管理器装最省事，缺点是仓库里的版本通常偏旧。想要新版本就用压缩包：解压到/opt下，然后建一个桌面入口文件放到~/.local/share/applications/里，内容大致是：

[Desktop Entry] Type=Application Name=DBeaver Exec=/opt/dbeaver/dbeaver Icon=/opt/dbeaver/icon.xpm Categories=Development;Database; Terminal=false

如果启动报找不到 Java，先确认java -version正常，再确认dbeaver.ini里的-vm指向正确。无图形界面的服务器上跑不起来，它是图形客户端，别指望在纯命令行环境里用，那种场景应该用原生的命令行客户端。

3.4 装完先别急着连库，把这几项调了

刚装完的默认配置是"能跑就行"的水平，稍微调一下体验差距很大。打开安装目录下的dbeaver.ini，找到-vmargs之后的部分，调整堆内存：

-vmargs -Xms512m -Xmx4096m -XX:+UseG1GC

-Xmx是最关键的参数，它决定客户端最多能用多少内存。默认值往往偏小（有些版本只有 1G 左右），打开几十万行的结果集或者同时连十几个库的时候就会频繁卡顿甚至直接崩。设成多大合适？看机器内存：16G 的机器给 4G 比较稳，8G 的机器给 2G，32G 以上的可以给到 6-8G。别贪心设成物理内存的一半以上，客户端吃满了系统会开始换页，反而更慢。

另外两个建议一起改的：在设置里把"结果集每次抓取行数"从默认值调到一个合理区间（比如 200-500），以及关掉不必要的自动刷新。这两项在"性能问题"那一节还会细说。

提示：改完 ini 必须完全退出客户端再启动，不是关窗口，是确保进程结束。Windows 上任务管理器看一眼有没有残留进程，macOS 用活动监视器确认。

4. 连上第一个库：从新建连接到驱动搞定

4.1 新建连接的完整流程

菜单里选新建连接，会列出一长串数据源类型。这里有个实用技巧：搜索框直接输数据库名，比在列表里翻快得多。选中类型后点下一步，填连接信息。

以最常见的 MySQL 为例，需要填的字段是：主机地址、端口（默认 3306）、数据库名（可以先空着，连上再选）、用户名、密码。填完别急着点完成，先点"测试连接"。测试通过再保存，这是基本习惯——先把错误暴露在测试环节，比保存之后每次打开都弹一次错要清爽。

数据库名留空的场景：你还不确定要连哪个库，或者需要跨库查。这种情况下连接树上会列出该实例下所有库，代价是元数据加载会慢一些，库特别多的实例上能明显感觉到。

保存后的连接会出现在左侧导航器里。右键能"编辑连接"、"复制连接"、"使连接失效"。复制连接这个功能在多环境切换时特别好用：生产、预发、测试三套环境参数只差一个主机名，复制两份改改就行，不用重复填。

4.2 驱动下载失败：这是最高频的拦路虎

第一次连某种数据库时，客户端需要下载对应驱动。这一步在受限网络环境下失败率极高，报错通常是下载超时、连接被重置、或者"找不到驱动文件"。

原因不复杂：驱动是从公共的 Maven 仓库拉取的，默认地址在国外，网络条件不好就超时。解决办法是换成可访问的镜像源。位置在设置的连接 - 驱动 - Maven 配置里，把仓库地址改成可用的镜像。改完重启客户端，再触发一次下载。

如果镜像也不通（比如完全隔离的内网环境），就走离线方案：在能上网的机器上，按菜单里的"驱动管理"找到对应驱动的坐标（一串类似组名:构件名:版本号的标识），手动把 jar 包下下来，然后在驱动设置里"添加文件"指向本地 jar。这个操作一次搞定，后面换机器时把整个工作空间的驱动目录拷过去就行。

注意：驱动版本要和数据库服务端版本大致匹配。用太老的驱动连新版本服务端，可能连得上但部分功能异常，比如时区、字符集、认证方式；用太新的驱动连老服务端，可能出现协议不兼容直接连不上。遇到"能 ping 通、端口通、就是连不上"，先换驱动版本试。

还有一个特殊情况：某些商业数据库的驱动因为授权原因不随包分发，第一次连接时必须手动下载，而且下载源是官方站点。这种情况没有捷径，老老实实按提示走。

4.3 SSH 隧道与 SSL：能连上的前提是路径对

很多生产库不直接暴露端口，需要经过跳板机。客户端的 SSH 隧道功能就是干这个的：在连接设置里切到 SSH 页签，填跳板机地址、端口、用户名，认证方式选密码或密钥。

这一步最容易出问题的地方是端口映射的方向搞反。要理解它的逻辑：客户端在本机随机开一个端口，把流量转发到跳板机，再由跳板机转发到目标数据库。所以配置里的"本地端口"可以留空让它自动分配，"远程主机"要填从跳板机视角看数据库的地址，而不是你本机视角的地址。这一条理解错了，就会一直卡在"连接超时"。

密钥认证的话，注意密钥文件的格式和权限。私钥文件权限过宽会被拒绝，Linux 和 macOS 上要chmod 600。带口令的私钥要在配置里填口令，别指望它自动弹框问。

SSL 相关的报错就更多了，常见的几个：

不要一遇到 SSL 报错就把加密关掉。在测试环境图省事关掉无所谓，生产环境这么做等于把传输内容明文暴露。正确做法是把服务端的 CA 证书导入客户端的信任库，这一步花十分钟，比事后解释为什么数据泄露划算得多。

4.4 连接属性里的几个关键参数

连接设置里有个"驱动属性"页签，一堆键值对。常用的几个：

• 连接超时：默认值偏短，跨网络或者经过隧道的时候容易误报超时。调到 30 秒左右比较稳。
• 字符集：连老版本数据库时经常需要显式指定，否则中文变问号。
• 时区：MySQL 系常见报错"The server time zone value is unrecognized"，加一个时区参数就好。
• 保持连接：长时间空闲后连接被服务端断开，再操作就报错。配上心跳语句（MySQL 系用/* ping */，Oracle 系用SELECT 1 FROM DUAL），让客户端定期发个空查询保活。
• 只读连接：这个强烈建议给生产库打开。打开后所有写操作在客户端层面就被拦住，能挡住手滑。

这些参数不用一次配全，遇到问题再针对性加。但只读连接建议默认给生产环境打开，这是我踩过坑之后养成的习惯。

5. 界面功能区拆解：哪些是真高频

5.1 数据库导航器：元数据都在这里

左侧的树是使用频率最高的区域。展开层级是：连接 - 库 - 模式（部分数据库有）- 表/视图/函数等。右键表能看到一堆操作，其中三个最有用：

• 查看表：直接打开数据页，默认带分页，不会一次拉全表。
• 生成 SQL - DDL：一键出建表语句，写文档、做迁移、比对结构全靠它。
• 查看 ER 图：选中一个模式右键看图表，会把该模式下所有表和外键关系画出来。表多的时候会很乱，可以在图里拖拽整理，也能只选中几张表生成局部图。

导航器上方有个过滤框，表特别多的时候直接输关键字过滤，比一层层展开快。还有个"按模式分组"的开关，多库多模式的环境下打开会清爽很多。

元数据加载是异步的，刚展开一个库的时候可能显示"正在加载"。库特别多的实例可以关掉自动加载全部元数据，改成手动刷新，能明显减少连上之后的等待时间。位置在连接设置的"实体"相关选项里。

5.2 SQL 编辑器：补全、格式化、模板

打开一个 SQL 编辑器有几种方式：工具栏新建、右键表选"生成 SQL - SELECT"、或者直接在导航器里双击某个表再切到 SQL 页签。我个人最常用的是右键表生成 SELECT，省得手敲字段名。

补全默认是按表名首字母匹配，用起来还行但有提升空间。设置里可以打开"按任意位置匹配"，输入字段名中间的一段也能匹配出来，写长表名的时候很有用。补全的候选里会带上当前连接的所有库和表，连接开得多的时候候选会很长，可以在设置里限定只从当前模式取。

格式化是另一个高频操作。快捷键一按，乱七八糟的缩进立刻规整。格式化规则可以自定义：关键字大小写、逗号放行首还是行尾、缩进几个空格。团队里如果有统一的 SQL 风格，把配置导出一份发给所有人，能省掉大量代码评审时的格式争论。

自定义模板这个功能用的人不多，但很值。比如把常用的分页查询、按时间范围统计、慢查询排查语句存成模板，输入缩写加触发键就展开。设置位置在编辑器相关的模板配置里。

5.3 数据编辑器：像改表格一样改数据

双击表打开的就是数据编辑器。几个必须知道的点：

第一，默认是分页加载，不是全表。页大小可以调，但不要为了"看全"设成很大的值，几百万行的表会把内存吃干净。真要看全量，用导出或者写带条件的查询。

第二，改数据默认不会立刻提交。编辑单元格后值会变黄，表示未提交状态。这时候可以点提交或者回滚。这个机制很安全，但新手容易误以为已经改完了，关掉页面才发现改动丢了。工具栏上的自动提交开关要留意状态。

第三，按列过滤和按值过滤是两个功能。列过滤是把某一列隐藏掉，结果集宽的时候用；按值过滤是加 where 条件，等价于重新查。有个很实用的小技巧：在某一行上右键选"按该值过滤"，会自动生成等值条件并重新查询，排查具体某条记录时特别快。

第四，大字段（大文本、二进制）双击会打开独立查看器，不会撑爆表格。

5.4 结果集导出与执行计划

查询结果可以导出成 CSV、Excel、JSON、SQL 插入语句等多种格式。导出时有几个选项值得注意：

• 只导出当前结果集还是重新执行查询并导出全量。前者快但你看到多少导多少，后者慢但完整。
• 编码。导出中文内容给别的系统用时，编码选错就是一堆乱码，默认值不一定合适，导出后打开确认一眼。
• 大结果集的流式导出。几百万行导出成 Excel 会直接崩，这种量级应该导 CSV 并考虑分批。

执行计划（Explain Plan）在调优时是刚需。选中一条语句，点执行计划的按钮，会展示访问路径、扫描行数、是否走索引。不同数据库的展示形式不一样，但核心信息是通的：看有没有全表扫描、看预估行数和实际行数差多少。差得离谱通常意味着统计信息过期，需要更新统计信息再分析。

6. 提效配置与常用快捷键

6.1 值得花十分钟改掉的默认设置

装完之后我第一件事是改这几项，按收益排序：

1. 编辑器字体和字号。默认字体看多字节字符容易糊，换成等宽字体、字号上调一档，长时间写 SQL 眼睛舒服很多。
2. 结果集抓取行数。默认值一般偏小，翻页频繁；调到 200-500 之间比较平衡。
3. 自动提交关闭。默认可能开着，一不小心 delete 就生效了。关掉之后所有写操作都要手动提交，多一道确认。
4. 打开"确认危险操作"。删除、更新不带条件的语句执行前弹确认，这种"烦人"的提示救过我至少两次。
5. 查询超时。给一个上限，避免一条写错的语句把连接占死。
6. 会话时区与字符集。在连接级别固定下来，省得每次新建会话都要处理。
7. 高亮当前行、显示行号。小功能，但定位错误行的时候能快几秒。
8. 结果集默认只读。默认行为改成打开表不加锁，减少对生产的干扰。
9. 保存时自动备份脚本。编辑器里的历史版本功能打开，误删脚本还能翻回来。
10. 关闭不需要的自动更新检查。网络受限环境下这个检查会拖慢启动。

这十项改完，日常使用的顺滑度会有明显提升。设置保存在工作空间里，换机器时把工作空间拷过去，配置一起带走了。

6.2 快捷键速查

不同平台的修饰键不一样，Windows 和 Linux 用 Ctrl，macOS 用 Command。下面按 Windows 写：

快捷键可以自定义。建议把"执行当前语句"和"执行整个脚本"这两个的区分记牢——很多人误执行了整个脚本，把几百条语句一口气跑完，起因就是没分清这两个键。执行前看一眼状态栏，它会告诉你将执行几条语句。

6.3 跨库搬数据：传输功能实操

这是我认为它最值钱的功能之一。场景：把一个库里的若干张表搬到另一个库，或者从生产导一份脱敏数据到测试环境。

操作路径是工具栏的"数据传输"。配置分三块：

源：选连接、选库、勾选要传的表。可以全选，也可以只选几张。

目标：选另一个连接和库。目标表已存在时有几种策略：直接插入、清空后插入、删除重建、跳过。测试环境一般用"删除重建"，保证结构一致；增量同步用"直接插入"，但要小心主键冲突。

选项：这里是重点。可以配置批量提交大小、是否禁用外键约束、是否保留自增主键、失败时是否继续。禁用外键约束这一项在跨表传输时几乎是必须的，否则子表先于父表插入会直接失败。批量大小调到 1000 左右在多数场景下比较平衡，太小了慢，太大了单条事务过重。

传输过程中看得到进度和日志，出错的表会单独标出来，可以只重试失败的部分。这个大表传输时特别有用——几百万行的表搬到一半断了，不用从头再来。

注意：跨库传输会真的写数据，操作前确认目标连接不是生产库。这个提醒看着多余，但每年都有人手滑。

7. 问题排查实录：这些坑我都踩过

7.1 启动类问题

双击没反应或者一闪而过。先看日志。日志文件在工作空间目录下的.metadata里，找log结尾的文件。大概率能看到 Java 版本相关的报错。如果是版本不匹配，按前面说的在 ini 里指定-vm。如果日志里报的是 ini 语法错误，检查-vm那两行是不是写在了-vmargs后面，或者路径里有空格。

启动后界面卡在加载中。常见原因是工作空间损坏。备份工作空间目录，然后删掉里面的配置缓存文件重启，客户端会重建。如果重建后正常，说明是缓存问题；如果还是卡，试试加启动参数指定一个全新的临时工作空间，能区分是程序问题还是数据问题。

内存溢出，报 OutOfMemory。调-Xmx。但要注意，有些情况不是内存不够，而是某条查询返回了超大结果集。调内存治标，正确的做法是给查询加 limit 或者分批处理。

7.2 连接类问题

连接失败的排查顺序我固定成这么几步，基本能覆盖九成情况：

1. 网络是否通。在同机器上用命令行工具或 ping 确认主机可达、端口开放。注意很多数据库不响应 ping，用 telnet 类的方式测端口更准。
2. 认证是否过。用户名密码错误有明确提示，但要注意有些数据库区分来源主机，账号是对的但来源 IP 不在允许列表里，报错会很含糊。
3. 驱动是否对。换驱动版本试，这是见效最快的排查手段。
4. 参数是否缺。时区、字符集、SSL、公钥检索，四个高频参数对照前面那张表加。
5. 服务端限制。连接数打满、账号被锁、防火墙策略变更，这些需要服务端配合看。

能连上但一操作就断。多半是空闲超时或者连接被中间设备回收。配心跳保活，把空闲超时时间调到合理值。

连上了但看不到表。权限问题或者模式选错了。有些数据库连上后默认不展开所有模式，需要手动在导航器里勾选显示。

7.3 性能与显示类问题

打开表要等很久。几个原因叠加：元数据自动加载、结果集太大、网络慢。对应处理：关掉自动加载、改成分页、加查询条件。大表排查时我一般直接用limit或者按主键范围切，别指望它一次捞完。

中文显示成问号或方块。分两层排查：如果数据库里的数据是好的，只是客户端显示乱码，改客户端字体和字符集设置；如果导出来的文件乱码，改导出编码；如果查询出来的值本身就是问号，那是写入环节的问题，得从连接字符集和表字符集两头查。

时间字段差几个小时。典型的时区问题。连接参数里固定时区，别依赖服务端默认值。这个问题在跨时区协作的项目里特别容易冒出来，因为开发机、测试机、生产机的系统时区可能都不一样。

浮点数精度看起来不对。客户端的显示精度和后端存储精度是两回事。看的时候调高显示精度，但要清楚这只影响展示，不改变实际值。涉及金额的字段千万别用浮点类型，这是数据库设计的问题，不是客户端的问题。

7.4 一份速查表

日常遇到的高频问题整理成表，方便对着查：

8. 我个人的几条使用心得

最后分享几个不成体系但确实管用的习惯。

连接命名一定要带环境和用途。生产-订单库-只读、测试-用户库-可写，这种命名看一眼就知道能不能碰。见过太多事故起源于"以为是测试库"，命名混乱是根因之一。颜色标记也建议用上，生产连接标红色，视觉上的警示比任何口头提醒都有效。

常用脚本别只放客户端里。客户端的工作空间会损坏、会丢、换机器不一定带走。重要脚本同时放在版本管理里，客户端里的只作为草稿区。这个习惯养成之后，我至少躲过两次"工作空间重建"带来的损失。

升级前先备份工作空间。新版本有时会做配置迁移，迁移失败就得重配所有连接。备份就是复制一个文件夹，成本极低。

别追求一次配到完美。连接参数、快捷键、模板这些，都是遇到问题再改，用得难受了再调。一开始花两小时把所有设置研究一遍，大概率记不住，还不如在真实使用中逐步打磨。我现在这套配置是两三年里慢慢改出来的，每次改一个点，改完立刻能感受到差别，这样才记得住。

遇到看不懂的报错，先看日志再说。客户端日志、数据库服务端日志、网络层日志，三处对照着看，比在搜索框里反复换关键词描述现象效率高得多。日志里那行异常堆栈，往往直接指向根因。