删除末尾数据并重启MySQL后，InnoDB表新插入数据的ID通常是当前最大ID加一。原有7条数据删除ID为6和7后，剩余最大ID是5，重启后InnoDB会扫描表获取最大ID并在此基础上自增，因此新插入数据的ID很可能是6。但自增ID不连续的情况常见，原因包括事务回滚导致ID浪费、批量插入预分配ID、并发插入产生间隙以及显式指定较大ID值改变自增计数器。InnoDB在重启后通过扫描表确定自增值，不会保留内存中的计数值。虽然可通过ALTER TABLE重置自增ID，但可能导致ID冲突或数据一致性问题，因此不建议随意操作。查询当前自增值可用SHOW TABLE STATUS命令。自增ID的核心作用是保证唯一性而非连续性，应用中应优先关注数据唯一与一致，而非追求ID连续。
一张自增表删除末尾数据后重启MySQL并插入数据，ID是多少取决于具体的存储引擎和配置。一般来说，如果使用InnoDB引擎，并且没有显式地重置自增计数器，新插入的ID很可能不是简单的最大ID加一。
自增ID的分配策略受多种因素影响，下面详细分析可能的情况。
解决方案
重启MySQL服务器后，InnoDB存储引擎对自增值的处理方式是：它会扫描表中的最大ID值，然后在此基础上增加，作为新的自增起始值。这意味着，如果你的表原有7条数据，删除了最后两条（ID为6和7），那么表中剩余的最大ID是5。重启后，InnoDB会找到这个5，并在此基础上自增，所以新插入的数据ID很可能是6。
但事情并非总是如此简单。
为什么自增ID可能不连续？
自增ID不连续的情况有很多，删除数据只是其中一种。还有其他情况会导致ID跳跃：
- 事务回滚： 如果一个事务申请了自增ID，但最终事务回滚，那么这个ID就被浪费了。
- 批量插入： 批量插入数据时，MySQL可能会预先分配一批ID，即使实际插入的数据少于预分配的数量，未使用的ID也不会被回收。
- 并发插入： 在高并发环境下，多个连接同时插入数据，可能会导致ID分配出现间隙。
- 显式指定ID： 如果你在插入数据时显式指定了ID值，且这个值大于当前的自增值，那么MySQL会自动调整自增计数器。
如何避免自增ID不连续？
实际上，完全避免自增ID不连续几乎是不可能的，也是没有必要的。自增ID的主要目的是唯一标识记录，而不是保证连续性。如果你真的需要连续的ID，可以考虑使用其他方式来实现，例如：
- 应用程序维护： 在应用程序中维护一个计数器，每次插入数据时从计数器获取ID。
- 使用序列： 某些数据库系统（如PostgreSQL）提供了序列（Sequence）功能，可以生成连续的数字。
但是，这些方法都会增加系统的复杂性，并且可能影响性能。
重置自增ID的影响
可以使用ALTER TABLE table_name AUTO_INCREMENT = value;命令来重置自增ID。但需要注意的是，重置自增ID可能会导致以下问题：
- ID冲突： 如果新的自增起始值小于表中已有的ID值，那么在插入新数据时可能会发生ID冲突。
- 数据一致性问题： 如果你的应用依赖于自增ID的连续性，那么重置自增ID可能会导致数据一致性问题。
因此，除非有充分的理由，否则不建议随意重置自增ID。
如何查询当前自增值？
可以通过以下SQL语句查询当前表的自增值：
SHOW TABLE STATUS LIKE 'your_table_name'\G
在结果中，Auto_increment字段显示的就是当前的自增值。
总结
自增ID的分配策略是一个复杂的问题，受到多种因素的影响。在实际应用中，应该根据具体的需求选择合适的策略。不必过于追求自增ID的连续性，而应该更加关注数据的唯一性和一致性。
