MySQL Workbench删数据不生效，终端执行同语句却正常的解决方法

绝大多数场景会遇到的核心问题 #

• 事务自动提交未开启，执行的删除操作未实际提交
  终端连接MySQL时默认开启autocommit参数，执行DELETE语句后会立刻把变更持久化到磁盘；但MySQL Workbench的默认配置中，SQL编辑器是关闭自动提交功能的，你在窗口里执行完目标删除语句（即delete from passwords.passwords where website = 'nowebsite';）后，操作只是临时挂在当前会话的未提交事务中，根本没有写入数据库，从外部看就像删除没有生效。
  验证方法：在Workbench执行完这条删除语句后，紧接着在同一个查询窗口运行select count(*) from passwords.passwords where website = 'nowebsite';，如果查询返回值为0，但重新刷新表数据后原来的目标行还存在，基本可以确定是事务未提交的问题。
  解决方式：
  • 即时修复：点击SQL编辑器工具栏上的对勾形状的*Commit（提交）*图标，或者手动执行commit;语句提交当前会话的所有未提交变更；
  • 长期调整：在设置里开启自动提交功能，依次打开 编辑 > 首选项 > SQL编辑器，勾选“自动提交查询”选项，重启数据库连接后就会默认生效，和终端的行为保持一致。

连接上下文不一致的排查 #

• 核对当前操作的MySQL实例是否和终端完全匹配
  MySQL Workbench支持同时管理多套MySQL连接，操作过程中很容易出现窗口误切的情况：比如你当前执行删除的查询窗口，实际连接的是本地搭建的测试MySQL实例，而你终端连接的是远程服务器上的生产MySQL实例，两边的库表数据完全独立，自然会出现终端能删掉目标行、Workbench里执行完数据还在的错位现象。
  验证方法：分别在Workbench和终端的MySQL会话中执行select @@hostname, @@port, current_user();，对比两次输出的主机名、服务端口、登录账号是否完全一致，即可快速确认是否连错了实例。

锁阻塞导致删除操作未真正执行 #

• 排查长事务带来的元数据锁阻塞
  如果你在Workbench里之前通过左侧SCHEMA栏打开过目标表的可视化浏览界面，这个面板默认会持有一个长时运行的只读事务，对目标表加共享锁。后续在查询窗口执行的DELETE语句，会因为拿不到排他锁一直处于阻塞等待状态，虽然SQL编辑器不会弹出报错，但删除操作根本没有真正执行完成。
  验证方法：在Workbench中执行show processlist;查看所有会话状态，找到执行DELETE的会话，若状态显示Waiting for table metadata lock即可确认是锁阻塞问题。
  解决方式：关闭之前打开的老旧表浏览标签页，或者通过kill 对应长事务的会话ID指令强制结束占锁的会话，释放元数据锁之后重新执行删除语句即可正常生效。

界面缓存造成的“假未删除” #

• 排除结果集缓存的误导
  MySQL Workbench的表可视化浏览面板不会自动同步数据库的实时变更，如果你已经成功提交了删除操作，浏览面板还是会显示之前缓存的旧数据，很容易误以为删除没有生效。这种情况只要点击浏览面板上方的圆形刷新按钮，就能看到数据库存储的真实最新状态。

内容的提问来源于stack exchange，提问作者hasan ramp