做Python开发的同学，尤其是写过Django、Flask、SQLAlchemy项目的人，大概都有过这样的经历：代码里调试完ORM，还要再开一个数据库客户端看数据到底变成什么样。我早期就是这样，PyCharm里写完代码，切到另一个工具刷新表、看SQL输出，来回折腾，效率很低。后来有一次在研究PyCharm右侧栏的时候，发现它居然自带一个完整的数据库工具，当时用了一次就决定把其他客户端丢掉了。
PyCharm专业版里的这个数据库工具，本质上是把一套跟独立数据库IDE几乎同级别的能力直接塞进了Python开发环境。它不只是能连数据库、执行SQL，还提供表结构浏览、数据编辑、ER关系图、数据导出、查询计划分析，甚至还能跟Django、SQLAlchemy的模型联动。对于不依赖命令行、希望“一个软件搞定开发全流程”的人来说，这大概是Python生态里被低估最多的生产力工具。
这篇东西我准备从配置讲起，把日常最常用的功能、和Python项目协同的玩法，以及我踩过的几个坑都梳理一遍。不管你现在是刚接触PyCharm，还是用了很久但没碰过Database工具窗口，这都能省下你不少试错时间。
1. 为什么我放着现成的数据库客户端不用，偏用PyCharm自带工具
先说个很多人会问的问题：我已经装了专门的数据库客户端，为什么还要用PyCharm里的这个工具？我的答案很简单：因为离代码近。你写SQL、看数据、改表结构的时候，不一定要离开编辑器，真正需要的是一个“能看懂Python代码语境”的数据库操作环境。
1.1 这个工具到底是什么
PyCharm里的数据库工具入口叫Database窗口，在编辑器右侧边栏，主菜单View -> Tool Windows -> Database可以打开。它支持的关系型数据库相当全，MySQL、PostgreSQL、SQLite、SQL Server、Oracle都在列表里，新版连MongoDB、Redis这类非关系型也能连。也就是说，你日常项目里能碰到的存储基本都能接进来。
我第一次打开这个面板的时候感觉有点懵，因为它的信息密度比普通客户端高，左边是一棵数据源树，展开之后能看数据库、schema、表、视图、存储过程、函数、触发器等对象，右边是当前选中对象的属性或者数据预览。实际上整个交互思路和那些主流数据库IDE是一致的，上手成本没有想象中高。
值得强调的是，这套数据库引擎不是随便做个连接器糊弄人的。它包含了完整的SQL解析、代码补全、索引感知、执行计划可视化，甚至能识别外键关系。你在写JOIN的时候，它能根据表结构提示可能的关联条件。这种级别的功能在一个Python IDE里面出现，对后端和数据分析场景来说确实方便。
1.2 和传统数据库客户端相比，优势在哪
传统客户端和PyCharm数据库工具不是谁替代谁的关系，而是使用场景的差异。跟我以前常用的那种独立客户端相比，PyCharm内置工具有三个地方让我感受最深：
第一是上下文不需要切换。我改完Django的Model，生成迁移，然后在数据库工具里刷新schema，马上就能看到表结构变化。整个过程在一个窗口里完成，不需要频繁切换应用。
第二是SQL结果和Python逻辑可以直接打通。举个实际例子，你在SQL控制台里跑了一个查询，得到结果集之后，可以直接右键导出成JSON、CSV，甚至复制成Markdown表格贴到文档里。这种“从数据到代码再到呈现”的顺畅感，是独立数据库客户端给不了的。
第三是它的连接配置可以跟着项目走。比如你把一个项目的数据库配置好之后，PyCharm会把这个数据源的配置文件保存在项目的.idea目录里，同事克隆项目后带上配置，就能直接使用同一个数据源的连接入口，省去了重新填主机名、端口、密码的步骤。当然，密码是否共享是安全设置的问题，这个后面说。
还有一个容易被忽略的点:它不只是数据库GUI工具，同时还是一个完整的SQL编辑器。代码高亮、语法检查、格式化、重构都支持，甚至还能把某张表的建表语句复制出来。对于不爱依赖命令行的人来说，这比pymysql一行行写脚本要直观得多。
1.3 适合谁用
你要是问我什么人最适合认真用这个工具，我总结有三类:
第一类是Django/Flask开发者的主力场景。每天主要工作在Python代码里，偶尔需要看数据库的实时状态，这种人用它最舒服。第二类是数据分析相关的朋友，习惯用Pandas处理数据，但又需要快速验证SQL查询结果，这个工具相当于一个可视化SQL控制台，和Jupyter协同也自然。第三类是那些喜欢所有工作都在同一个IDE里完成的人，不想装一大堆软件，PyCharm里能连App能连数据库，自然就省事。
如果说到不适合，可能就是专职DBA或者要处理超大规模数据仓库的人，他们需要更专业的性能分析和集群管理能力，建议还是用专门的数据库运维工具。不过日常开发和中小型项目的数据库操作，这个内置工具绰绰有余。
2. 连接配置：把数据库接进PyCharm的完整流程
可能有人会卡在第一步，因为PyCharm首次连接数据库时需要下载驱动，这个过程在国内网络环境下偶尔会失败，很多人就在这里放弃了。其实配置本身不复杂，我把常见情况都过一遍。
2.1 打开数据库面板有几种方式
最直观的方式是看PyCharm窗口右侧的竖排侧边栏，如果项目没配置过数据库，一般有一个Database的按钮，点一下就把工具窗口打开了。如果没有这个按钮，也可以从主菜单选择View -> Tool Windows -> Database，效果一样。
还有一种方式是走设置流程：File -> Settings(或者Preferences) -> Tools -> Database。这里的管理界面和工具窗口是同一套，都能新建数据源。如果你装了多个PyCharm插件，有些时候数据库选项会折叠在More Plugins里，这时候需要先到插件市场把Database Tools and SQL插件启用，这个插件本身在专业版是自带的，如果找不到，多半是因为被手动禁用过。
打开面板之后，看到左侧的Data Sources列表就是数据源管理区，在这里可以新建连接。新建的方式有两种：点击左上角的+号，或者直接右键Data Sources区域选择New。
2.2 一步步配置连接
我以最常见的MySQL和PostgreSQL举例，SQLite单独说。
配置MySQL时，选择MySQL数据源之后，基本信息要填主机、端口、用户名、密码和数据库名。端口默认3306，一般不用改。下拉框里会提示选择数据库版本，主要是为了让驱动用对应兼容的方式连接，不确定就选默认或选一个和你服务器版本接近的版本。填完之后，建议先点击Test Connection，它会显示连接是否成功，并且给出驱动缺失的提示。
如果是第一次连接，PyCharm会提示Download missing driver files，点击下载即可。这一步会从仓库拉取驱动，耗时跟网速有关。下载完成后，Test Connection应该就能通过了。
配置PostgreSQL时逻辑基本一样，主要区别是数据库类型选择PostgreSQL，然后填主机、端口、用户名、密码和初始数据库。PostgreSQL驱动下载一般比MySQL顺利，可能是因为依赖数量少一些。需要注意PostgreSQL默认有一个postgres数据库，如果你要连的是业务库，在Database字段里填业务库名字就行，连接成功后在数据源树上能看到这个库下的public schema、表、视图等对象。
SQLite配置反而是最省事的。选择SQLite数据源后，它不要求主机和端口，只需要指定一个数据库文件路径。可以是绝对路径，也可以选择项目相对路径。对于本地开发、测试环境或者一次性数据排查，SQLite连接非常轻量，添加完刷新就能直接看到表和索引。
填完信息之后有几个可选项值得关注：在“高级”标签页里有useSSL、characterEncoding之类的连接参数，如果你连的是公司内部强制SSL的数据库，需要在这里把useSSL置为true。还有“SSH/SSL”标签页，可配置SSH隧道，这个对连接只能通过堡垒机访问的生产库很关键，但配置方法要稍微复杂一些，下面单独展开。
2.3 驱动下载失败的常见原因与处理
这是新人最容易劝退的环节。点击Test Connection之后，如果出现类似Download missing driver files失败或者长时间卡住，常见原因其实是网络无法直接访问驱动仓库。解决办法有几个：
第一种是手动下载驱动JAR包。到对应的数据库驱动官方下载地址或者Maven中央仓库找到对应版本的JAR，然后回到PyCharm的数据源配置界面，在“驱动”下拉框中选择“手动设置”，把JAR包路径加进去。
第二种是给PyCharm配置代理，让驱动下载走代理。这个在Settings里找到Appearance & Behavior -> System Settings -> HTTP Proxy，设置一个网络代理即可。不过这会涉及你本地的网络环境，我这里不展开讲，大家根据实际情况处理。
第三种办法是下载稍微老一点的驱动版本，因为有些时候是最新的驱动包对旧数据库协议不兼容导致连接报错，换一个版本反而稳定。我实际遇到过MySQL 5.7连不上MySQL 8.0驱动的情况，这时候把驱动版本切到对应的旧版本，连接就正常了。所以驱动下载失败或者连接报错时，不要一味追求最新版本。
驱动问题解决之后，还是建议把Test Connection多测几遍，确认能通过再点OK保存。因为有些隐藏的坑，比如时区、SSL、防火墙白名单，测试连接时能看得更清楚。
2.4 SSH通道和容器场景的补充
生产环境里的数据库经常不允许你直接通过3306/5432端口访问，而是要求先登录一台堡垒机。这种情况下，PyCharm的SSH隧道功能就派上用场了。
在数据源配置界面的SSH/SSL标签页里，勾选“使用SSH隧道”，然后配置SSH主机、端口、用户名、认证方式（密码或密钥）。配置好之后，PyCharm会把本地数据库连接通过SSH隧道转发过去，这时候你在JDBC配置里填的主机和端口可以继续填数据库内网地址，也可以填localhost，整体上是安全的。
如果你要连的是Docker容器里跑的数据库，配置思路也差不多。先把宿主机的端口映射到本机，然后连接localhost+映射端口即可。容器场景里最需要注意的是端口映射冲突，如果你本地已经有另一个数据库占用了同一个端口，Docker启动会报错，或者连到了错误的实例，排查时先确认端口再连PyCharm。
这里有个小经验：每次改完数据源配置，建议先点一下“刷新”按钮或者重新连接，因为PyCharm的Schema缓存不会自动跟随数据库变更。你建了新表之后，数据库树里不刷新是看不到的，这时候不是连错了，而是缓存没更新。
3. 日常开发最常用的功能拆解
连接配置好之后，这块才是正文。我数了一下，平时真正高频使用的数据库功能大概有八个，从写SQL到看结果、画关系图、导出数据、生成代码都覆盖了。每拆一个我都会说说使用思路和容易踩的细节。
3.1 写SQL与执行：从选中拖到运行
在PyCharm里执行SQL有两种常见操作。第一种是在“查询控制台”里直接写。右键数据源，选择New -> Query Console，就会打开一个新的SQL控制台，相当于一个临时文件，你可以随意写查询语句。第二种是新建一个.sql文件，把它关联到某个数据源，然后在文件里写SQL。两者的区别在于控制台默认绑定当前数据源，而.sql文件可以在右上角切换数据源，适合要跑多个库的场景。
执行的时候，如果只想运行某一条语句，用鼠标选中那部分SQL，再点击执行按钮（绿色三角）就行。如果没选中，PyCharm默认执行当前光标所在的一条完整语句。这个行为细节很多新手不知道，经常一次性把整个文件执行了，结果建表语句重复执行报错。
执行结果会显示在下方Result面板，默认是表格形式。你还可以选查看Explain Plan，用图形化方式看SQL走了哪些索引、每步消耗多少行。注意Explain Plan点击按钮时需要确保当前选中的是你要分析的SQL，否则会默认为你执行了一次分析。
3.2 自动补全与SQL格式化
这个话题单独拿出来说，是因为PyCharm的SQL补全比很多独立客户端做得还要细。它不只是补全关键字，还能根据当前数据源的表结构，补全表名、字段名、别名。写JOIN的时候，如果表和表之间存在外键关系，甚至能提示出ON a.id = b.user_id这样的关联条件。
搭配格式化功能之后，维护复杂SQL要省心不少。右键选择Reformat Code，PyCharm会把一团乱麻的SQL重新排列，缩进、换行、关键字大写都按你设置的Style来。如果你的团队有SQL书写规范，可以在数据库工具设置里配置关键字大小写风格。
我自己的习惯是：在本地控制台写一条复杂SQL，先用格式化整理，再复制到代码里，这样代码里嵌入的SQL字符串就是工整的。有时候在Python代码里看到那种几个空格连着的多行SQL，多半是没经历过PyCharm格式化。
3.3 数据库树导航与筛选
左边的数据库树默认展示了所有schema和对象。随着表数量变多，一张张找表太慢，这时有两个功能很实用。
第一个是“过滤”功能。点击数据库树顶部的漏斗图标，输入关键词，树里就只显示名字匹配的表或视图。这个过滤不是精确匹配，而是模糊包含，效率很高。
第二个是“右击跳到代码”。如果你已经打开了某张表，可以在树中右键选择Jump to Query Console，直接进入关联该表结构的SQL控制台。或者你正在写SQL，按快捷键可以直接跳到数据库树中当前表的位置。
还有一个小技巧：表结构面板支持按列名搜索字段。比如你想确认某个字段到底叫什么名字，直接在表结构里搜索，不需要一行行扫。
3.4 表数据查看、编辑与筛选
双击数据库树中的表名，会打开这个表的数据预览，默认最多显示一定行数（可以设置上限）。在这个数据网格里，可以直接修改单元格，PyCharm会自动生成UPDATE语句并提交。这个功能对临时修数据很管用，但我还是要提醒一句：修改时要留意事务状态，尤其是线上库，别一路上手就改。
数据预览面板上有一个过滤行，能直接输入条件过滤数据，比如status = 1或者create_time > '2024-01-01'。它会生成WHERE条件去查询，而不是把全表拉到内存里筛，这一点性能上做了优化，但前提是你输入的语法得是SQL表达式的写法，不是正则。
如果你只想看某几条数据，也可以在“行过滤器”里构造条件。表格支持多列排序，点击列头即可，这个操作在一些老版本客户端里反而没有，体验比较跟手。
3.5 ER关系图：一张图看懂全库
当数据库表数量超过几十张，靠肉眼理解外键关系就很吃力了。PyCharm里提供了一个很有价值的可视化功能：在数据库树中多选几张表，右键选择Diagrams -> Show Diagrams，就能生成一个ER关系图，展示表之间的外键关联。
图表的布局可以手动拖动，还能以保存图片的方式分享到团队文档里。我记得有一次排查一个老系统的业务逻辑，全表将近五十张，看半天文档都不明白“订单”和“支付流水”怎么关联，后来把相关几张表拖进Diagram，一分钟就看清了外键链路。
这个小功能不该被低估。我建议你在每次参与新项目时，先花十分钟把所有核心表生成ER图，比看任何技术文档都直观。至于执行计划和关系图细节，如果版本不同菜单位置稍有变化，可以直接在表上右键，搜索“Diagram”关键字即可。
3.6 数据导出与导入
查询结果面板上有一个Export Data按钮，可以把当前结果集导出为CSV、TSV、Excel、JSON、XML等格式。这个功能我几乎每周都在用，尤其是需要给非技术人员一份临时数据报表时，直接导出Excel最省事。
导出的时候有几个选项需要留意：第一个是“包含表头”，如果你要把数据导出来再用程序处理，表头有时反而要手动去掉；第二个是分隔符，CSV默认逗号，但有的时候拿来贴到SQL语句里，反而制表符更合适；第三个是“导出行数限制”，默认导出当前结果集所有行，如果数据量太大，建议先在SQL里加LIMIT再导出。
导入数据则更多是配合测试环境使用。右键数据源或某张表，选择Import Data from File，可以导入CSV或JSON文件。这里强烈建议先小文件试一次，因为编码问题非常常见，CSV文件经常是Excel导出的GBK编码，导入时PyCharm默认按UTF-8读，就会出现中文乱码，这时候需要调整file encoding。
3.7 查询控制台与跨库查询
查询控制台不只是一个空白SQL文件，它还能绑定多个数据源。你可以在同一个控制台里打开不同库的表，如果表名不冲突，甚至能做跨库JOIN。这个能力在对比线上环境和本地环境的数据时很有用。
但是跨库JOIN需要注意权限和配置，不同的数据库实例之间做跨库关联会受数据库侧权限限制，PyCharm只是尽力去拼，实际能不能支持取决于引擎本身。比如两个MySQL实例之间，它最终会尝试把两端数据拉到一个引擎里处理，所以数据量大时性能会明显下降。我一般不推荐正经使用跨库JOIN，对比数据时用控制台分别跑两条SQL，结果通过并列窗口对比可能更稳妥。
3.8 从表结构生成代码或SQL
这是隐藏生产力按钮。右键某张表，你会看到Generate菜单，里面有DDL to Clipboard、DDL to Console、SQL Generator等选项。最常用的就是从已有表复制出建表语句，粘贴到另一个环境执行。
另外，在数据库表上还可以通过右键生成自己需要的代码片段。虽然后端项目的数据模型大部分用ORM生成，但有时候我需要快速造一批模拟INSERT语句，SQL Generator就能帮上忙。对于早期没有用ORM的老项目，迁移时把表结构导出成SQL脚本这个功能几乎是救命级别。
还有一个容易被忽视的细节：在“Generate”菜单里选择“Generate Python...”可能不是每个版本都默认出现，因为它依赖的语言插件选项不同。如果你只想要一份Python风格的字段映射，把表字段复制成字段名 = 字段类型这样的结构，可以直接用“Copy fields references”之类的功能，不同版本措辞略有差异，找到类似Copy的入口就行。
4. 与Python项目协同：这才是PyCharm的独家优势
纯数据库操作部分已经够用了，但既然你是在PyCharm里用，我更建议把数据库工具和Python项目结合起来，这里产生的价值是其他独立数据库客户端完全给不了的。
4.1 Django项目的联调体验
如果你在用Django开发，PyCharm专业版本身就有Django支持配置。在Settings里把Django框架的settings.py路径设置好之后，编辑器就能识别ORM模型字段。这时候数据库工具再接上同一个数据库，你改完models.py，执行python manage.py makemigrations和migrate，回到数据库工具里刷新Schema，新表或者新字段就出来了。
这个套路看起来简单，但真的比原来的工作流高效。以前我需要刷一次数据库，再回到客户端里右键刷新，而且表和ORM字段命名经常有映射差异，调试半天。现在所有变更都在同一个IDE里完成，数据库树上的小蓝点也会提示Schema有所改变，状态一目了然。
有一个坑要提醒：Django里给模型起名喜欢用小写和下划线，数据库表默认也是这种风格，但数据库树的排序和搜索默认按字母顺序，你找模型对应的表时会有种对不上号的感觉。建议在数据库树中打开“按名称排序”，同时利用过滤功能快速定位。
4.2 在查询控制台里跑迁移和调试SQL
可能有人会问：Django的迁移不是应该用命令执行吗？为什么要在查询控制台里跑？这里的场景其实是非迁移类的SQL操作。比如我要往已经存在的表里加一个索引，或者需要一个复杂的UPDATE，直接在查询控制台写好SQL并执行，比写临时脚本再删掉要简单得多。
SQL执行完，如果你想在Python代码里快速读取结果，还可以把查询结果导出成JSON的Shape，直接塞进Python字典结构。虽然这不是Django直接调数据库，但作为临时数据处理，这个组合很顺手。
调试SQLAlchemy项目的时候，这个工具的价值同样明显。SQLAlchemy的ORM调试过程中，很常见的问题是生成的SQL和你预期不一致。这时可以直接在查询控制台里手写一条等价SQL对比结果，或者把实际的底层表数据拉出来查看，定位是ORM逻辑问题还是数据本身的问题。这种“双开”的调试体验，对理解ORM的行为非常有帮助。
4.3 数据库工具与Pandas结合
数据分析场景也值得一提。PyCharm的数据库工具可以连接生产环境数据库，查询出结果后导出CSV/JSON，然后用Pandas、Jupyter读取。虽然这个流程看起来多了一步导出，但对于不熟悉直接写pandas.read_sql的人来说，用可视化查询先验证数据形态，再导出进行分析，这是一种很稳的路径。
更进阶一点，你可以把数据库工具中的连接配置和本地的Python脚本结合起来。PyCharm数据源默认并不直接给你的Python代码提供连接凭据，但你可以按这个配置信息，在代码里用一个配置文件维护一样的连接参数。这就是很多项目的本地开发配置来源，在数据库工具里调试成型的连接串，再交给代码复用，能减少很多连不上数据库的低级错误。
4.4 把连接配置同步给项目团队
前面提到，数据源配置是存在项目.idea目录里的。如果你们团队使用PyCharm专业版，而且大家共用同一个开发库，把数据源配置提交到版本控制里，同事拉到代码后就能直接用。数据库的密码默认不共享，除非你在数据源配置里勾选了允许保存密码，所以我建议共享配置时只共享连接信息，密码让每个人自己输入。这样既方便又避免把数据库密码明文扔进Git仓库。
这里需要强调安全习惯：不要把生产环境的完整密码提交到任何仓库里，哪怕库是私有库也有泄露风险。数据库工具里的密码保存选项，我一般只在本地开发环境勾选，生产环境一律不保存。
5. 我踩过的坑和排查手册
用这个工具几年下来，遇到过的坑零零总总算起来真不少。我挑几个典型且容易再犯的写出来，做成一个速查式的记录，希望能帮你在遇到同样问题时直接找到方向。
5.1 驱动下载一直失败怎么办
连接配置的时候，驱动下载失败是最高频的卡点。我建议按这个顺序排查：先确认网络能不能访问外网；再确认PyCharm设置里HTTP Proxy是不是被配置成了某个无效代理；最后看是不是没有下载权限。如果以上都是正常的，那就是网络到Maven仓库的链路问题，这时候手动下载驱动JAR放到本地，再在数据源驱动配置里指定本地路径，基本能解决。
千万不要反复点下载按钮，这样只会重复同一个失败结果。手动装驱动时注意Java版本兼容，某些老驱动在高版本JDK下启动会报错，如果出现协议相关的运行时错误，尝试换一个驱动版本。
5.2 时区问题和8小时偏差
连接数据库之后查询时间字段，如果发现时间比真实时间少了8小时，基本可以确定是JDBC连接时区设置不对。解决办法是在连接URL的高级参数里追加serverTimezone=Asia/Shanghai，MySQL的驱动对时区参数比较敏感，PostgreSQL则主要是受系统时区和数据库时区影响。
这里有个小细节：PyCharm内部查看时可能使用本地时区显示，但你在导出数据或者复制单元格时，拿到的是原始时区下的字符串。如果你拿导出结果去做时间分析，务必确认时区是预期的那个。曾经我就因为忽略时区，夜间跑批算出来的日期差了一天，排查了很久才发现源头是时区参数。
5.3 大表查询卡顿怎么办
如果数据表超过百万行，直接用表数据预览模式打开会非常慢，因为Grid默认会拉取较大的数据量。解决办法有两个：一种是右键表 -> Open Data，只看到头几百行；还有一种是在SQL控制台写带LIMIT的查询，按需拉数据。
查询结果集特别大的时候，PyCharm会有内存压力，最好在SQL里做聚合或者加WHERE条件。如果你确实需要在结果集里做二次筛选，可以用结果集顶部的过滤框，它在内存里做筛选，比重新跑SQL快，但内存占用不会减少。
5.4 修改数据库密码后的连锁反应
数据库密码改掉之后，PyCharm里的数据源会报连接错误。这时你再点Test Connection，它提示失败，但有时候不是密码错误，而是旧的连接池会话没有释放。解决办法是右键数据源，选择Disconnect，然后再重新Connect。如果还是失败，把数据源删除重新建一次，这样能确保会话和缓存都清干净。
这个坑在团队协作环境特别常见，因为密码经常被轮换。遇到连接报错，不要第一时间怀疑驱动或网络，先确认是不是密码问题，再检查有没有连接池残留。
5.5 我的几个调试排错心得
最后分享几个我在实际操作中养成的习惯。
第一个习惯是给每个环境的数据源命好名。比如dev-mysql-local、prod-pg-readonly，虽然这只是命名问题，但在切换环境时能避免很多低级错误。我甚至会把只读环境专门建一个只读数据库账号，万一在PyCharm里手滑执行了UPDATE，还能多一层保障。
第二个习惯是查询控制台文件及时整理。PyCharm允许你给SQL控制台文件建目录，我会按照模块把分析用的SQL归档，比如/sql/order_analysis.sql。这些文件跟着项目走，下一次排查问题时直接打开就能复用。
第三个习惯是“先Diagrams后动手”。接手一个老项目，不管你有没有文档，先把核心表拖进关系图看一眼。这个习惯至少帮我避开了好几处“以为改了主表就够”的坑。
第四个习惯涉及误操作防护：开启只读模式。在数据库工具中双击打开表后能看到一个锁状的按钮，点击它可以进入只读模式，防止不小心修改真实数据。我在排查线上问题时，一定会确认这个锁有没有打开，再谨慎操作。
结尾前的一个小经验
要说使用PyCharm数据库工具这么久，最让我上头的其实是SQL执行历史和结果对比。你在查询控制台里跑过的每条SQL，PyCharm都会记录执行历史，命令行里可以按快捷键调出历史，哪怕你忘了之前写过的条件，也能从历史里捞回来。这个功能我每天都在用，但很少见到有人专门提它。
如果你现在还没用过Database窗口，我的建议是先别急着装更多客户端，把这套内置工具用顺，大概率你会发现Python开发和数据查询之间的距离真的可以缩到很短。等用熟了，再回看那些需要频繁切换软件的日子，会感觉轻松很多。
