作为常年泡在 IDEA 里写 Java 的人我隔三差五就得停下来查一把数据库。以前查数据最麻烦的就是切窗口代码写到一半发现某个字段的值不对得从 IDEA 切到数据库客户端连上连接、敲 SQL、看结果看完再切回来。这一来一回看着没多少时间但一天来个七八次脑子里的上下文早被打断了。后来我用上了 JavaAI 插件的“执行 SQL 语句”功能在 IDEA 里直接把 SQL 跑掉、结果原地看整个查数据的节奏顺了很多连带着写代码的效率也提了一截。这篇就把这功能怎么配、怎么用、有哪些坑按我实际走过的流程整理出来给同样被切窗口折磨的兄弟一个参考。1. 这个功能到底解决了什么问题1.1 从“切窗口查数据”说起先聊聊以前查数据有多烦。我在本地开发的时候代码里经常要跟数据库打交道比如某个接口返回的数据不对第一反应就是去看看库里到底存了什么。最早我习惯开一个 Navicat 或者类似客户端专门留着查数据用。刚开始还行用久了问题就来了首先是窗口太多桌面上一堆东西找起来麻烦其次是你从写代码的状态切换到“查库”的状态是需要一段注意力的查完再切回来代码逻辑往往要想一会儿才能接上。这种切来切去的操作一天来几次还能忍如果是排查线上问题几个小时都得泡在数据里那就真的头皮发麻了。而且很多数据库客户端版本之间还有差异有的界面布局不一样有的连接配置还得重新填每次换电脑、换项目都要折腾一遍。后来我发现其实我不需要一个完整的数据库管理工具我大多数时候就是“跑一条 SQL、看一眼结果”而已就这么简单的一个需求被切窗口整得特别重。1.2 JavaAI 的定位是“执行”不是“管理”JavaAI 插件的“执行 SQL 语句”功能正好卡在这个需求点上。它不是想取代 Navicat 那种专业客户端它更像个“随身查询器”核心就一件事你给它一条 SQL它帮你跑然后把结果摊在 IDEA 里给你看。这个定位我觉得特别清醒。做数据库管理的人都知道真正的 DBA 工具要管连接、管备份、管用户权限、管执行计划那一套东西在开发调试的场景里是杀鸡用牛刀。JavaAI 把范围圈定在“执行”这一块反而让我用得顺手——因为它不用你维护一堆连接不用你记客户端快捷键更不用你在 IDEA 和自己数据集市之间来回横跳。你只要选中一段 SQL或者让 AI 帮你生成一段 SQL点一下执行结果就出来了。1.3 它能帮你做什么、不适合做什么用了一段时间之后我总结了一下这功能适合的场景写代码时突然想确认某个表结构和数据、接口返回值对不上想看底表数据、联调的时候想快速验证 SQL 语法、或者只是想在改需求前看一眼线上数据量级。这些场景下它的体验比专门的数据库客户端要轻得多因为所有的事情都发生在一个 IDE 里。但它也有明显不适合干的活。比如你要做大批量的数据迁移、要设计复杂的表结构、要盯着慢查询做调优这些建议还是用专业客户端。JavaAI 执行 SQL 更适合“短平快”的查询不适合长会话、深操作。这里踩过一次坑我拿它跑一个几百万行的更新结果卡了很久最后我只能去命令行中断从此之后超过一定数据量级的操作我都会切回专门的工具。想清楚它擅长什么就不会对它有超出预期的抱怨。2. 核心思路与实现机制2.1 它到底是怎么把 SQL 跑起来的这个功能在底层做的事其实你拆开看并不复杂就是“SQL 输入 → 数据源连接 → 执行 → 结果渲染”。但能把这些环节揉在 IDEA 里靠的是它对 IDEA 自带的数据库功能做了很好的复用和扩展。IDEA 本身是带着一套数据库模块的你在右侧边栏能找到 Database 面板可以配置各种数据源连接。JavaAI 插件本质上就是基于那一套连接信息在你发起“执行 SQL 语句”的时候把当前光标所在或选中的 SQL 片段交给一个内置的执行器在后台建立一个数据库会话跑完之后把结果以表格形式渲染到 IDEA 的输出区域。整个过程对你来说只有一个动作但背后帮你省掉了“新建连接、填参数、切换到查询页”这些零碎步骤。2.2 为什么偏偏在 IDEA 里做这件事软件开发有个很朴素的原则离得近省事。你写代码在 IDEA改配置在 IDEA看日志在 IDEA那查数据这件事能并在 IDEA 里就并进去。每次切外部工具不仅费时间还容易打断思路而打断思路的代价在写复杂逻辑时特别大。我印象很深的一次在排查一个多线程并发问题代码里涉及到几个表的状态流转我需要在很短的时间里反复看不同 id 的数据变化。如果切到外部客户端来回几次心态就崩了但在这个功能里我一个窗口写完查询直接执行结果刷在下方再来一条再执行整个过程行云流水。这种“在一个地方把所有事干完”的体验是它最大的价值。2.3 和 IDEA 自带 Database 面板有什么差别这里肯定有人要问IDEA 自带不是就能连数据库写 SQL 跑查询吗没错IDEA 的 Database 面板能干这事JavaAI 的“执行 SQL 语句”和它最大的区别是在入口和便捷性上。IDEA 自带面板更多是“面向管理”的你要先在右边栏点开面板、定位到连接、再打开一个 SQL 控制台然后在那个控制台里写和执行。这一套流程没问题但总觉得操作路径有点长。而 JavaAI 的入口更贴近你的代码上下文直接在编辑器里选中 SQL快捷键一按就执行了结果也不用切面板就在旁边看。另外它还能结合 AI 模型你描述一个需求它帮你把 SQL 写出来再执行这条链路对不常写复杂 SQL 的人来说特别友好。2.4 设计逻辑里的一个关键取舍我个人理解这个功能的设计逻辑是“默认信任随时兜底”。它没有强制你每次执行前都要确认连接、确认环境默认就跑在当前选中的数据源上效率优先。但它同时也留了口子你可以手动指定连接也可以在主界面看清楚当前数据源是什么以防跑错环境。这个取舍很贴近日常开发的真实需求。你想想在开发环境里查数据是高频动作每次都要弹一堆确认框几次之后就不想用了。JavaAI 选择把高频场景做到最顺把低频的、需要谨慎的场景留给用户手动控制。我后来习惯了之后每次执行前会下意识看一眼状态栏上的连接名已经形成肌肉记忆了。3. 实操过程从配置到跑通一条 SQL3.1 环境准备与插件安装先把前提说清楚我用的是 IDEA 2023.1 版本Java 环境是 JDK 8 和 JDK 17 混合着用插件对版本倒没有特别苛刻的要求IDEA 2021 之后的版本基本都能跑。安装方式很简单打开 IDEA 的 Settings进入 Plugins搜索 JavaAI点 Install 就行。装完它会提示你重启 IDEA照做就好。这里有个小提醒有些同事装插件喜欢一次装一堆装完一起重启再验证结果出问题都不知道是谁的锅。我的习惯是只装这一款重启后先在自带 Database 面板里把连接配好确认连接没问题再去用 JavaAI 的“执行 SQL 语句”排查起来思路清楚很多。3.2 数据源配置这一步别偷懒虽然 JavaAI 是“执行”功能但它本身不存连接信息它吃的是 IDEA Database 面板里已经配好的数据源。所以第一步其实是把数据源配置好。具体路径打开 IDEA 右侧的 Database 面板点左上角的加号选择你的数据库类型。我用的是 MySQL选完会弹出一个连接信息窗口填主机地址、端口、用户名、密码还有一个数据库名。填完后点 Test Connection这里要特别注意如果提示缺少驱动IDEA 会问你要不要下载你就让它下载等它装好。驱动这个问题常见特别是一些内网环境下载不了手动去官网把驱动 jar 包下来然后在 Driver 设置里指向本地路径也能解决。数据源配好之后最好给每个连接起个好认的名字别全用默认的 localhost。尤其是项目多了以后几个库里同名表都有连接名还是“MySQL localhost”这种执行的时候很容易看错。3.3 用 JavaAI 生成 SQL 并执行数据源搞定之后JavaAI 就可以上场了。它有两种用法我分开说。第一种你自己已经写好 SQL想直接跑。在编辑器里打开一个 .sql 文件或者直接建个新的临时文件把 SQL 敲进去然后用鼠标选中你想执行的那一段调用执行快捷键它就会跑。选中的好处是如果一个文件里有多条 SQL它不会把没选中的也一并跑了避免误操作。第二种就是它更好玩的用法——让 AI 帮你写。你打开 JavaAI 的输入框用自然语言描述你想查什么比如“查一下用户表里状态为 1 的前 10 条数据”它会把 SQL 生成出来然后你确认后直接执行。这一步对不太熟悉表结构、或者不想费劲写复杂 join 的人来说很省事。要注意的是你得在描述里尽量说清楚是哪张表、哪个字段、什么条件不然它可能猜得不够准。3.4 执行结果怎么看执行完之后结果会显示在 IDEA 下方的一个结果区域里就是一个标准的表格视图。列名对应你查出的字段行就是数据左上角会显示这次查询影响的行数和耗时。这里有个我一开始没注意的细节如果 SQL 是查询语句结果区显示的是查询出的数据如果 SQL 是更新、插入、删除这类语句结果区不会给你展示大表格而是会告诉你“执行成功影响了几行”。这个区别要想清楚免得你跑一个 UPDATE 之后到处找“数据在哪看”——它不是查询自然没有查询结果集。另外注意看底部那个状态栏可以看到当前跑的是哪个连接我每次执行前都会下意识确认一下尤其是手上有好几个数据源的时候这个习惯能避免把 SQL 发错库。3.5 一个真实的小例子拿一个很常见的场景举例。我有个模拟项目表叫 order_info字段包括 id、user_id、order_no、amount、status。当时我要看每个用户的总下单金额排个序。在 JavaAI 里输入一句话“统计 order_info 表中每个 user_id 的总金额按总金额倒序排列。”它生成的 SQL 大致是SELECT user_id, SUM(amount) AS total_amount FROM order_info GROUP BY user_id ORDER BY total_amount DESC;看着没问题我点执行结果很快出来多少行、每个用户多少钱一目了然。最舒服的是我全程没离开 IDEA查完直接在代码里继续定位下一步问题。这种“一句话出数据”的体验确实比打开客户端连库、手敲 SQL 快很多。4. 常见问题与排查技巧实录4.1 连接报错JDBC 驱动找不到这个问题我碰到过不止一次。配置好数据源之后点 Test Connection提示类似“no suitable driver found”大概率是驱动没配上。解决办法分两步第一步回到 Database 面板选中你的数据源打开设置看 Driver 那栏的下拉框确认有没有具体的驱动类第二步如果下拉框里是空的点旁边的下载按钮补上。如果下载失败说明网络不通就得手动去数据库官方资源页下载对应版本的 jar然后在 Driver 设置里通过“Add”指向本地文件路径。有一点要提醒驱动版本和你连的数据库版本尽量匹配。MySQL 5.7 和 MySQL 8.0 用的驱动类都不太一样混用容易报奇怪的时区或认证错。4.2 执行报语法错误但 SQL 明明在客户端能跑这个坑我踩得比较深。有一段 SQL 在 Navicat 里跑得好好的拿到 JavaAI 里执行就报语法错误。后来排查发现问题出在方言差异上。它默认的方言有时候和你的数据库类型对不上比如你连的是 PostgreSQL但它按 MySQL 方言去解析、校验某些写法就会出问题。解决方式是在数据源里确认“Dialect”设置正确同时尽量用标准的 SQL 写法少用数据库特有的语法。比如别写LIMIT之外的数据库分页写法join 条件都用显式写法。另外如果一条 SQL 特别复杂建议先在专门的客户端里跑通再拿过来执行省得在插件环境里慢慢调。4.3 误执行了非查询语句怎么办这个是我最想强调的一个坑。JavaAI 的执行功能默认是直接执行的它可不管你是 SELECT 还是 DELETE。如果你在编辑器里选中了一行 DELETE直接触发执行那后果懂得都懂。我第一次用的时候没太注意选错了一段更新语句还好是在本地开发库里没造成什么后果。之后我养成两个习惯第一执行前一定看清楚选中内容宁可多花两秒检查也不让一条 DELETE 稀里糊涂跑出去第二如果数据源允许我会在 Database 面板里给重要的库开启“只读”模式或者用最小权限的账号连库从源头上规避误操作。4.4 在事务里查不到刚写入的数据还有一次我遇到的情况更隐蔽代码里有一个事务事务内插了一些数据但还没提交。我同时用 JavaAI 执行同库查询数据库连接是另一个会话因为 MVCC 隔离机制它看不到当前事务里未提交的数据。于是我以为代码写错了其实数据根本没提交白排查了半天。这个属于数据库基础设施的知识不算插件 bug但遇到的时候很容易让人困惑。所以后来我再遇到“查不到刚写入的数据”这种怪现象第一反应就是先看看是不是有未提交事务确认提交后再查就正常了。4.5 结果集太大IDE 直接卡住我试过连续执行几条不带 LIMIT 的查询其中有一条关联了好几个表结果返回来十几万行IDEA 的下方结果区直接开始转圈滚动都有点卡。这个体验很差后来我学乖了凡是查询操作第一版 SQL 我一定加 LIMIT先确认数据量和数据内容再决定要不要扩大范围。JavaAI 的执行区域里其实可以配置默认的行数上限我建议把它设成 500 或者 1000日常查数据足够用也不会把 IDE 拖垮。要是真需要全量数据再临时把限制放开或者干脆用数据导出功能走专门工具。5. 一些个人经验和小技巧5.1 查询之前先定好 LIMIT前面已经提到过这里想再单独唠叨几句。开发查数据和报表查询不一样多数时候我们只是想看个大概。所以你写 SQL 的时候默认养成写LIMIT 100的习惯既能快速出结果又不至于把开发库压到告警。这个习惯在山穷水尽追查一个刁钻 bug 的时候特别好用因为它让你先看到数据长什么样再决定下一步。5.2 利用“选中片段”只跑自己关心的语句如果 SQL 文件里有好几段语句有的还是历史遗留的调试语句直接整体执行容易出事。我的做法是永远只选中需要执行的那一段然后触发执行快捷键。这样既保证安全也减少无谓的执行时间。尤其当文件里有 UPDATE、DELETE 这类语句时选中再跑基本不会误伤。5.3 让 AI 写 SQL但别完全依赖JavaAI 的 AI 写 SQL 能力确实能帮你省时间比如不记得某个函数怎么拼、某个 join 条件怎么组织直接描述需求让它生成。但我的体会是它对你当前项目表结构的理解并不一定完整准确尤其是字段命名比较随意的业务表它生成出来的 SQL 有概率引用了不存在的字段。所以我一般把它当“草稿生成器”用先让它写然后我在编辑里快速过一遍检查表名、字段名、条件逻辑确认没毛病再执行。如果需要的是非常复杂的 SQL我会拆成几步每一步单独描述避免一步到位生成的语句绕了远路。5.4 高频查询保存成模板有些查询一周要跑好几次每次都要重新敲或者重新让 AI 生成也挺烦。我会把这些常用查询整理成一个小的 SQL 文件放在项目里专门的目录下比如 docs/sql 或者 db/query下次直接打开文件、选中、执行就行。这个做法的额外好处是团队里的新同事接手项目时能看到这些整理过的查询快速了解核心表的常用访问方式比在群里问人要快得多。5.5 给生产环境单独搞一个低权限账号最后一条也是我最想让所有开发同事看到的。不管用什么工具连生产库一定不要用管理员账号。我自己的习惯是套一个只读账号连过去这样日常排查数据没有任何问题但所有写操作天然就被拦住了。JavaAI 的执行功能本质上是直通的它不会替你做太多安全校验所以安全边界得自己设。你可以在 Database 面板里给生产数据源专门建一个连接配置用低权限账号登录然后用 JavaAI 执行查询就安全多了。平时我宁愿多花两分钟把账号配好也不想在凌晨三点排查生产问题时因为一个误操作把自己搭进去。5.6 快捷键能改就改成顺手的位置插件一般自带一个默认快捷键但默认键位不见得顺手尤其是我习惯左手操作数值区右手握鼠标有一些组合键按起来很别扭。我拿到插件之后第一件事就是去 Keymap 设置里把“执行 SQL 语句”的快捷键改成一个我舒服的键位。这不算什么高深技巧但提升很明显。因为查数据的动作是极其高频的每一个多余的按键动作积攒下来都是看得见的时间消耗。我改完之后基本做到了“选中即查、查询即看”整个过程顺畅到没有存在感。如果你还在手动去菜单里点来点去我建议先花一分钟把快捷键调好回报率特别高。6. 最后说点实在的用了这个功能快半年我最直观的感受是查数据这件事终于回到了它该在的位置——它不是开发流程里的一道“关卡”而是像看日志、看变量一样抬手就能完成的动作。以前我遇到疑难问题去数据库查数据会有一种“又要切窗口好麻烦”的心理惰性很多时候宁可瞎猜或者加日志打点也不愿意去看数据。现在没有这层心理负担了该查就查反而定位问题的速度快了很多。当然我也一直提醒自己这只是个“执行”工具不是万能的数据库管理台。它帮你省掉的是机械性的切换和等待真正要搞懂的东西比如表结构设计、索引怎么建、SQL 怎么优化还得靠平时多积累。工具只是放大器你的判断力才是核心。不过至少在“查数据”这个最日常的小事上我现在是真的离不开它了。 
长河君 · 2026/10/19 9:59:39 · 阅读 1.2k IDEA执行SQL插件指南：不切窗口也能高效查数据库
作为常年泡在 IDEA 里写 Java 的人我隔三差五就得停下来查一把数据库。以前查数据最麻烦的就是切窗口代码写到一半发现某个字段的值不对得从 IDEA 切到数据库客户端连上连接、敲 SQL、看结果看完再切回来。这一来一回看着没多少时间但一天来个七八次脑子里的上下文早被打断了。后来我用上了 JavaAI 插件的“执行 SQL 语句”功能在 IDEA 里直接把 SQL 跑掉、结果原地看整个查数据的节奏顺了很多连带着写代码的效率也提了一截。这篇就把这功能怎么配、怎么用、有哪些坑按我实际走过的流程整理出来给同样被切窗口折磨的兄弟一个参考。1. 这个功能到底解决了什么问题1.1 从“切窗口查数据”说起先聊聊以前查数据有多烦。我在本地开发的时候代码里经常要跟数据库打交道比如某个接口返回的数据不对第一反应就是去看看库里到底存了什么。最早我习惯开一个 Navicat 或者类似客户端专门留着查数据用。刚开始还行用久了问题就来了首先是窗口太多桌面上一堆东西找起来麻烦其次是你从写代码的状态切换到“查库”的状态是需要一段注意力的查完再切回来代码逻辑往往要想一会儿才能接上。这种切来切去的操作一天来几次还能忍如果是排查线上问题几个小时都得泡在数据里那就真的头皮发麻了。而且很多数据库客户端版本之间还有差异有的界面布局不一样有的连接配置还得重新填每次换电脑、换项目都要折腾一遍。后来我发现其实我不需要一个完整的数据库管理工具我大多数时候就是“跑一条 SQL、看一眼结果”而已就这么简单的一个需求被切窗口整得特别重。1.2 JavaAI 的定位是“执行”不是“管理”JavaAI 插件的“执行 SQL 语句”功能正好卡在这个需求点上。它不是想取代 Navicat 那种专业客户端它更像个“随身查询器”核心就一件事你给它一条 SQL它帮你跑然后把结果摊在 IDEA 里给你看。这个定位我觉得特别清醒。做数据库管理的人都知道真正的 DBA 工具要管连接、管备份、管用户权限、管执行计划那一套东西在开发调试的场景里是杀鸡用牛刀。JavaAI 把范围圈定在“执行”这一块反而让我用得顺手——因为它不用你维护一堆连接不用你记客户端快捷键更不用你在 IDEA 和自己数据集市之间来回横跳。你只要选中一段 SQL或者让 AI 帮你生成一段 SQL点一下执行结果就出来了。1.3 它能帮你做什么、不适合做什么用了一段时间之后我总结了一下这功能适合的场景写代码时突然想确认某个表结构和数据、接口返回值对不上想看底表数据、联调的时候想快速验证 SQL 语法、或者只是想在改需求前看一眼线上数据量级。这些场景下它的体验比专门的数据库客户端要轻得多因为所有的事情都发生在一个 IDE 里。但它也有明显不适合干的活。比如你要做大批量的数据迁移、要设计复杂的表结构、要盯着慢查询做调优这些建议还是用专业客户端。JavaAI 执行 SQL 更适合“短平快”的查询不适合长会话、深操作。这里踩过一次坑我拿它跑一个几百万行的更新结果卡了很久最后我只能去命令行中断从此之后超过一定数据量级的操作我都会切回专门的工具。想清楚它擅长什么就不会对它有超出预期的抱怨。2. 核心思路与实现机制2.1 它到底是怎么把 SQL 跑起来的这个功能在底层做的事其实你拆开看并不复杂就是“SQL 输入 → 数据源连接 → 执行 → 结果渲染”。但能把这些环节揉在 IDEA 里靠的是它对 IDEA 自带的数据库功能做了很好的复用和扩展。IDEA 本身是带着一套数据库模块的你在右侧边栏能找到 Database 面板可以配置各种数据源连接。JavaAI 插件本质上就是基于那一套连接信息在你发起“执行 SQL 语句”的时候把当前光标所在或选中的 SQL 片段交给一个内置的执行器在后台建立一个数据库会话跑完之后把结果以表格形式渲染到 IDEA 的输出区域。整个过程对你来说只有一个动作但背后帮你省掉了“新建连接、填参数、切换到查询页”这些零碎步骤。2.2 为什么偏偏在 IDEA 里做这件事软件开发有个很朴素的原则离得近省事。你写代码在 IDEA改配置在 IDEA看日志在 IDEA那查数据这件事能并在 IDEA 里就并进去。每次切外部工具不仅费时间还容易打断思路而打断思路的代价在写复杂逻辑时特别大。我印象很深的一次在排查一个多线程并发问题代码里涉及到几个表的状态流转我需要在很短的时间里反复看不同 id 的数据变化。如果切到外部客户端来回几次心态就崩了但在这个功能里我一个窗口写完查询直接执行结果刷在下方再来一条再执行整个过程行云流水。这种“在一个地方把所有事干完”的体验是它最大的价值。2.3 和 IDEA 自带 Database 面板有什么差别这里肯定有人要问IDEA 自带不是就能连数据库写 SQL 跑查询吗没错IDEA 的 Database 面板能干这事JavaAI 的“执行 SQL 语句”和它最大的区别是在入口和便捷性上。IDEA 自带面板更多是“面向管理”的你要先在右边栏点开面板、定位到连接、再打开一个 SQL 控制台然后在那个控制台里写和执行。这一套流程没问题但总觉得操作路径有点长。而 JavaAI 的入口更贴近你的代码上下文直接在编辑器里选中 SQL快捷键一按就执行了结果也不用切面板就在旁边看。另外它还能结合 AI 模型你描述一个需求它帮你把 SQL 写出来再执行这条链路对不常写复杂 SQL 的人来说特别友好。2.4 设计逻辑里的一个关键取舍我个人理解这个功能的设计逻辑是“默认信任随时兜底”。它没有强制你每次执行前都要确认连接、确认环境默认就跑在当前选中的数据源上效率优先。但它同时也留了口子你可以手动指定连接也可以在主界面看清楚当前数据源是什么以防跑错环境。这个取舍很贴近日常开发的真实需求。你想想在开发环境里查数据是高频动作每次都要弹一堆确认框几次之后就不想用了。JavaAI 选择把高频场景做到最顺把低频的、需要谨慎的场景留给用户手动控制。我后来习惯了之后每次执行前会下意识看一眼状态栏上的连接名已经形成肌肉记忆了。3. 实操过程从配置到跑通一条 SQL3.1 环境准备与插件安装先把前提说清楚我用的是 IDEA 2023.1 版本Java 环境是 JDK 8 和 JDK 17 混合着用插件对版本倒没有特别苛刻的要求IDEA 2021 之后的版本基本都能跑。安装方式很简单打开 IDEA 的 Settings进入 Plugins搜索 JavaAI点 Install 就行。装完它会提示你重启 IDEA照做就好。这里有个小提醒有些同事装插件喜欢一次装一堆装完一起重启再验证结果出问题都不知道是谁的锅。我的习惯是只装这一款重启后先在自带 Database 面板里把连接配好确认连接没问题再去用 JavaAI 的“执行 SQL 语句”排查起来思路清楚很多。3.2 数据源配置这一步别偷懒虽然 JavaAI 是“执行”功能但它本身不存连接信息它吃的是 IDEA Database 面板里已经配好的数据源。所以第一步其实是把数据源配置好。具体路径打开 IDEA 右侧的 Database 面板点左上角的加号选择你的数据库类型。我用的是 MySQL选完会弹出一个连接信息窗口填主机地址、端口、用户名、密码还有一个数据库名。填完后点 Test Connection这里要特别注意如果提示缺少驱动IDEA 会问你要不要下载你就让它下载等它装好。驱动这个问题常见特别是一些内网环境下载不了手动去官网把驱动 jar 包下来然后在 Driver 设置里指向本地路径也能解决。数据源配好之后最好给每个连接起个好认的名字别全用默认的 localhost。尤其是项目多了以后几个库里同名表都有连接名还是“MySQL localhost”这种执行的时候很容易看错。3.3 用 JavaAI 生成 SQL 并执行数据源搞定之后JavaAI 就可以上场了。它有两种用法我分开说。第一种你自己已经写好 SQL想直接跑。在编辑器里打开一个 .sql 文件或者直接建个新的临时文件把 SQL 敲进去然后用鼠标选中你想执行的那一段调用执行快捷键它就会跑。选中的好处是如果一个文件里有多条 SQL它不会把没选中的也一并跑了避免误操作。第二种就是它更好玩的用法——让 AI 帮你写。你打开 JavaAI 的输入框用自然语言描述你想查什么比如“查一下用户表里状态为 1 的前 10 条数据”它会把 SQL 生成出来然后你确认后直接执行。这一步对不太熟悉表结构、或者不想费劲写复杂 join 的人来说很省事。要注意的是你得在描述里尽量说清楚是哪张表、哪个字段、什么条件不然它可能猜得不够准。3.4 执行结果怎么看执行完之后结果会显示在 IDEA 下方的一个结果区域里就是一个标准的表格视图。列名对应你查出的字段行就是数据左上角会显示这次查询影响的行数和耗时。这里有个我一开始没注意的细节如果 SQL 是查询语句结果区显示的是查询出的数据如果 SQL 是更新、插入、删除这类语句结果区不会给你展示大表格而是会告诉你“执行成功影响了几行”。这个区别要想清楚免得你跑一个 UPDATE 之后到处找“数据在哪看”——它不是查询自然没有查询结果集。另外注意看底部那个状态栏可以看到当前跑的是哪个连接我每次执行前都会下意识确认一下尤其是手上有好几个数据源的时候这个习惯能避免把 SQL 发错库。3.5 一个真实的小例子拿一个很常见的场景举例。我有个模拟项目表叫 order_info字段包括 id、user_id、order_no、amount、status。当时我要看每个用户的总下单金额排个序。在 JavaAI 里输入一句话“统计 order_info 表中每个 user_id 的总金额按总金额倒序排列。”它生成的 SQL 大致是SELECT user_id, SUM(amount) AS total_amount FROM order_info GROUP BY user_id ORDER BY total_amount DESC;看着没问题我点执行结果很快出来多少行、每个用户多少钱一目了然。最舒服的是我全程没离开 IDEA查完直接在代码里继续定位下一步问题。这种“一句话出数据”的体验确实比打开客户端连库、手敲 SQL 快很多。4. 常见问题与排查技巧实录4.1 连接报错JDBC 驱动找不到这个问题我碰到过不止一次。配置好数据源之后点 Test Connection提示类似“no suitable driver found”大概率是驱动没配上。解决办法分两步第一步回到 Database 面板选中你的数据源打开设置看 Driver 那栏的下拉框确认有没有具体的驱动类第二步如果下拉框里是空的点旁边的下载按钮补上。如果下载失败说明网络不通就得手动去数据库官方资源页下载对应版本的 jar然后在 Driver 设置里通过“Add”指向本地文件路径。有一点要提醒驱动版本和你连的数据库版本尽量匹配。MySQL 5.7 和 MySQL 8.0 用的驱动类都不太一样混用容易报奇怪的时区或认证错。4.2 执行报语法错误但 SQL 明明在客户端能跑这个坑我踩得比较深。有一段 SQL 在 Navicat 里跑得好好的拿到 JavaAI 里执行就报语法错误。后来排查发现问题出在方言差异上。它默认的方言有时候和你的数据库类型对不上比如你连的是 PostgreSQL但它按 MySQL 方言去解析、校验某些写法就会出问题。解决方式是在数据源里确认“Dialect”设置正确同时尽量用标准的 SQL 写法少用数据库特有的语法。比如别写LIMIT之外的数据库分页写法join 条件都用显式写法。另外如果一条 SQL 特别复杂建议先在专门的客户端里跑通再拿过来执行省得在插件环境里慢慢调。4.3 误执行了非查询语句怎么办这个是我最想强调的一个坑。JavaAI 的执行功能默认是直接执行的它可不管你是 SELECT 还是 DELETE。如果你在编辑器里选中了一行 DELETE直接触发执行那后果懂得都懂。我第一次用的时候没太注意选错了一段更新语句还好是在本地开发库里没造成什么后果。之后我养成两个习惯第一执行前一定看清楚选中内容宁可多花两秒检查也不让一条 DELETE 稀里糊涂跑出去第二如果数据源允许我会在 Database 面板里给重要的库开启“只读”模式或者用最小权限的账号连库从源头上规避误操作。4.4 在事务里查不到刚写入的数据还有一次我遇到的情况更隐蔽代码里有一个事务事务内插了一些数据但还没提交。我同时用 JavaAI 执行同库查询数据库连接是另一个会话因为 MVCC 隔离机制它看不到当前事务里未提交的数据。于是我以为代码写错了其实数据根本没提交白排查了半天。这个属于数据库基础设施的知识不算插件 bug但遇到的时候很容易让人困惑。所以后来我再遇到“查不到刚写入的数据”这种怪现象第一反应就是先看看是不是有未提交事务确认提交后再查就正常了。4.5 结果集太大IDE 直接卡住我试过连续执行几条不带 LIMIT 的查询其中有一条关联了好几个表结果返回来十几万行IDEA 的下方结果区直接开始转圈滚动都有点卡。这个体验很差后来我学乖了凡是查询操作第一版 SQL 我一定加 LIMIT先确认数据量和数据内容再决定要不要扩大范围。JavaAI 的执行区域里其实可以配置默认的行数上限我建议把它设成 500 或者 1000日常查数据足够用也不会把 IDE 拖垮。要是真需要全量数据再临时把限制放开或者干脆用数据导出功能走专门工具。5. 一些个人经验和小技巧5.1 查询之前先定好 LIMIT前面已经提到过这里想再单独唠叨几句。开发查数据和报表查询不一样多数时候我们只是想看个大概。所以你写 SQL 的时候默认养成写LIMIT 100的习惯既能快速出结果又不至于把开发库压到告警。这个习惯在山穷水尽追查一个刁钻 bug 的时候特别好用因为它让你先看到数据长什么样再决定下一步。5.2 利用“选中片段”只跑自己关心的语句如果 SQL 文件里有好几段语句有的还是历史遗留的调试语句直接整体执行容易出事。我的做法是永远只选中需要执行的那一段然后触发执行快捷键。这样既保证安全也减少无谓的执行时间。尤其当文件里有 UPDATE、DELETE 这类语句时选中再跑基本不会误伤。5.3 让 AI 写 SQL但别完全依赖JavaAI 的 AI 写 SQL 能力确实能帮你省时间比如不记得某个函数怎么拼、某个 join 条件怎么组织直接描述需求让它生成。但我的体会是它对你当前项目表结构的理解并不一定完整准确尤其是字段命名比较随意的业务表它生成出来的 SQL 有概率引用了不存在的字段。所以我一般把它当“草稿生成器”用先让它写然后我在编辑里快速过一遍检查表名、字段名、条件逻辑确认没毛病再执行。如果需要的是非常复杂的 SQL我会拆成几步每一步单独描述避免一步到位生成的语句绕了远路。5.4 高频查询保存成模板有些查询一周要跑好几次每次都要重新敲或者重新让 AI 生成也挺烦。我会把这些常用查询整理成一个小的 SQL 文件放在项目里专门的目录下比如 docs/sql 或者 db/query下次直接打开文件、选中、执行就行。这个做法的额外好处是团队里的新同事接手项目时能看到这些整理过的查询快速了解核心表的常用访问方式比在群里问人要快得多。5.5 给生产环境单独搞一个低权限账号最后一条也是我最想让所有开发同事看到的。不管用什么工具连生产库一定不要用管理员账号。我自己的习惯是套一个只读账号连过去这样日常排查数据没有任何问题但所有写操作天然就被拦住了。JavaAI 的执行功能本质上是直通的它不会替你做太多安全校验所以安全边界得自己设。你可以在 Database 面板里给生产数据源专门建一个连接配置用低权限账号登录然后用 JavaAI 执行查询就安全多了。平时我宁愿多花两分钟把账号配好也不想在凌晨三点排查生产问题时因为一个误操作把自己搭进去。5.6 快捷键能改就改成顺手的位置插件一般自带一个默认快捷键但默认键位不见得顺手尤其是我习惯左手操作数值区右手握鼠标有一些组合键按起来很别扭。我拿到插件之后第一件事就是去 Keymap 设置里把“执行 SQL 语句”的快捷键改成一个我舒服的键位。这不算什么高深技巧但提升很明显。因为查数据的动作是极其高频的每一个多余的按键动作积攒下来都是看得见的时间消耗。我改完之后基本做到了“选中即查、查询即看”整个过程顺畅到没有存在感。如果你还在手动去菜单里点来点去我建议先花一分钟把快捷键调好回报率特别高。6. 最后说点实在的用了这个功能快半年我最直观的感受是查数据这件事终于回到了它该在的位置——它不是开发流程里的一道“关卡”而是像看日志、看变量一样抬手就能完成的动作。以前我遇到疑难问题去数据库查数据会有一种“又要切窗口好麻烦”的心理惰性很多时候宁可瞎猜或者加日志打点也不愿意去看数据。现在没有这层心理负担了该查就查反而定位问题的速度快了很多。当然我也一直提醒自己这只是个“执行”工具不是万能的数据库管理台。它帮你省掉的是机械性的切换和等待真正要搞懂的东西比如表结构设计、索引怎么建、SQL 怎么优化还得靠平时多积累。工具只是放大器你的判断力才是核心。不过至少在“查数据”这个最日常的小事上我现在是真的离不开它了。