DataGrip 中的更新 SQL 无效
Posted
技术标签:
【中文标题】DataGrip 中的更新 SQL 无效【英文标题】:Invalid update SQL in DataGrip 【发布时间】:2017-09-14 03:41:09 【问题描述】:我在我的 DataGrip 上写了一个 mysql 更新 SQL 来更新错误的数据:
update common_express_track set step = 135 where express_id in (33, 235, 237) and business_source = 0 and step = 0 and content = 'Out For Delivery' order by content;
我执行了它,控制台显示“61 行在 7s 530ms 内受到影响”,然后我执行了另一个查询语句以确保数据已被修改。
select * from common_express_track where express_id in (33, 235, 237) and business_source = 0 and step = 0 and content = 'Out For Delivery' order by content;
然后控制台显示“0 rows retrieved in 3s 751ms”。
但是当我重启DataGrip并再次执行查询语句时,我得到了61行,这意味着更新语句不起作用,我不知道为什么,是因为缓存还是什么?
如何解决这个问题?
【问题讨论】:
使用 mysql 控制台并在那里检查 您的SELECT
的WHERE
包含step=0
,而UPDATE
将其设置为135....
@Usagi Miyamoto - 是的,但剩下的问题解释了原因,没关系
在句子中`但是当我重新启动datagrip并再次执行查询语句时,` - 你的意思是第二个查询吗?
顺便说一句,“重新启动 datagrip”是什么意思?
【参考方案1】:
当你执行查询时你应该使用Autocommit
然后通过单击数据库视图中的表,您将看到refresh
尝试在查询中使用Autocommit
,在浏览数据时尝试使用refresh
。它应该会有所帮助。
【讨论】:
好的!它有效,我将事务控制选项更改为自动,这一次数据真的被修改了。非常感谢你!顺便说一句,你能告诉我手动选项和自动选项之间的区别吗? 如果没有自动提交,您应该单击提交以真正执行您的查询,但您也有可能回滚。我建议在生产数据库上使用此选项(如果您在更新前不选择),但是当您开发时使用自动提交并确认任何查询更简单,那么您将不会忘记这一点。 自动和手动模式:提交按钮或⌘Enter→提交您的数据,这意味着您的本地更改(它们被突出显示)提交到数据库。如果您处于手动模式,则不会提交此事务。 Revert Selected 从上下文菜单或 ⌘⌥Z (它曾经是 ⌘Z ,但 Revert 不是 Undo,对吗?)在选定的行上 → 恢复选定行的未提交的本地更改。 仅在手动模式下:提交按钮或⇧⌘⌥Enter→提交事务。如果您有未提交的本地更改(再次突出显示),它们将在提交之前自动提交。回滚按钮 → 如果事务未提交则回滚。以上是关于DataGrip 中的更新 SQL 无效的主要内容,如果未能解决你的问题,请参考以下文章
Snowflake 是不是向 DataGrip 等 SQL 客户端提供解释计划中的成本信息?
JetBrains发布DataGrip 1.0——数据库与SQL领域中的瑞士军刀