This may not be practical, but: do not tell the DB to create an autoincrement id for you. Instead give each new table an id YOU create and guaranteed to be unique.

That's commonly called a sequence and is often implemented in the DB server, guaranteed to deliver unique IDs under all circumstances.

• PostgreSQL
• Oracle
• MariaDB

Other DB servers offer only an automatic ID generator, and for that, you need to use last_insert_id in DBI (see SELECT LAST_INSERT_ID does not work).

• MySQL
• MS SQL Server
• SQLite

Related: Some very common errors (or, if you want to be polite, misconceptions):

The ID generated by either of these mechanisms is JUST THAT. A unique value.

• In any usage scenario with more than one user and/or more than one process/thread and/or more than one CPU core, the next ID is not predictable.
• The ID is not a sort criteria.
• IDs are commonly set up to increment by one for each use. But that's an inplementation detail. They could also be set up to return multiples of seven starting from a ridiculously large positive number and going down to ridiculously large negative number. The returned IDs would still be unique. The bits from such a sequence could even be shuffled around so that any returned ID looks completely random (but still is unique).
• The numeric sequence of used IDs may have gaps, some times big gaps, e.g. after rolling back transactions. This is intentionally and by design to guarantee uniqueness. It does not hurt. It does not waste anything. Trying to fill those gaps is an error. The IDs in those gaps were once used, filling the gaps would reuse IDs and make them non-unique.

Alexander