MySql 自适应 ID
MySql adaptive IDs
我有一个 table 设置了一个自动递增的 ID。
假设我有 ID 1、2、3、4 和 5。当我删除 ID 号 3 时，我希望 ID 4 下降到 3，ID 5 下降到 4。
这可能吗？这是怎么做到的？
我认为您想保持记录 ID 有序并且不希望它们之间有任何漏洞:)
这当然是可能的，但你真的应该让自己远离这样的解决方案。如果您以后开始将您的 table 彼此联系起来，您会后悔这个想法并疯狂地跟踪所有 table 的外国 ID。
真的，记录之间有漏洞真的不是什么坏事。此外，这就是实际数据库逻辑的工作方式。当使用 ID 时，它就完成了。你不会再用它了。当它不存在时，你就会明白它已经消失了。与此相关的数据库会跟踪上次使用的编号（对于 ID 列），并且自动递增的不是最后一个现有记录的 ID，而是上次使用的记录的 ID。
总之，可以。但你不会想要的。
我故意没有解释它是如何完成的。在那之前想确保这是 OP 真正想要的。
至于 OP 的评论 It is what I really want :) There will be no other tables connected to it. 我可以想到一个不需要 任何 数据库交互的简单解决方案，因为 OP 现在正在承担责任。
创建不带自动递增 ID 字段的 table。您的 ID 字段应为 int 类型。当您创建记录时，通过排序 IDs desc（从大到小）从 table 中获取最后一个 ID，并从中获取 TOP 1。针对您的请求的示例查询：
SELECT TOP 1 ID FROM Table ORDER BY ID DESC
在新的 INSERT 查询中使用结果 + 1。
当您删除一个值时，您应该遍历所有记录并在 for 循环中逐一更新它们的 ID。这意味着，如果您有数以千计的记录，并且不使用数据库系统的内部函数（在这里您不能，因为您使用的是自己的逻辑），可能需要一段时间（您已被警告！）。也就是说，如果您与其他 table 没有任何关系。如果这样做，您必须对相关的 table 重复该迭代以保持外国 ID 关系（数据库不再维护）。因为，通过违抗 DB 的内部逻辑，您将控制权掌握在自己手中，现在您有责任跟踪和修改您自己的一切。我有没有提到您不能在任何相关 table 中使用标识列，因为它不允许您将 ID 更改为相关 table 中不存在的 ID？
如您所见，这是一个您应该避免的痛苦过程。在您了解真正发生的事情之前，有些事情可能根本没有意义。但是相信我，我们都去过那里。这些系统是建立在其背后的逻辑之上的。无需重新发明轮子。当有人告诉你不要去那里时，你可能会认真考虑一下。 :)
祝你好运！
编辑：删除记录时，您应该使用服务器端代码来获取和更新每一行。这是逻辑。获取 table 行的总数。在循环外创建一个全局变量，并在循环内计算您的 get 请求递增 1。开始循环（它的长度是你的行总数）。您从底部开始（从 ID 为 1 的第一行开始）。如果 get 请求的结果为空，则控制每一行。如果有 null，则跳过并继续下一步。直到你找到一个真正的记录。当你得到它时，通过向你的数据库发送一个 INSERT 查询，立即用你在循环外创建的全局变量更新它的 ID。您的循环将使用该逻辑完成每一行并完成。
我从来没有写过这种详细的答案，除了 OP 对其他人没有帮助。但你很幸运。仔细阅读本文，别忘了从现在开始你就是一个人了。
人们可以将您的任务视为向上计数的简单计数器列。
如果这是真的，想象一下 table items:
realID | field_x | field_y
-------+----------+--------
1001 | bla | blubb
1003 | bla2 | blubb2
1004 | bla+ | blubbs
现在看这个：
select count(i2.realId) as counter, i1.field_x, i1.field_y
from items i1 left join items i2 on i2.realID <= i1.realID
结果是：
counter | field_x | field_y
--------+---------+--------
1 | bla | blubb
2 | bla2 | blubb2
3 | bla+ | blubbs
我还没有检查拼写错误，但该结构肯定会起作用。这个想法是将 table 连接到自身，这样所有记录的 ID 都小于或等于 table 中的相应记录。这就是它计数的原因。
像这样，您的专栏将只是虚拟的，您不必 "recount"。如果您需要它更永久，您可以将记录存储在临时中间 table.
但是每当您在 join 中使用范围时，请务必小心并预料到性能问题。
我有一个 table 设置了一个自动递增的 ID。 假设我有 ID 1、2、3、4 和 5。当我删除 ID 号 3 时，我希望 ID 4 下降到 3，ID 5 下降到 4。
这可能吗？这是怎么做到的？
我认为您想保持记录 ID 有序并且不希望它们之间有任何漏洞:)
这当然是可能的，但你真的应该让自己远离这样的解决方案。如果您以后开始将您的 table 彼此联系起来，您会后悔这个想法并疯狂地跟踪所有 table 的外国 ID。
真的，记录之间有漏洞真的不是什么坏事。此外，这就是实际数据库逻辑的工作方式。当使用 ID 时，它就完成了。你不会再用它了。当它不存在时，你就会明白它已经消失了。与此相关的数据库会跟踪上次使用的编号（对于 ID 列），并且自动递增的不是最后一个现有记录的 ID，而是上次使用的记录的 ID。
总之，可以。但你不会想要的。
我故意没有解释它是如何完成的。在那之前想确保这是 OP 真正想要的。
至于 OP 的评论 It is what I really want :) There will be no other tables connected to it. 我可以想到一个不需要 任何 数据库交互的简单解决方案，因为 OP 现在正在承担责任。
创建不带自动递增 ID 字段的 table。您的 ID 字段应为 int 类型。当您创建记录时，通过排序 IDs desc（从大到小）从 table 中获取最后一个 ID，并从中获取 TOP 1。针对您的请求的示例查询：
SELECT TOP 1 ID FROM Table ORDER BY ID DESC
在新的 INSERT 查询中使用结果 + 1。
当您删除一个值时，您应该遍历所有记录并在 for 循环中逐一更新它们的 ID。这意味着，如果您有数以千计的记录，并且不使用数据库系统的内部函数（在这里您不能，因为您使用的是自己的逻辑），可能需要一段时间（您已被警告！）。也就是说，如果您与其他 table 没有任何关系。如果这样做，您必须对相关的 table 重复该迭代以保持外国 ID 关系（数据库不再维护）。因为，通过违抗 DB 的内部逻辑，您将控制权掌握在自己手中，现在您有责任跟踪和修改您自己的一切。我有没有提到您不能在任何相关 table 中使用标识列，因为它不允许您将 ID 更改为相关 table 中不存在的 ID？
如您所见，这是一个您应该避免的痛苦过程。在您了解真正发生的事情之前，有些事情可能根本没有意义。但是相信我，我们都去过那里。这些系统是建立在其背后的逻辑之上的。无需重新发明轮子。当有人告诉你不要去那里时，你可能会认真考虑一下。 :)
祝你好运！
编辑：删除记录时，您应该使用服务器端代码来获取和更新每一行。这是逻辑。获取 table 行的总数。在循环外创建一个全局变量，并在循环内计算您的 get 请求递增 1。开始循环（它的长度是你的行总数）。您从底部开始（从 ID 为 1 的第一行开始）。如果 get 请求的结果为空，则控制每一行。如果有 null，则跳过并继续下一步。直到你找到一个真正的记录。当你得到它时，通过向你的数据库发送一个 INSERT 查询，立即用你在循环外创建的全局变量更新它的 ID。您的循环将使用该逻辑完成每一行并完成。
我从来没有写过这种详细的答案，除了 OP 对其他人没有帮助。但你很幸运。仔细阅读本文，别忘了从现在开始你就是一个人了。
人们可以将您的任务视为向上计数的简单计数器列。
如果这是真的，想象一下 table items:
realID | field_x | field_y
-------+----------+--------
1001 | bla | blubb
1003 | bla2 | blubb2
1004 | bla+ | blubbs
现在看这个：
select count(i2.realId) as counter, i1.field_x, i1.field_y
from items i1 left join items i2 on i2.realID <= i1.realID
结果是：
counter | field_x | field_y
--------+---------+--------
1 | bla | blubb
2 | bla2 | blubb2
3 | bla+ | blubbs
我还没有检查拼写错误，但该结构肯定会起作用。这个想法是将 table 连接到自身，这样所有记录的 ID 都小于或等于 table 中的相应记录。这就是它计数的原因。
像这样，您的专栏将只是虚拟的，您不必 "recount"。如果您需要它更永久，您可以将记录存储在临时中间 table.
但是每当您在 join 中使用范围时，请务必小心并预料到性能问题。