Restore MySQL database is very slow

I've just bought a new home desktop. I have three MySQL databases that I want to move across. I dumped them all using mysqldump before removing the drive from the old machine.

Restoring the largest of the databases is taking ages (getting on for 24 hours so far). I'm restoring via:

mysql -uxxxx -p
Enter password: yyyy
mysql> create database foo;
mysql> use foo;
mysql> start transaction;
mysql> \. <dump-file>

I pray I remember to commit when this finishes!

I abandoned my first attempt to restore, without the transaction as it was taking so long. I intend not to bother with the transaction when restoring the other two databases as it seems to make no difference.

Is there anything I can do to speed up the restore? Should I have done the backup differently - I just used a vanilla mysqldump command line, with --skip-column-statistics since the dump would otherwise fail, as proposed in this stackoverflow answer.

For reference, the new machine runs Windows 10 and MySQL 8.0.25 Community; the old machine ran Windows 7 and MySQL 5.6.22.

Looking at the dump files more closely (to find the server version), I see that the tables are created with their indexes, followed by a lot of INSERT INTO statements. This doesn't seem particularly clever. Is there a way to induce mysqldump to produce a script that:

1. Creates the tables without indexes
2. Inserts the rows; and then
3. Creates the indexes.

which would seem a better approach for when the database is being restored. (It's a little surprising that this isn't the default!) I assume this is possible with MySQL - I've been using SQLLite for the past 3 years and it's certainly possible there.

Update

This question isn't completely answered by How can I speed up a MySQL restore from a dump file?, since that question particularly refers to MyISAM tables, and mine are InnoDB. (Apologies. I probably should have mentioned the storage engine in my original question.)

That answer did, however motivate and inform my attempts to resolve matters, which I document in my own answer below.

I eventually gave up waiting for the import to complete, after >24 hours.

I modified the scripts generated by mysqldump so as to create the tables without secondary indexes, and to create the indexes only when all the INSERT statements had been executed. With this change, the import had completed when I checked three hours after starting.

I then further modified the script to insert the rows within a transaction, by adding SET AUTOCOMMIT=0; START TRANSACTION; at the start, and COMMIT; at the end. With this change, the restore completed in 90 minutes.

While editing the generated dumps, I noticed that they include

/*!40000 ALTER TABLE `xxx` DISABLE KEYS */;

and

/*!40000 ALTER TABLE `xxx` ENABLE KEYS */;

surrounding the INSERT statements. I looked up the documentation on these commands and discovered that they only apply to MyISAM tables. The documentation on the mysqldump utility states that these lines (including the comment delimiters and the magic number 40000) are generated if you specify --disable-keys on the command line. The utility documentation also states that it will add the "insert everything in a single transaction" behaviour that I found desirable if you specify --no-autocommit on the command line.

In summary, I should probably have taken the backups with

 mysqldump --no-autocommit...

At least in my case (mysqldump version 8.0.25 and an InnoDb table) the --disable-keys option makes no difference; ALTER TABLE ... ENABLE|DISABLE KEYS statements (commented out, and with a magic number) are always generated. I do need to modify the generated dump to create the tables without secondary keys, and to add them once all the INSERT INTO statements have been executed.