【问题标题】:MySQL wrongly updates integer column when it is updated second timeMySQL第二次更新时错误地更新整数列
【发布时间】:2012-11-08 15:58:45
【问题描述】:

我有一个非常奇怪的问题,这让我整天发疯。我有一个包含几列的简单 MySQL 表。一列是 int(11) NULL。当我更新它的值时,它按预期工作。但是,当我第二次更新它的值时,它被分配了“0”值。

我已经在我的 MySQL 5.1.58-1ubuntu1 和其他 MySQL 5.0.96-community 上测试了相同的行为,并且两者的行为完全相同。所以这显然不是一个版本的 MySQL 的问题。

我很难解释,但我附上了 2 个屏幕截图,可以更好地告诉你哪里更好。

第一个屏幕截图是我正在更新的表格的结构:

这里显示了正在执行的 SQL 查询,您可以在其中看到,第一次更新是正确的,第二次在“invoice_number”列中无故产生“0”值:

我是否忽略了一些明显的东西?它真的让我发疯,因为它对我来说没有任何意义......

提前感谢您的任何帮助...

编辑:我尝试在我的查询中只使用数字,这是结果(对我来说也很奇怪):

【问题讨论】:

  • +1 表示奇怪的问题,这让我整天发疯。我知道这种感觉
  • 为什么要在代码中指定字符串? '35' 是一个字符串,35 是一个数字。你为什么不做= 35 WHERE id = 55
  • 不要对数字列使用字符文字'55'55' 不是数字,而是字符串。你应该使用55(如果奇怪源于一些奇怪的隐式类型转换,我不会感到惊讶)
  • 您似乎在使用 phpMyAdmin 或类似工具。您是否从第二个屏幕截图底部的该文本区域运行了所有查询?如果是这样,可能是查询正在被缓存并且您从缓存中获取结果(这意味着您的工具中存在错误,而不是 MySQL)。您是否尝试过分别运行这些查询,一次一个?
  • @Dems 我同意,但不是服务器自动尝试将字符串解析为数字吗?

标签: mysql sql


【解决方案1】:

这不是答案,但 cmets 越来越拥挤。您显示的行为确实表明存在某种问题,但更有可能出现在您用于连接数据库的工具中,而不是数据库中。

单引号的问题是转移注意力(即分心)。即使 '55' 的解释与 55 不同,它在 where 语句中也会以相同的方式解释。此外,“35”有效,但“30”无效。

一个关键的见解是删除引号时的失败。声明:

update i_orders
    set invoice_number = 30
    where id = 55

不应该查找 30 的列索引。您看到的未知列错误表明发送到数据库的查询不是您在工具中看到的查询。

您可以在数据库中记录查询以查看实际发送的内容吗?

【讨论】:

  • 记录查询正是我今天早些时候发疯时所做的。第二个屏幕截图中显示的这 4 个查询正是从 MySQL 日志中复制的行。
  • 整数问题比较好奇。 MySQL 不应该在 set 语句中寻找列引用。字段列表听起来像是它属于插入中的表名之后。我看不到如何解析您的查询以获取该错误。也不知道为什么字符串不会导致这个问题。
【解决方案2】:

好吧,我终于想通了。问题出在其他地方,而不是 MySQL 本身。我已经从 MySQL 查询日志中复制了我的问题中显示的所有 SQL 查询,所以我从不怀疑可能有什么奇怪的东西。但是,“35”值的开头有 - UTF-8 字节顺序标记(EF BB BF),当然,它是不可见的。

第一个更新查询来自我应用程序的不同位置,其值“30”仅为字符串 (2)。但是当我在第二个查询中对值执行 var_dump 时,我注意到“35”实际上是 string(5)。该值来自 jQuery 的 $.get() 调用,并附有此 BOM ...

在这样一个“隐形”上度过了两天的生活......

【讨论】:

    猜你喜欢
    • 2012-11-22
    • 1970-01-01
    • 2023-03-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多