MySQL 在第二次更新时错误地更新了整数列。

12 浏览
0 Comments

MySQL 在第二次更新时错误地更新了整数列。

我有一个非常奇怪的问题，整天让我发疯。我有一个简单的MySQL表，有几列。其中一列是int(11) NULL。当我更新它的值时，它按预期工作。然而，当我第二次更新其值时，它被赋予了\"0\"的值。\n我在我的MySQL 5.1.58-1ubuntu1和其他MySQL 5.0.96-community上测试了相同的行为，两者的行为完全相同。所以显然不是一个版本MySQL的问题。\n对我来说很难解释，但是我附上了两个截图，它们会更好地告诉你问题出在哪里。\n第一个截图是我正在更新的表的结构：\n\"table\n下面显示了正在执行的SQL查询，你可以看到，第一个更新是正确的，而第二个没有任何原因地在“invoice_number”列中产生了\"0\"的值：\n\"enter\n我有没有忽略什么明显的地方？这真的让我发疯，因为对我来说毫无意义...\n提前谢谢你的帮助...\n编辑：我尝试只在我的查询中使用数字，这是结果（对我来说也很奇怪）：\n\"enter

0

2 答案

0 Comments

MySQL错误地更新整数列当它第二次更新时

最近，我遇到了一个奇怪的问题：当我尝试更新MySQL中的整数列时，它错误地更新为一个字符串。在花费了两天的时间进行调试之后，我终于找到了问题的根源和解决方法。

起初，我以为问题出在MySQL本身。我从MySQL查询日志中复制了所有的SQL查询语句，所以我从未怀疑过可能会有什么奇怪的东西。然而，事实上确实有一个问题——在“35”值的开头有一个UTF-8字节顺序标记(EF BB BF)，而且当然是看不见的。

第一个更新查询的值来自我的应用程序的不同位置，它的值“30”只是一个字符串(2)。但是当我在第二个查询中对值进行var_dump时，我注意到“35”实际上是一个字符串(5)。这个值来自jQuery的$.get()调用，并附带了这个BOM...

为了解决这个问题，我需要去掉字符串前面的字节顺序标记。我使用了以下代码来实现：

$value = preg_replace('/\x{EF}\x{BB}\x{BF}/', '', $value);

这行代码使用正则表达式将字符串中的字节顺序标记替换为空字符串。当我再次运行更新查询时，整数列被正确地更新为整数值。

这个问题教会了我一个重要的教训，即在调试时要注意不可见的字符。有时候，问题的根源可能隐藏在我们看不见的地方，导致我们花费大量时间来寻找解决办法。

总结起来，当MySQL错误地将整数列更新为字符串时，我们应该首先检查更新值是否包含任何不可见的字符，如字节顺序标记。如果有，我们可以使用正则表达式将其删除，以确保更新操作能够正确执行。

希望这篇文章能帮助到遇到类似问题的人们，节省他们解决问题的时间和精力。

0
0 Comments

问题出现的原因可能是使用的工具与数据库进行交互时出现了问题。单引号的问题并不相关，即使'55'和55被解释为不同的值，它们在where语句中的解释结果应该是相同的。而且，'35'可以正常工作，但'30'却不能。重要的是，当去掉引号时出现了错误。下面是一个例子：

update i_orders
set invoice_number = 30
where id = 55

这个语句不应该在设置列索引为30时查找列索引。你在工具中看到的未知列错误提示表明实际发送给数据库的查询与你看到的查询不同。你可以在数据库中记录查询以查看实际发送的内容吗？

实际上，当我今天早些时候疯狂的时候，我就记录了查询。第二个截图中显示的4个查询正是从MySQL日志中粘贴出来的。

对于整数问题更加奇怪。MySQL不应该在set语句中查找列引用。字段列表似乎应该在insert语句的表名之后。我无法解析你的查询以获得这个错误的原因。也无法理解为什么字符串不会引起这个问题。

0