简介：Oracle官方发布的最新正式版SQL Developer 21.4.3.063.0100 x64，是一款面向数据库开发与运维的一体化图形工具，主要服务于Oracle数据库的开发者与DBA，支持SQL查询、PL/SQL调试、数据库对象管理及数据迁移等场景。该版本免装Oracle客户端，解压即可直接使用，跨平台稳定，免费正版且无功能限制，相比传统商业工具使用更省心。压缩包约435.95MB，共2512个文件，主体包括jar程序库、xml配置文件、dll原生组件、sql脚本与xslt转换模板，另含png图标、md文档、properties设置等辅助资源，目录结构完整，便于按需部署和二次开发。目前已有819人浏览学习，适合日常开发调试、数据迁移及教学演示。通过此包可获得完整官方发行组件、内置JDBC驱动及多语言支持，无需额外授权即可长期使用，有效提升数据库操作效率。
1. SQL Developer 21.4.3 这个 x64 包到底在解决什么问题
Oracle SQL Developer 21.4.3.063.0100-x64，是 Oracle 官方推出的免费数据库图形化客户端，21.4.3 属于 21c 系列的一个稳定补丁版本。对每天要对着 Oracle 和 MySQL 写 SQL、调存储过程、倒数据的工程师来说，这个工具解决的从来不是"能不能连上库"这种基础问题，而是把日常高频操作从命令行里解放出来，顺便把数据导入导出、执行计划分析、SQL 调优这些重活集成到一个界面里。x64 后缀意味着这是 64 位 Windows 安装包，能用到超过 4GB 内存——处理大数据量导出和复杂查询结果集时，这个差别非常直观。
这篇笔记适合两类人：一是刚接触 Oracle 生态，想找一款不用授权费、开箱即用的图形化客户端；二是在用别的工具（Navicat、DBeaver）但遇到 Oracle 特有对象（包、类型、物化视图）支持不顺手，想换回官方工具的老手。我会从安装配置、连接管理、参数调优到踩坑排查，按实际使用顺序把整个链路讲透。
2. 装好并跑起来：安装包、JDK 与初始化配置
2.1 先搞清安装包解压结构和 JDK 依赖
下载下来的 sqldeveloper-21.4.3.063.0100-x64.zip 不是传统意义的安装程序，本质是绿色解压包。解压后你会看到一个 sqldeveloper 文件夹，里面关键路径如下：
sqldeveloper/ bin/ sqldeveloper.exe -- Windows 启动器 sqldeveloper.conf -- JVM 参数配置（堆内存、启动参数） ../ jdbc/ lib/ -- JDBC 驱动相关 sqldeveloper/ sqldeveloper.exe -- 实际启动入口 ...这里需要明确一个容易搞混的点：21.4.3 的 Windows x64 安装包内部自带了一个 JDK，存放在sqldeveloper/jdk目录下。也就是说，如果你只是本机日常使用，不需要额外安装 Java，解压即用。
但要注意，自带 JDK 的版本通常不是最新的。我们团队遇到过用 Java 17 跑这个版本在某些界面渲染上出现字体模糊、卡顿的情况，而自带的 JDK 8 反而稳定。如果你决定改用自己安装的 JDK，需要修改配置文件指向外部 JDK。
2.2 设置 JAVA_HOME 和启动参数
虽然安装包自带 JDK，但当你需要连接某些老版本 Oracle 数据库，或者要跑第三方 JDBC 驱动时，建议显式配置 JAVA_HOME 环境变量，让 SQL Developer 统一使用你指定的 JDK。
# Windows 命令行示例（以管理员身份运行） setx JAVA_HOME "C:\Program Files\Java\jdk1.8.0_202" setx PATH "%PATH%;%JAVA_HOME%\bin"设置完环境变量后，修改sqldeveloper/bin/sqldeveloper.conf里的 JVM 参数。这是需要重点关注的配置文件，堆内存大小直接决定你能打开多大的结果集：
# sqldeveloper.conf 关键行 AddVMOption -Xms128M AddVMOption -Xmx512M # 如果你机器内存足够，建议改成 AddVMOption -Xms512M AddVMOption -Xmx2048M参数说明：
-Xms是 JVM 启动时分配的初始堆内存，设太小会导致刚打开工具频繁 GC，界面卡顿。-Xmx是最大堆内存，超出后报 OutOfMemoryError。查询返回十万行以上的结果集、同时打开多个连接窗口时，512M 很容易顶到上限。- 改了配置后必须重启工具才生效。
还有一个细节，SQL Developer 对工作目录有依赖。如果你把解压后的文件夹放在C:\Program Files\这类带空格的路径下，偶尔会遇到启动器路径解析异常。我一般习惯放在D:\devtools\sqldeveloper\，路径越简单越省心。
2.3 首次启动、自动更新和网络代理
首次启动会弹出"You are using an outdated version"之类的更新提示。如果你的生产环境不允许随意升级客户端，务必点掉自动更新：
菜单路径：Tools -> Preferences -> Environment -> Check for updates on startup 取消勾选这是一个很容易被忽略的坑：某些内网环境，SQL Developer 启动时会尝试连接 Oracle 的更新服务器，如果走代理或者网络策略限制，启动过程会卡住 30~60 秒。取消自动更新检查后，启动时间能缩到 5 秒以内。如果仍然卡顿，检查 hosts 文件或者防火墙日志中是否有对updates.oracle.com（常见 Oracle 更新域名，正常技术场景下用于检查补丁） 的拦截。
首次启动还需要确认默认的数据库连接类型。SQL Developer 自带 Oracle、MySQL、SQL Server、PostgreSQL 等驱动，其中 MySQL 和 SQL Server 的连接需要额外下载 JDBC 驱动。
我一般会这样准备 MySQL 驱动：单独下载mysql-connector-java-8.x.x.jar，放在sqldeveloper/jdbc/lib目录下，然后在 工具->首选项->数据库->第三方 JDBC 驱动 里添加该 jar 包。社区版 Navicat 的 MySQL 驱动是内置的，但 SQL Developer 默认不带 MySQL 驱动，这点很多从 Navicat 转过来的人会踩坑。
3. 连接管理：从 Oracle 到 MySQL 的落地配置
3.1 Oracle 连接的 SID 与 Service Name 的选择
连接 Oracle 时首要搞清楚 SID 和 Service Name 的区别。客户端填错这一项，报错信息往往是ORA-12505: TNS:listener does not currently know of SID given in connect descriptor。
SID 是数据库实例的唯一标识，Service Name 是数据库对外服务的逻辑名，一个实例可以注册多个 Service Name。用 SQL Developer 新建 Oracle 连接时：
连接类型: 基础 主机名: 192.168.1.100 端口: 1521 服务名: orclpdb1 -- 推荐，PDB 用这个 SID: orcl -- 单实例老库用这个判断依据很简单：连 Oracle 12c 以后的 PDB，用 Service Name；连 11g 及以前的单实例，用 SID。如果两个都不确定，问 DBA 要tnsnames.ora文件里的配置，或者执行lsnrctl services查看监听器实际注册的服务名。
保存密码时，如果连接的是生产环境，不建议在连接属性里勾选"保存密码"。SQL Developer 的密码保存机制是加密存储在工作区目录下的credentials.xml文件里，但本机如果被别人登录了，仍然可以通过解密工具读出来，实际安全性不如 Oracle Wallet 或 SSH 隧道。
3.2 SSH 隧道方式连接跳板机后的数据库
很多生产环境的数据库不直接对外开放，需要通过跳板机（堡垒机）转发。SQL Developer 支持在连接属性中配置 SSH 隧道，而不需要额外装 Putty 等工具。
连接属性: 连接类型: SSH 隧道 认证方式: 密码 / 公钥 主机: 10.0.0.5 -- 跳板机地址 端口: 22 用户名: jumpuser 密码: ****** 然后下方继续配置数据库实际内网地址: 主机: 172.16.10.20 端口: 1521 服务名: orclpdb1这里的原理是：SQL Developer 先在本地建立到跳板机的 SSH 连接，再通过这条加密通道去连接数据库。相比本地直连，多了一层加密，速度上会有轻微损耗。配置时要注意跳板机上的AllowTcpForwarding必须为开启状态，否则工具界面一直提示"Connection refused"。
我遇到过最典型的问题：跳板机连接正常，但打开连接时报ORA-12541: TNS:no listener。排查后发现是数据库主机上的防火墙只放行了应用服务器的 IP，没有放行跳板机。这个不是 SQL Developer 的问题，但排查方向容易跑偏到客户端配置上。
3.3 MySQL 连接的驱动与时区参数
MySQL 连接配置相对简单，但有一个时区参数很容易踩坑。连接串上需要显式指定serverTimezone，否则 8.x 的驱动会报错或者时区差 8 小时。
SQL Developer 新建 MySQL 连接时，不能直接改 JDBC URL，需要在连接属性里找到自定义 JDBC URL一栏手动填写完整连接串：
jdbc:mysql://192.168.1.200:3306/business_db?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&characterEncoding=utf8参数说明：
serverTimezone=Asia/Shanghai：不设置的话，JDBC 驱动无法识别服务器时区，报Could not get server timezone，或者插入TIMESTAMP数据时差 8 小时。useSSL=false：内网环境开启 SSL 会显著增加握手耗时和 CPU 开销，除非有合规要求，否则我一般关闭。allowPublicKeyRetrieval=true：MySQL 8.0 使用 caching_sha2_password 认证时，首次连接需要这个参数，否则报Public Key Retrieval is not allowed。characterEncoding=utf8：统一客户端与服务端字符集，避免中文乱码。需要注意 MySQL 8.0 服务端默认字符集是 utf8mb4，不要在客户端写成 utf8mb4 之外的纯 utf8。
驱动 jar 包版本建议选 8.0.31 之后的版本，这个版本修复了多个时区和 SSL 相关的兼容问题。如果连接 MySQL 5.7 且数据库配置了skip_name_resolve，还需要确认驱动的 IP 地址解析行为。这些细节都属于"看着不起眼，不配好就反复翻车"的典型。
4. 调优：把导入导出和结果集处理速度提起来
4.1 堆内存与结果集缓存的关系
SQL Developer 处理大结果集时，默认行为是一次性把查询结果拉回内存。如果堆内存设太小，会出现两种情况：查询转圈 30 秒后直接抛异常，或者结果集表格滚动时明显卡顿。
除了调大sqldeveloper.conf里的堆内存，还有一个隐藏参数值得关注：
AddVMOption -Dsun.java2d.d3d=false AddVMOption -Dsun.java2d.noddraw=true这两个参数不是 SQL Developer 特有的，是 JVM 层面的 2D 渲染开关。在远程桌面（RDP）环境或者一些 Windows Server 系统上，ddraw会导致图形界面刷新异常、滚动结果集时出现黑色残影。加上后大部分情况都能解决。
调优原则不是单纯把-Xmx调到很大就完事。如果你同时开了多个连接窗口，每个窗口的查询结果集都会在堆内存中占据空间。经验值是 2G 堆内存最多支撑同时打开三个万行级别的结果集，超过就容易触发 Full GC，GC 期间界面完全无响应。
4.2 大数据量导出：导出向导的参数选择
用 SQL Developer 导出大表时，默认的 INSERT 方式会非常慢。比如十万行的表导出 .sql 文件，默认参数可能要跑十几分钟。关键是设置导出选项里的批次大小。
导出向导关键选项: 格式: INSERT ALL / CSV / LOADER 每个文件的记录数: 10000 / 50000（改成 10000 以上） 批大小: 1000 -- 关键参数批大小参数控制每次写入文件的缓冲行数。默认值 50 意味着每 50 行做一次 flush，十万行就是 2000 次 I/O 刷写，每次都有磁盘寻道开销。调到 1000 后，同样是十万行，导出时间能缩短到原来的三分之一左右。
经验参考：
表行数 < 1万: 无论怎么调都一样快，不用管 表行数 10万: 批大小 1000，单个文件 50000 行 表行数 > 100万: 批大小 5000，同时启用“并行导出”选项并行导出在 SQL Developer 21.4.3 里的路径是：导出向导的"并行度"选项，填 2~4 即可。填太高会导致单表导出时多个线程争抢同一条 SQL 的游标，反而变慢。这份 SQL Developer 的导出工具对超大表的处理能力不如专门的导出工具，但作为日常操作完全够用。
4.3 查询慢与分析执行计划
SQL Developer 的一个核心价值在于图形化展示执行计划。当一条 SQL 跑得慢，我会先选中查询语句，按F10查看执行计划，确认是否走了全表扫描或者索引失效。
-- 在 SQL Worksheet 中执行，生成执行计划 EXPLAIN PLAN FOR SELECT o.order_id, c.customer_name FROM orders o JOIN customers c ON o.customer_id = c.customer_id WHERE o.created_date >= DATE '2024-01-01' AND o.status = 'PAID'; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);执行计划输出后重点看两个地方：
TABLE ACCESS (FULL)出现在大表扫描上，意味着没有走索引。此时需要回表确认条件列是否有索引。NESTED LOOPS与HASH JOIN的选择。两张小表连接时 NESTED LOOPS 不一定差，但大表连接时出现 NESTED LOOPS 且驱动表小，往往需要优化。
SQL Developer 的执行计划展示相比命令行 态SET AUTOTRACE ON更直观，彩色高亮和缩进树形结构能快速定位瓶颈点。不过要注意一点：执行计划中的"Cost"值是估算值，不代表真实执行时间。我曾经见过 Cost 值相差 20 倍的两条执行计划，实际跑起来时间几乎一样，所以判断优化效果最终还是要看实际执行时间。
5. 避坑：用 21.4.3，最常见的六个翻车现场与排查路径
5.1 启动卡在 Logo 界面，进度条不动
现象：双击sqldeveloper.exe后，窗口一直停留在启动画面，任务管理器显示进程占用 CPU 但画面超过 1 分钟不消失。
原因：最常见的是网络代理配置导致启动时联网检查失败，JVM 进入等待超时。其次是自己配了外部 JDK 但版本不兼容，比如用 Java 17 跑 21.4.3 会出现 SWT 渲染线程崩溃，报错信息未必弹窗显示。
解决：先打开sqldeveloper.conf，在文件末尾加上AddVMOption -Djava.net.preferIPv4Stack=true，这个参数让 JVM 优先走 IPv4 网络栈，避免双栈环境下 IPv6 检查超时。如果仍然卡死，把AddVMOption中指向外部 JDK 的行注释掉，恢复使用自带 JDK。如果还是不行，执行where java检查系统 PATH 中是否混入了其他版本的 Java，Windows 上多个 JDK 并存时经常因为 PATH 顺序导致加载了错误版本。
5.2 连接 Oracle 报 ORA-12505 / ORA-12514
现象：输入主机名、端口、服务名后点连接，报错ORA-12505: TNS:listener does not currently know of SID given in connect descriptor。
原因：绝大多数情况不是网络不通，而是服务名或者 SID 填错了。Oracle 12c 以后默认创建的是 CDB 和 PDB，监听器注册的是 PDB 的 Service Name，不是 CDB 的 SID。很多人拿到连接串时只看到端口和主机名，顺手填了orcl，但实际 PDB 名是orclpdb1。
解决：在 SQL Developer 连接属性里把"连接类型"从"基础"切换为"TNS"，然后在 TNS 别名中填入完整的服务名。或者让 DBA 在数据库服务器上执行：
lsnrctl services输出里Service "orclpdb1" has 1 instance(s)这样的信息，这里写的就是正确填法。把Service "..."后面的名字原样复制到服务名输入框即可。注意不能用"服务名"输入 PDB 的 SID，填下去大概率报 ORA-12505。
5.3 结果集中文乱码，且改 NLS_LANG 无效
现象：查询出来的中文全部显示为问号或乱码，修改环境变量NLS_LANG后重启工具仍然无效。数据库里的数据本身是完好的，用其他客户端查正常。
原因：SQL Developer 21.4.3 在 Windows 上默认使用 Java 的 Unicode 字符集，不依赖NLS_LANG。乱码出现在客户端时，根源多数是数据库客户端字符集与服务端不一致，或者 JDBC 连接没有指定characterEncoding。NLS_LANG是 SQL*Plus 和 OCI 驱动的设置方式，对纯 JDBC 的 SQL Developer 只起部分作用。
解决：先确认服务端字符集，在 SQL Worksheet 中执行：
SELECT userenv('language') FROM dual;如果结果是SIMPLIFIED CHINESE_CHINA.AL32UTF8，客户端就不用改。如果这里显示WE8MSWIN1252，那问题出在数据库实例字符集本身，SQL Developer 配置解决不了，需要 DBA 处理数据迁移或统一字符集。对于 MySQL 连接的中文乱码，检查连接串是否带了characterEncoding=utf8，同时确认表字段的 collation 是 utf8mb4 系列而不是 latin1。如果表字段是 latin1，连接串里写什么都会乱。
5.4 导出 .sql 文件后 Excel 打开中文乱码
现象：用 SQL Developer 导出 CSV 文件，用 Excel 直接打开，中文全部乱码，用 Notepad++ 打开则正常。
原因：SQL Developer 导出的 CSV 默认编码取决于 JVM 的系统文件编码。中文 Windows 上编码通常是 GBK（本地代码页），而 Excel 打开 CSV 时如果没有 BOM 头，会默认按 ANSI 代码页解析。如果你的导出文件实际是 UTF-8 无 BOM，Excel 就会按 GBK 去解码，中文自然乱码。
解决：在导出向导的"分隔符"页面中，把"文件编码"手动切换为UTF-8。但这样仍然没有 BOM，Excel 还是会按 ANSI 解码。更稳妥的做法是导出后用 PowerShell 把文件转成带 BOM 的 UTF-8：
# 将无 BOM 的 UTF-8 文件附加 BOM 头，然后另存为新文件 $content = Get-Content -Path "D:\export\orders.csv" -Encoding UTF8 -Raw $newContent = [System.Text.Encoding]::UTF8.GetPreamble() + [System.Text.Encoding]::UTF8.GetBytes($content) [System.IO.File]::WriteAllBytes("D:\export\orders_utf8bom.csv", $newContent)这个问题的本质是编码标识缺失，和 SQL Developer 本身的关系不大，但导出 CSV 都会遇到，值得留意。
5.5 执行存储过程时长时间无响应，但其他查询正常
现象：在 SQL Worksheet 里调用一个存储过程，运行了很长时间，没有返回结果也没有报错。同一个库用另一台机器上的工具调用秒回。
原因：大概率是存储过程内部有DBMS_LOCK.SLEEP或者执行了外部 I/O 操作，与工具无关。但也可能是 SQL Developer 与数据库之间的网络会话被防火墙中断了，TCP 连接半开情况下，服务端还在执行，客户端已经接收不到数据。此时用SELECT status FROM v$session WHERE ...查看会话状态。
解决：打开"会话监视器"（菜单：工具->会话监视器），找到当前会话，确认SQL_ID指向的语句是否是你要执行的存储过程调用。如果SQL_ID显示的是BEGIN proc_name; END;，说明调用本身没有被阻塞，问题大概率在存储过程内部的嵌套子查询或循环上。我遇到过一个存储过程里嵌了 50 万次循环插入的临时表，必然慢。处理方式是查v$session_wait中该会话的EVENT字段：
EVENT = 'PL/SQL lock timer' -- 存储过程内部 SLEEP EVENT = 'enq: TX - row lock contention' -- 被其他会话锁阻塞 EVENT = 'SQL*Net message from client' -- 客户端空闲，等用户输入根据 EVENT 才能定位是等待锁，还是等待 I/O，还是单纯代码逻辑慢。
5.6 工具打不开，报缺少 MSVCR120.dll
现象：双击启动直接提示The program can't start because MSVCR120.dll is missing from your computer，或者弹出0xc000007b错误。
原因：SQL Developer 的 Windows 安装包依赖 Microsoft Visual C++ 2013 Redistributable 运行时库。某些精简版系统或者 Windows Server 默认不带。0xc000007b 除了缺库，也可能是 x64 位库与 x86 位库混装导致。
解决：安装 Microsoft Visual C++ 2013 Redistributable Package (x64) 版本，运行库装完通常就好了。安装时注意看清包名里的 x64 标识，只装 x86 版本解决不了 64 位程序的依赖。如果你用的是 Windows 11 LTSC 2024 这类精简系统，建议一步到位把 VC++ 2013 到 2022 的 x64 运行库都装上，以后遇到其他开发工具缺运行库也能一起解决。
6. 进阶：命令行启动、代码模板与版本升级路线
到了这一步，工具能稳定跑起来了，日常连接、导出、调优也顺手了，接下来值得花时间的是三个能明显提升效率的进阶方向。
第一个是命令行启动。生产环境排障时，图形界面不一定可用，SQL Developer 提供了命令行模式执行脚本的能力。在 Windows 的 cmd 窗口里可以这样跑：
cd D:\devtools\sqldeveloper\bin sqldeveloper -start -connect "jdbc:oracle:thin:@//192.168.1.100:1521/orclpdb1" -interpreter "D:\scripts\check.sql"这个用法适合定时巡检脚本或者批量执行一段固定的 SQL。启动时不再加载图形界面的完整渲染引擎，内存开销小很多，我一般拿来做凌晨的数据检查任务，比写一堆sqlplus的登录逻辑更直观。
第二个值得养成习惯的是代码模板。21.4.3 支持自定义 SQL 代码模板，路径在：工具->首选项->数据库->SQL 编辑器代码模板。把团队常用的分页查询、字典翻译、表对比脚本存成模板，避免每次写重复的长 SQL。这一步对团队协作的价值是慢慢积累的，半年下来库里的模板集合就是一套小型的开发规范。
第三个是版本升级路线。21.4.3 这个版本虽然稳定，但 Oracle 已经推出了后续的 23.x 系列。不要急着追新，先明确你的数据库版本——如果生产库还在 11g，21.4.3 完全够用且更稳妥；如果已经升到 23c，再考虑升级客户端。升级前导出sqldeveloper/user目录下的连接配置，新版安装后直接替换目录即可保留全部连接，不用重新配置。
回头看我这些年用 SQL Developer 的过程，最大的教训是：任何数据库图形化工具都只是辅助，真正让你不翻车的，永远是搞清楚底层连接参数和数据库本身的运行状态。SQL Developer 的好处在于把这一切可视化，但前提是你知道每一步配置背后在解决什么问题。希望这篇笔记能帮你在部署和维护 21.4.3 时少走一些我走过的弯路。
本文还有配套的精品资源，点击获取
