In MySQL why is the first batch executed through client-side prepared statement slower?
Probably you have an ordinary "cold cache" case.

When you INSERT 10,000 rows into a table, the rows need to be added to the appropriate place(s) in the "data".  Also, 10,000 entries need to be added to each index's BTree.  (How many indexes do you have?  Please provide SHOW CREATE TABLE.)

If you have AUTO_INCREMENT, then the rows will be "appended" to the table; this is not a caching issue.  If, on the other hand, you have a UUID index, or some other 'random' index, then the "inserts" into the index will be random -- involving read-modify-write.  The read and the write are cached.  But, if the system were "cold" when you did the first 10,000, a lot of reads were probably necessary.  Multiply that by how many indexes you have.

How big is the table?  If it is small enough to fit into innodb_buffer_pool_size (if InnoDB) or small enough for the indexes to fit into key_buffer_size (if MyISAM), then soon all the index blocks will be cached, and the inserts will speed up.

If the table is too big for the cache, then the 'random' indexes will continue to hit the disk (and be slow).  AUTO_INCREMENT will continue to be fast.

5 seconds is about 500 reads from a commodity spinning drive.  So, I would guess that you have a modest sized table.  Since the next 10K rows go in &lt;1sec (&lt;100 disk hits), I will guess that it fits in cache so far.

I often recommend 100-1000 for chunk size.  This is partially because 5 sec can be a problem.  You may as well COMMIT after each chunk, since the benefit of delaying it is minor.  Furthermore, if you wait "too long" to commit, the 'transaction' could overflow the log_file, leading to an inefficiency.

A chunk size of 100 is about 10% slower than the theoretical maximum.  1000 is about 1% slower than max.

If you have replication, keep in mind that the 5 seconds will interfere with anything else being replicated.  (Another argument against 10K.)