 <p>Generally you'll have to fetch back out the <code>id</code> values of the inserted rows. This is unless you can create another key that is used in place of that which can be procedurally generated in advance.</p> <p>While <code>INSERT</code> statements with multiple rows is significantly faster, the price you pay is a lack of precision. If your <code>id</code> values are issued sequentially, which is the default behavior, then you can be reasonably assured that the <code>LAST_INSERT_ID()</code> represents the ID of the first row inserted, so you could perhaps calculate the ID of the rows using the method you propose, though starting at index 0.</p> <p>Remember that multiple submissions do not affect the <code>LAST_INSERT_ID()</code> result because this value is per-connection. It is only changed if you perform a subsequent query on the same database handle. Operations in other requests will not affect it.</p> <p>Databases that are clustered or multi-master may issue non-sequential identifiers in which case this won't work. This is also unreliable in an <code>INSERT IGNORE</code> situation where the number of rows actually inserted could be less than the number of rows provided.</p>