Question

我有一个大表，它使用基于外部API输入的ID保存数据。 ID存储在int字段中。当我开发系统时，我没有遇到任何问题，因为外部API中的记录ID始终低于2147483647.。

系统最近几个月一直在从API获取数据，并且显然ID超过2147483647标记。我现在有一个包含数千个不可用记录的数据库，ID为2147483647。

无法再次从数据库中获取此信息（基本上，API允许我们从最近x天前查找数据）。

我很确定我注定要失败。但是，是否有任何积压或任何其他方式来检索原始输入查询，或者被MySQL截断以适合int字段的数字？

Answer 1

正如评论中已经讨论的那样，无法从表中检索信息。它默默地（？!!!）被截断为32位。

首先，致电API提供商 ，解释您的情况，看看您是否可以重做查询。最好的情况是他们说是的，你不必尝试从日志中重建东西。最糟糕的是，他们说不，你现在回到了现在。

然后我会检查一些日志。

首先是MySQL General Query Log。如果你打开了它，它可能包含运行的查询。另一种可能性是Slow Query Log，如果您的查询发生得很慢，则会更频繁地启用。

在MySQL中，默认情况下数据截断是一个警告。这些警告可能会进入日志并包含原始数据。 MySQL Error Log是一种可能性。在Windows上，它可能已进入Windows Event Log。在Mac上，它可能位于Console可见的日志中。在Unix中，它可能已经转移到syslog。

然后可能会在某处记录API查询本身。如果您使用了代理，它可能会在其日志中包含它们。从API获取并添加到数据库的程序也可以具有其自己的日志。这是一个很长的镜头。

作为最后的手段，请尝试点击所有/var/log和/var/local/log以及您认为可能包含日志的任何其他地方。

将来你可以采取一些措施来防止这类事情再次发生。最重要的是 启用strict SQL mode 。这会将警告（例如已截断的数据）转换为错误。

Set UNIQUE constraints on unique columns。如果您的API ID列已声明为UNIQUE，则会检测到错误。

将UNSIGNED BIGINT用于数字ID。 20亿是这几天很容易超过的数字。它将意味着每行4个额外字节或大约8千兆字节，以存储20亿行。磁盘很便宜。

考虑开启ANSI SQL mode。这将禁用许多MySQL扩展并使您的SQL更具可移植性。

最后，考虑切换到PostgreSQL。多年来，MySQL积累了许多糟糕的想法，功能混乱，以及糟糕的默认行为。你只是一个接一个。 PostgreSQL设计得更好，功能更强大，更灵活，通常也更快或更快。

在Postgres中，你会遇到错误。

test=# CREATE TABLE foo ( id INTEGER );
CREATE TABLE
test=# INSERT INTO foo (id) VALUES (2147483648);
ERROR:  integer out of range

Answer 2

如果您启用了二进制日志记录，并且仍然拥有binlog的备份，并且<input type="text" id="fullname" placeholder="Name" /> <button type="button" onClick="document.getElementById('fullname').focus()" id="button">Set Focus</button>未设置为binlog_format，则应在此处保留原始插入和/或更新语句，其中您可以提取它们并使用更合适的表定义将它们重放到另一台服务器中。

如果您没有启用binlog和/或您没有永久存档binlog ...这是您应该考虑这样做的原因之一。

有没有办法检索高于2147483647的sql int字段的原始输入？

2 个答案: