Inserting a large number of records at the beginning of a table

Question

MySQL

Gentlemen, please tell me the solution, alas, I can’t think of it myself. There is a service, it has three tables, one main, two child. On the main, foreign keys are exposed to the child ones. Main table format: id, id_table1, id_table2, data (datetime), text. Log table. In addition, this table is also linked by a foreign key with another one, where only the necessary records are entered. So here's the problem, before the logs were kept in files, a huge number of them have accumulated. I would like to put everything in this big table, but the problem is how to make the auto-increment offset. The only option I see is step by step:
1) find out how many records we will insert new ones
2) stop logging for a while
3) count how many records are in the current table and calculate the required offset
4) increase the auto-increment by the required offset
5) start recording the logs back, the recording will go with the desired offset
6) run from the tail of the old data block, moving each record by an offset
7) free up the necessary space at the beginning of the table for new data
8) insert new data at the beginning tables with forced indication of the record ID

Perhaps there is a more original solution? For it is necessary to shift the block from about 700 records in one and 200 records in other table. I will be extremely grateful for the answers.

Answer 1

What if you use negative values?
you had from 1 to xxx, will be from -yyy to xxx

Answer 2

I would make so:
1. created new tables.
2. zafigachit all of the files there.
3. disabled logs and constructs
4. insert into new_tables select (all fields except PK) from old tables.
5. renamed the tables, included logs.
something like this, if I understood the conditions correctly.

Answer 3

Are you sorting logs by id? If, anyway, by id, I don’t know the correct option for Solko:
Add a new field for increment
Add records
Set old records to old records with new id
delete the old field

Answer 4

Alas, no, an ordinary timestamp, which in the database lies in the datetime format field. I did not want to duplicate data here and there. I understand your idea, I'll think about how it can be applied to our situation

Answer 5

Don't bother. For a relational database, the order of the rows does not matter. If pedantry really doesn’t let you live, go to uuid )