Oracle SQL Developer 这个工具我在好几个不同类型的项目里带人上手过从刚毕业的实习生到做了七八年运维的老手都有。有趣的是大部分人第一次打开它的反应都是这也太朴素了吧然后过两周再问他们用什么连库答案基本都变成了就用它了。官方出品、免费、跨平台、不用装驱动、自带调试器和导出工具这几点凑在一起对天天要跟 Oracle 数据库打交道的人来说就是个很难拒绝的组合。这篇东西不打算讲什么高深的东西就是把 Oracle SQL Developer 从下载到日常写 SQL、调存储过程、导数据这一整条链路捋一遍重点放在那些文档里不写、但实际操作中一定会撞上的地方。如果你是刚开始接触 Oracle 的新人照着走一遍基本能干活如果你已经在用 PL/SQL Developer 或者 Navicat也能看看有没有值得换过去的理由。1. 先搞清楚这工具到底解决什么问题1.1 它是什么以及它不是什么Oracle SQL Developer 是 Oracle 官方提供的一个免费图形化数据库开发工具本质上是一个用 Java 写的客户端通过 JDBC 连到数据库上去。它能干的事情包括写和执行 SQL、编辑和调试 PL/SQL、浏览表结构和数据、导出导入数据、比较两个库的差异、做数据建模。你可以把它理解成官方版的数据库管理界面定位和 PL/SQL Developer、Navicat、DBeaver 这一类是重合的。但它不是数据库本身也不是必须装在数据库服务器上的东西。它是一个客户端装在你自己电脑上通过网络连到远端的库就行。这一点很多人第一次接触时会搞混我见过有人专门跑去问DBA 能不能给我装一下 SQL Developer其实完全没必要自己本地装就是了。另外它也不是万能的。做大规模数据迁移、性能压测、集群管理这些活它有对应模块但不强专业的事还得交给专业工具。日常开发、查数据、写存储过程、导个报表它是完全够用的。1.2 和 PL/SQL Developer、Navicat 的取舍这个问题我被问过无数次直接上表比较直观。对比项Oracle SQL DeveloperPL/SQL DeveloperNavicat for Oracle授权免费商业收费商业收费跨平台Windows / macOS / Linux 都行基本只有 WindowsWindows / macOS存储过程调试支持体验不错支持老牌强项支持但偏弱多数据库支持主要面向 Oracle也能连 MySQL 等面向 Oracle支持一大堆数据库启动速度偏慢Java 通病快较快界面观感朴素甚至有点旧老派但顺手现代好看数据导出功能全配置项多够用导出体验最好我自己的用法是长期开发、调试 PL/SQL、对比库结构用 SQL Developer偶尔连一下 MySQL 顺手看看数据用 Navicat如果所在团队全员用 PL/SQL Developer 并且已经买了授权那就没必要折腾。工具这东西团队协同的顺畅度往往比单个功能的强弱更重要。需要说明的是Navicat 连接 Oracle 需要自己下 JDBC 驱动或者用 OCI 方式配这块新手很容易卡住而 SQL Developer 自带驱动不用管这一层。1.3 哪些人适合现在就用起来三类人我建议优先考虑它。第一类是学生和刚入行的新人没有预算买商业工具SQL Developer 是唯一既能免费又能覆盖完整开发流程的选择。第二类是需要在 Linux 或 macOS 上干活的PL/SQL Developer 在这两个平台基本没法用。第三类是临时需要排查线上问题的人下载解压就能用不写注册表不留残留用完删目录走人。不适合的场景也说一句如果你的日常工作就是批量导出几十万行数据做分析或者需要频繁做复杂的 ETL那可能直接用脚本加 SQL*Loader 或者专门的 ETL 工具效率更高图形界面在超大数据量面前反而是拖累。2. 装之前先避开的几个坑2.1 JDK 版本这个坑我踩过至少三次SQL Developer 是 Java 程序它必须依赖一个本地 JDK 才能跑起来。问题就在这——不同版本的 SQL Developer 要求的 JDK 版本不一样装错了就是双击没反应或者弹一个一闪而过的黑框然后什么都没发生。我的经验是4.1.5 那个年代的老版本跑在 JDK 8 上21.2 及以前的版本基本也都能吃 JDK 8再往后的版本官方逐步抬到了 JDK 11更近的版本甚至建议 JDK 17。这个分界线具体落在哪个小版本上最靠谱的做法是打开下载页看那一行 Requires JDK x.x 的说明或者解压后看目录里的 readme。别凭记忆猜。还有一个更隐蔽的问题你可能电脑上已经装了 JDK但 SQL Developer 不认识它。这时候要去改配置文件。免安装版本在sqldeveloper/bin/sqldeveloper.conf里找到SetJavaHome这一行把后面的路径改成你的 JDK 根目录注意是 JDK 不是 JRESetJavaHome C:\Program Files\Java\jdk-11.0.20Windows 下如果用的是带安装包的版本配置文件通常在用户目录里路径大致是%APPDATA%\sqldeveloper\版本号\product.conf同样找SetJavaHome改。macOS 和 Linux 在~/.sqldeveloper/下面。注意路径里不要有中文和空格尤其是空格经常被忽略。如果你把 JDK 装在C:\Program Files下面注意这个目录名本身带空格某些老版本会因此解析失败这时候把 JDK 挪到C:\Java\jdk-11这种干净路径下最省事。2.2 免安装版本其实才是最优解官方提供两种形态带安装程序的版本和免安装的 ZIP 压缩包。我的建议是无条件选 ZIP 包。原因很简单压缩包解压就能用不需要管理员权限不往系统里写卸载信息换个版本只要解压到另一个目录想删直接删文件夹。公司在没有管理员权限的机器上这是唯一的选择。解压之后目录大概长这样顶层有一个sqldeveloper文件夹和一个sqldeveloper.exe里面还有jdev、bin、ide这些子目录。第一次启动会问你要不要导入旧版本配置全新安装就选否。启动的时候如果看到命令行窗口先弹出来再消失然后主界面起来这是正常的那个黑框是启动脚本别关它关了程序就退了。这个设计确实不太优雅习惯就好。2.3 连不上数据库先怀疑监听而不是工具新手最常见的反应是SQL Developer 有问题。实际上九成的连接失败跟工具没关系是数据库监听没起来或者网络不通或者服务名写错了。这几个概念一定要分清监听器Listener跑在数据库服务器上的一个进程默认监听 1521 端口负责接收客户端的连接请求并转给数据库实例。SID实例名一个服务器上可以跑多个实例每个有自己的 SID。服务名Service Name逻辑上的服务标识集群环境下通常一个服务名背后对应多个实例。连接的时候填 SID 还是服务名填错一个就报 ORA-12505 或者 ORA-12514。我的笨办法是先问 DBA 要连接串一般长这样jdbc:oracle:thin://10.20.30.40:1521/ORCLPDB1从里面直接抄 IP、端口和服务名别自己猜。在服务器上或者你能登录的机器上验证监听状态用lsnrctl status能看到Service xxx has 1 instance(s) ... status READY就说明监听是好的。这一步能省掉大量扯皮时间。3. 从零建一个能用的连接3.1 三种连接方式该怎么选新建连接时SQL Developer 会让你选连接类型主要有三种选择逻辑其实很清晰。基本Basic是最常用的填主机名、端口、SID 或服务名然后用户名密码。90% 的场景用这个就对了不需要在本地维护任何配置文件。TNS方式是复用本地的tnsnames.ora文件里的别名。什么时候用当你手头已经有一份配置好的tnsnames.ora里面有几十个库的别名直接选别名比自己一个个填 IP 快得多。前提是要让 SQL Developer 找到这个文件通常靠环境变量TNS_ADMIN指定目录或者放在默认路径下。手动 JDBC URL是万能兜底。直接填完整的连接串jdbc:oracle:thin:10.20.30.40:1521:ORCL jdbc:oracle:thin://10.20.30.40:1521/ORCLPDB1注意这两种写法的区别冒号加 SID 是老的写法//加斜杠加服务名是新写法。现在建的库基本都是多租户架构必须用服务名那一套用 SID 那套连 PDB 是连不上的会一直报错让你怀疑人生。这一点值得单独记一下。3.2 连接测试失败怎么办点测试按钮失败的时候错误码信息量很大我整理了一份常见对照表可以直接拿去查。错误码大概含义优先排查方向ORA-12541没有监听器服务器监听没起或端口填错ORA-12514监听不认识这个服务服务名写错或库没注册到监听ORA-12505监听不认识这个 SID把 SID 和服务名搞混了ORA-12154无法解析连接标识符TNS 别名找不到TNS_ADMIN 没配ORA-01017用户名或密码错误密码大小写、账号是否在正确的库ORA-28000账号被锁定连续输错密码导致需要 DBA 解锁ORA-28001密码已过期需要改密码注意有的库有宽限期ORA-28547连接服务器失败通常是网络管理配置问题驱动类型或连接串格式不对ORA-28547 这个错误单独说一句它出现的原因经常是有人在连接串里误加了 OCI 相关的参数或者用第三方驱动去连走了错误的协议。SQL Developer 默认用 thin 驱动把这行配置恢复干净通常就好了。3.3 密码保存和连接分组的小技巧SQL Developer 支持保存密码勾选保存密码之后下次直接连。有个细节是它会问你要不要用主密码保护如果选了每次启动要输一次主密码安全性高但麻烦。多人共用一台机器的环境建议开个人电脑无所谓。连接多了以后左侧的连接树会非常乱。这时候可以新建连接分组比如按环境分成开发测试生产三组生产环境的库我一般还会把颜色改成红色这样一眼就知道自己在连哪个库避免在错的环境里跑错语句。这个习惯救过我不止一次。还有个小功能叫连接副本可以复制一个已有连接然后改改用户名比从头填一遍快很多尤其是同一个库要切多个账号测试的时候。4. 界面里最该先摸熟的几个区域4.1 连接树与对象导航左侧那棵树是主战场。展开一个连接能看到 Tables、Views、Indexes、Packages、Procedures、Functions、Sequences、Synonyms 这些节点。日常用得最多的是 Tables。这里有个非常实用的操作点开 Tables 之后上方的过滤框可以直接输入表名模糊匹配不用在一堆表里翻。输入%ORDER%就能筛出所有带 ORDER 的表。数据库里几千张表的时候这个过滤框的利用率会非常高。右键一张表菜单里有一堆东西值得记住查看View看建表语句、约束、索引、触发器、依赖关系一个面板搞定。编辑Edit可视化的表结构编辑器改列名、加列、改类型都行改完点保存它会自动生成并执行 DDL。这个功能很方便但也危险生产库上别随便用它生成的 DDL 可能跟你想的不一样。数据Data表格形式浏览数据可以就地编辑改完点提交。同样生产库慎用。导出Export后面专门讲。4.2 工作表与 SQL 历史中间那片写 SQL 的区域叫工作表Worksheet。几个一定要知道的操作执行单条语句用CtrlEnter执行整个脚本用F5。这两个的区别很大——CtrlEnter只跑光标所在的那一条F5会把编辑器里所有内容当脚本跑包括前面那些你只是顺手记下来的、没打算执行的语句。我见过有人在脚本里放了一堆DELETE然后手贱按了 F5后果就不用我说了。这是个必须养成的肌肉记忆。SQL 历史记录是救命的。工具栏上有个像时钟的按钮点开能看到你这次会话执行过的所有语句按时间倒序还能搜索。忘记上一条执行了什么、想找半小时前写的那个复杂查询全靠它。代码模板Snippets也挺有用在右上角面板内置了一些常见语法的骨架比如select、ins、upd。你可以自己往里加模板把团队常用的建表模板、分页模板存进去双击就贴到编辑器里省掉大量重复敲键盘的时间。4.3 执行计划和输出面板性能排查离不开执行计划。写一条 SQL按F10就能看执行计划它会真的执行这条语句并展示计划树。如果不想真的跑可以用CtrlF10生成解释计划不执行只估算。这两者的区别要清楚真的要优化的时候看 F10 的结果因为只有真实执行才能拿到准确的行数估算和实际耗时。执行计划面板里重点看几个东西TABLE ACCESS FULL是全表扫描数据量大就是性能杀手INDEX RANGE SCAN是走索引区间扫描一般是好事CARDINALITY是优化器估算的行数如果和实际行数差了几十倍说明统计信息过期了需要重新收集。下方还有个 DBMS_OUTPUT 面板调试 PL/SQL 的时候靠DBMS_OUTPUT.PUT_LINE往里打日志。注意这个面板默认是关闭的要手动点开并且要执行一次SET SERVEROUTPUT ON不然你打的东西一句都看不见。这个坑我踩过调了半天以为是代码没跑到其实就是面板没开。5. 日常写 SQL 的几个实操套路5.1 分页查询的三种写法分页是最高频的需求之一Oracle 的写法经历过几轮演变。11g 及以前最经典的是 ROWNUM 双层嵌套SELECT * FROM ( SELECT a.*, ROWNUM rn FROM ( SELECT id, name, created_at FROM orders WHERE status PAID ORDER BY created_at DESC ) a WHERE ROWNUM 20 ) WHERE rn 10;这里必须嵌套两层不能写成WHERE ROWNUM 10 AND ROWNUM 20因为 ROWNUM 是在结果集生成过程中逐行分配的第一行分配到的永远是 1永远不会满足 10的条件结果就是空集。这个陷阱新手几乎必踩一次。另一个写法是用分析函数SELECT * FROM ( SELECT id, name, created_at, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM orders WHERE status PAID ) WHERE rn BETWEEN 11 AND 20;12c 之后最简单直接有官方语法SELECT id, name, created_at FROM orders WHERE status PAID ORDER BY created_at DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY;三种写法里我实际测下来等页数比较深的时候比如翻到第一万页ROWNUM 和 ROW_NUMBER 这两种写法在排序字段有索引的情况下通常表现接近OFFSET 语法在语法上最干净。具体用哪个看你的库版本和团队规范。要注意的是OFFSET ... FETCH是 12c 才有的11g 上跑会直接报语法错误。5.2 TRUNC 函数几个容易被忽略的用法TRUNC这个函数看着简单实际用起来花样不少而且都是日常高频。TRUNC(SYSDATE) -- 今天的零点时分秒全归零 TRUNC(SYSDATE, HH) -- 当前整点 TRUNC(SYSDATE, DD) -- 同 TRUNC(SYSDATE) TRUNC(SYSDATE, IW) -- 本周周一ISO 标准周一算一周开始 TRUNC(SYSDATE, W) -- 本周中与当天最接近的那天算起 TRUNC(SYSDATE, MM) -- 本月 1 号 TRUNC(SYSDATE, Q) -- 本季度第一个月的 1 号 TRUNC(SYSDATE, YYYY) -- 本年 1 月 1 号最常用的是TRUNC(SYSDATE)做当天数据的筛选比如SELECT * FROM orders WHERE created_at TRUNC(SYSDATE);这样写的好处是能走created_at上的索引而如果你写成WHERE TO_CHAR(created_at,YYYY-MM-DD) TO_CHAR(SYSDATE,YYYY-MM-DD)因为对列做了函数运算索引就废了全表扫描。这个差别在大表上可能是几秒和几十分钟的区别。提示IW和W的区别很多人搞不清。IW是固定按 ISO 标准一周从周一开始W是按当月的第一个周几来算比较反直觉。做周报统计的时候我基本只用IW因为它稳定可预测。5.3 导出的身份证号变成科学计数法怎么办这个场景太典型了从库里把带身份证号的数据导出来用 Excel 一打开18 位数字全变成了4.10102E17这种鬼样子而且后三位还全变成了 000。原因不是 Oracle 的问题是 Excel 把超过 15 位的纯数字当成数字类型处理超过精度就显示科学计数法而且直接丢掉了精度。解决办法有几种按推荐程度排序。第一种在 SQL 里给字段加前导字符让它导出时就不是纯数字SELECT CHR(9) || id_card AS id_card, name FROM users;CHR(9)是一个制表符导出到 Excel 里看不出来但 Excel 就会把它当文本处理。用空格也行就是前面会多一个空格需要清理。第二种拼成 Excel 公式的形式SELECT || id_card || AS id_card, name FROM users;导出后 Excel 会把它当公式解析成一个文本值显示正常。缺点是在其他工具里打开会看到一堆引号和等号。第三种导出时选对格式。SQL Developer 导出 CSV 的时候导出对话框里可以配置分隔符和引号规则把数字加引号之类的选项打开生成的 CSV 每个字段都带双引号Excel 打开时就会当文本。不过 Excel 打开 CSV 时默认还是可能自作聪明所以更稳的是用数据 从文本/CSV导入在导入向导里手动把那一列的类型指定成文本。第四种直接导出成 Excel 的 xlsx 格式SQL Developer 支持直接导出 xlsx导出的文件里字段类型是保留的打开不会再变。这是最省心的我现在的默认选择就是它。还有一个前提要确认源字段本身的类型。如果表里身份证号存的是NUMBER类型那在数据库层面就已经丢精度了导出前先用TO_CHAR也救不回来。这种情况必须改表结构身份证号一定要用VARCHAR2(18)存这不是可选项是必须的。我在项目评审里看到用数字存身份证号的一律打回去改。5.4 把一个逗号分隔的字段拆成多行这种需求在标签、多值字段的场景里很常见一个字段里存了A,B,C要拆成三行来做关联查询。11g 的写法WITH t AS ( SELECT 1 AS id, A,B,C,D AS tags FROM DUAL ) SELECT t.id, TRIM(REGEXP_SUBSTR(t.tags, [^,], 1, lv)) AS tag FROM t, (SELECT LEVEL AS lv FROM DUAL CONNECT BY LEVEL 100) r WHERE lv REGEXP_COUNT(t.tags, ,) 1 ORDER BY t.id, lv;这里CONNECT BY LEVEL 100是造一个 1 到 100 的行号序列上限要大于可能出现的最大分段数。有人图省事写成 10000结果碰上大表关联的时候性能直接崩掉因为笛卡尔积太大了。正确的做法是先算一下业务里这个字段最多能有多少段留一点余量就行。12c 之后可以用LATERAL加REGEXP_SUBSTR写法更清晰而且执行计划一般也更好SELECT t.id, x.tag FROM t, LATERAL ( SELECT TRIM(REGEXP_SUBSTR(t.tags, [^,], 1, LEVEL)) AS tag FROM DUAL CONNECT BY LEVEL REGEXP_COUNT(t.tags, ,) 1 ) x;注意两种写法都需要正则正则在数据量大的时候开销不小。如果这个字段的格式非常规整、分隔符固定用SUBSTR加INSTR手写循环反而更快。是否值得优化取决于这条 SQL 的执行频率和表的量级。5.5 插入数据时重复就不插这个需求在数据同步场景里太常见了几种写法各有适用场景。MERGE 语句功能最全能同时处理插入和更新MERGE INTO user_sync t USING (SELECT ? AS user_id, ? AS user_name FROM DUAL) s ON (t.user_id s.user_id) WHEN MATCHED THEN UPDATE SET t.user_name s.user_name WHEN NOT MATCHED THEN INSERT (user_id, user_name) VALUES (s.user_id, s.user_name);NOT EXISTS 写法最直观只插入不更新INSERT INTO user_sync (user_id, user_name) SELECT s.user_id, s.user_name FROM source_table s WHERE NOT EXISTS ( SELECT 1 FROM user_sync t WHERE t.user_id s.user_id );并发量大的时候这个写法会有竞态问题两个会话可能同时判断不存在然后都插进去。真正安全的是靠唯一约束兜底配合LOG ERRORS忽略重复INSERT /* IGNORE_ROW_ON_DUPKEY_INDEX(user_sync(user_id)) */ INTO user_sync (user_id, user_name) VALUES (?, ?);这个 hint 是 11g 之后才有的能在遇到唯一键冲突时静默跳过当前行比用异常捕获效率高。但注意它只对唯一索引生效主键冲突不算。如果不想用 hint也可以用LOG ERRORS INTO把失败的行记到一张错误表里脚本跑完再统一查INSERT INTO user_sync (user_id, user_name) SELECT user_id, user_name FROM source_table LOG ERRORS INTO err$_user_sync (batch_001) REJECT LIMIT UNLIMITED;这种方式的好处是批量插入不会因为一行失败就全部回滚适合数据清洗类的任务。用之前要先建错误表SQL Developer 里有现成的过程可以调右键表就能看到创建错误日志表的选项。6. 写和调存储过程6.1 创建、编译、看编译错误在连接树里右键 Procedures 节点新建过程会给你一个模板骨架。填完逻辑按CtrlS保存就会自动编译。如果编译失败下方的编译器日志面板会列出具体的错误行号和错误信息。这里有个细节SQL Developer 报的错误行号是相对于整个过程的不是你当前编辑器滚动的位置。所以在长过程里定位错误可以点编译日志里的行号它会自动跳到对应位置。最烦人的错误是 ORA-00942 表或视图不存在。在你自己 schema 里编译通过的代码换个用户编译就报这个错八成是权限问题——A 用户要对 B 用户的表有直接授权不能只通过角色授权。因为存储过程在编译和执行时不认角色只认直接权限。这是个挺反直觉的规则但非常关键。解决方法是让 DBA 执行GRANT SELECT ON B.表名 TO A;而不是把权限给角色。6.2 断点调试的实际操作SQL Developer 的调试功能做得比我预期好。步骤是这样的先在过程上右键选编译以进行调试然后双击代码行号的左侧空白处下断点会出现一个小红点。接着右键过程选调试它会弹出一个对话框让你填参数值填完点确定程序会停在断点处。这时候可以看几个面板变量面板显示当前作用域所有变量的值堆栈面板显示调用层次还有监视点可以手动加表达式。工具栏上有单步跳过、单步进入、继续执行这些按钮跟一般 IDE 一样。第一次用调试报权限错误是很常见的需要 DBA 给你两个权限GRANT DEBUG CONNECT SESSION TO your_user; GRANT DEBUG ANY PROCEDURE TO your_user;第一个是允许建立调试会话第二个是允许调试非自己所属的过程。如果是调试自己的过程第二个可以不要。但实际操作中经常会调用到别人写的包所以在开发环境把两个都加上比较省事。注意生产环境的账号千万别授这两个权限。调试会话会短暂挂起被调试的会话如果在生产上误操作可能影响正在跑的业务。这类权限只在开发测试环境开。6.3 用 DBMS_OUTPUT 打日志的正确姿势调试不一定每次都要下断点很多时候打日志更快。用DBMS_OUTPUT.PUT_LINE(变量值 || v_val);输出到面板。前提是这几个条件都满足DBMS_OUTPUT 面板处于打开状态执行过SET SERVEROUTPUT ON以及过程所在会话的输出缓冲区没满。缓冲区默认大小是 20000 字节输出多了会被截断或者报 ORA-20000 缓冲区溢出。调试大循环的时候可以在SET SERVEROUTPUT ON SIZE UNLIMITED把上限放开。另一个常见困惑是过程里的输出要等过程执行完才一次性显示不是实时的。这是因为 PL/SQL 是在整个块执行完毕后统一刷新缓冲。想看实时输出得用DBMS_OUTPUT.GET_LINE分次读取比较麻烦一般调试够用了。7. 导出导入与版本管理7.1 导出数据的几种形态右键一张表选导出会让你选格式。常见的几种用途不一样CSV通用性最好但要注意 Excel 的编码和科学计数法问题。Excel xlsx直接给业务方用的首选字段类型保留得最好。Insert 语句生成的 SQL 可以在别的环境直接执行适合少量数据搬运。DDL只导结构不导数据适合建表脚本归档。Loader 格式生成控制文件和数据文件配合 SQL*Loader 大批量导入。导出对话框里有两个参数值得关注一是分隔符默认逗号但如果数据里本身有逗号导出会出问题改成制表符或者竖线更稳二是包含列标题给业务方的文件一定要勾上不然对方打开一脸懵。导出大批量数据的时候界面会卡住这是正常的。SQL Developer 会把数据抓在客户端内存里再写文件表特别大的时候会有内存压力。超过百万行的表我一般不建议用图形界面导直接上 SQL*Loader 或者数据泵更靠谱。7.2 用数据库差异功能比对两个库的结构这是 SQL Developer 里被严重低估的一个功能。菜单在工具 数据库差异选两个连接它会扫描出所有对象级别的差异包括表、视图、索引、存储过程、权限等等可以生成同步脚本。实际怎么用比如开发库改了表结构要在测试库同步你就可以用这个功能生成差异 DDL然后人工检查一遍再执行。比手写脚本可靠得多尤其是索引、约束这些容易漏的东西。要留个心眼它生成的脚本不一定完全符合你的规范比如会带上特定的表空间名。所以生成的脚本必须人工过一遍重点是检查表空间、存储参数、权限这几块。我一般会把它当成差异清单来用而不是当成无脑执行的脚本。7.3 内置 Git 支持值不值得用较新版本的 SQL Developer 内置了 Git 支持可以把数据库对象纳入版本管理。工作流大概是把过程、函数、触发器导出成文件放到一个本地目录初始化 Git 仓库然后在 SQL Developer 里关联这个仓库之后就能看到文件的修改状态可以提交、拉取、回溯。值不值得用取决于团队现状。如果团队本来就有完善的数据库脚本管理流程比如用 Flyway 或者 Liquibase那把 SQL Developer 的 Git 集成当成一个查看差异的辅助就行。如果团队完全是手工改库、没有版本管理那用它至少能给核心的存储过程建一个可回溯的历史比什么都没有强很多。一个实际的经验是这个功能对过程/函数/触发器这类文本型对象比较友好对表数据和表结构就不太合适因为结构变更的 DDL 差异在日常迭代中噪音太大。所以我的用法是只把 PL/SQL 代码纳入版本管理表结构变更还是走专门的变更脚本流程。8. 常见问题速查与避坑清单8.1 启动类问题启动闪退是最常见的一类。排查顺序建议这样走先确认 JDK 版本对不对再看SetJavaHome路径是否指向了 JDK 而不是 JRE 目录再看路径里有没有中文或空格。如果前两步都没问题把用户目录下的配置目录整个删掉%APPDATA%\sqldeveloper或~/.sqldeveloper让程序重新生成默认配置经常能解决一些莫名其妙的启动失败。还有一种情况是启动特别慢要几十秒。这通常是连接数太多或者某个连接的库网络不通程序在等超时。解决办法是关掉暂时不用的连接或者把连接的超时参数调小。打开某个表的时候界面卡死一般是这张表特别大而默认的抓取行数设置太高。改法在工具 首选项 数据库 高级里把数组抓取大小从默认的 200 调小到 50 试试再勾上自动提交关闭。抓取大小这个参数的含义是一次网络往返取回多少行调小了内存压力小但往返次数多需要一个平衡。8.2 中文乱码与编码问题乱码分两块界面中文乱码和数据中文乱码。界面乱码通常是字体问题在工具 首选项 环境 字体里换个支持中文的字体就行比如微软雅黑或者思源黑体。数据乱码更麻烦本质是客户端和朋友库的字符集不一致。先确认数据库字符集SELECT * FROM nls_database_parameters WHERE parameter LIKE %CHARACTERSET%;再看客户端的NLS_LANG环境变量格式是语言_地区.字符集比如SIMPLIFIED CHINESE_CHINA.AL32UTF8。如果库是 UTF-8 而客户端是 ZHS16GBK中文就会变乱码。在 Windows 上设置环境变量的方式是在系统属性里加Linux 上是在 shell 配置文件里 export。还有一个容易忽略的地方SQL Developer 自己的报表编码设置。在工具 首选项 环境 编码里建议设成 UTF-8。这个设置影响的是编辑器里文件的读写跟 NLS_LANG 是两回事两个都要对才行。8.3 写 SQL 时的习惯问题有几个习惯我觉得值得坚持。第一生产环境的连接颜色标红并且不要保存密码每次手输这样能强迫自己确认一遍在连哪个库。第二写UPDATE和DELETE之前先用SELECT COUNT(*)跑一遍条件确认影响行数符合预期再改语句。第三COMMIT一定手动执行不要开自动提交尤其在多步操作里自动提交会让回滚变得不可能。还有一个小技巧是善用 SQL Developer 的格式化功能快捷键CtrlShiftF能把乱七八糟的 SQL 排得整整齐齐。团队协作的时候提交代码前先格式化一遍别人的阅读体验会好很多。提示执行计划要看两遍一遍是开发阶段写完就看的解释计划一遍是上线后真实执行时看的实际计划。两者的差别往往能暴露出统计信息不准或者绑定变量窥探的问题这是纯看代码看不出来的。最后分享一个我自己用着最顺手的小配置在工具 首选项 数据库 工作表里把执行后自动换行到下一语句打开语句分隔符保持分号。这样写完一条按 CtrlEnter光标自动跳到下一条写批量脚本的时候节奏非常顺一天下来能省不少手上的动作。工具这东西从来都是一点点调出来的默认配置只是个起点把它改成贴合自己手感的样子效率上的回报比换个新工具来得实在。
