Java 带drop的JPA DDL生成重用旧索引

我们使用JPA，出于测试原因，我们将drop和create表作为ddl生成模式。但是，这会导致重新启动应用程序时出现一些奇怪的行为：

我们运行应用程序一次并生成一些数据。例如，我们创建70个Entite，从1到70递增ID->工作正常

我们重新启动应用程序，从而删除并重新创建表->工作正常

当我们现在再次创建数据时，它变得很奇怪：新实体的ID从31开始，而不是1。然而，当它们达到49时，它们再次在1处重新启动，并最终抛出“唯一约束冲突异常”，因为已经使用了Id 31

我检查了数据库，确实存在“旧”索引（命名为SQL15082120153900）。创建新实体时，将添加一个新索引。序列表中的值为“50”，我不想更改它

有什么想法吗？是什么导致了这种奇怪的行为，或者我如何修复它？我想知道为什么索引不随表格一起删除。或者至少“索引计数器”或其调用方式被重置。很奇怪

---

PS：我们正在运行一个带有本地derby的tomcat，但是它也发生在嵌入式derby和sybase ASE DB上。

设置分配大小以匹配DB中的增量。请看：我也偶然发现了这个解决方案，但我很确定这将与现有的DBs发生冲突，这些DBs从来都不是以“拖放并创建”开始的，而是以“创建”开始的。向每个实体添加一个新的@SequenceGenerator不会破坏旧的应用程序吗，因为它们的DBs仍然具有默认序列，而它们有一个注释告诉它们使用不同的序列？新表可以使用一个新的序列对象，而不会影响现有的应用程序，但是现有的表需要继续使用相同的序列，否则会产生冲突。DROPDDL只用于测试，所以我不明白为什么您要尝试实现一个可以投入生产的解决方案。SQLEclipseLink使用的是什么？我不知道一个序列如何在没有其他事情发生的情况下上升到70然后重置到31。我现在使用了Alan提出的sequenceGenerator，它似乎可以工作。我们还没有对我们的测试机器进行测试，它模仿了生产行为，但其他一切现在都运行顺利，所以我想，现在一切都好了。。。是的，我们不想在生产环境中有解决办法，这就是为什么我要求一个更好的解决方案，似乎改变分配大小正是我想要的。好的，它使用分配大小1。然而，我们刚刚注意到，这意味着：巨大的性能问题，因为JPA必须在每次插入操作后增加序列计数器。因为我们会有很多这样的选择，这是没有选择的。还有其他想法吗？