In my application, I have a lot of foreign key dependencies, and often insert large numbers of rows. What I have done up until now is run a single insert at a time, and record the insert ID. This tends to take a long time when inserting a large number of rows, even when apache and mysql are run on the same server.
My question is, if I were to alter my application to add a number of rows with a single INSERT, would I be able to assume the ids of each row based strictly upon the last insert id returned by the mysql connection? The issue is that there is the occasional situation where more than one person will be putting large amounts of information into the database at a time.
From what I have been able to determine, it seems safe to assume that when you insert 500 rows, your insert ids will range from (lastInsertID) to (lastInsertID+499), regardless of whether a query from another connection has begun or ended in the time it took to complete, but I want to be sure this is accepted as safe practice.
I am primarily running InnoDB, but there is the occasional MyISAM in there as well.
Thanks All!
-Jer
The mysql_insert_id and the now recommended alternative mysqli_insert_id returns the first entry id from the affected table's AUTO_INCREMENT column of the last query you've ran.
Mysql grouped INSERT statements are inserted iteratively from the first entry AUTO_INCREMENT index. So yes it is safe to assume that the entries inserted from a single INSERT statement are contiguous.
Comment from the Mysql reference "The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
Related
According to the PHP documentation, mysql_insert_id takes the last inserted id from the mysql table.
My question is, if I have a website that inserts more than 2 rows per second to the DB, can I use the mysql_insert_id and get the correct ID I am referring to in the INSERT query a line before?
From the MySQL manual:
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
Short version: it is safe to use.
mysql_insert_id gives you the insert id of the most recent INSERT statement on the connection you give it.
If you call this immediatly after your insert, on the same mysql connection, you get the inserted id matching that insert statement, independantly of any other inserts going on in the mean time.
According to the PHP documentation, mysql_insert_id takes the last inserted id from the mysql table.
My question is, if I have a website that inserts more than 2 rows per second to the DB, can I use the mysql_insert_id and get the correct ID I am referring to in the INSERT query a line before?
From the MySQL manual:
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
Short version: it is safe to use.
mysql_insert_id gives you the insert id of the most recent INSERT statement on the connection you give it.
If you call this immediatly after your insert, on the same mysql connection, you get the inserted id matching that insert statement, independantly of any other inserts going on in the mean time.
According to the PHP documentation, mysql_insert_id takes the last inserted id from the mysql table.
My question is, if I have a website that inserts more than 2 rows per second to the DB, can I use the mysql_insert_id and get the correct ID I am referring to in the INSERT query a line before?
From the MySQL manual:
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
Short version: it is safe to use.
mysql_insert_id gives you the insert id of the most recent INSERT statement on the connection you give it.
If you call this immediatly after your insert, on the same mysql connection, you get the inserted id matching that insert statement, independantly of any other inserts going on in the mean time.
I am trying to write a tag system which I want allow users to insert multiple tag in a text input. And then I want insert each tag in tag_table and need their id for keep in tag_post_table.
I know that in multiple insert last_insert_id return the first record id. Co can I add count of tags to last_insert_id for getting the real last id and use every id between them? Is this reliable?
I read this article, but I don't understand it completely
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html
As I understand this article:
With innodb_autoinc_lock_mode set to 0 (“traditional”) or 1 (“consecutive”), the auto-increment values generated by any given statement will be consecutive, without gaps, because the table-level AUTO-INC lock is held until the end of the statement, and only one such statement can execute at a time.
Setting innodb_autoinc_lock_mode to 0 or 1 guarantees that the auto incemented ids are consecutive.
So the ID you get from LAST_INSERT_ID is the first of the new IDs and LAST_INSERT_ID + "the number of affected rows" is the last of the new IDs.
Also LAST_INSTERT_ID is not affected by other connections
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
But notice, that there may be wrong results, if you use INSERT ... ON DUPLICATE KEY UPDATE or INSERT IGNORE .... But I have not tested this.
I'm working on a project for which I need to frequently insert ~500 or so records at a remote location. I will be doing this in a single INSERT to minimize network traffic. I do, however, need to know the exact id field (AUTO_INCREMENT) values.
My web searches seem to indicate I could probably use the last_insert_id and calculate all the id values from there. However, this wouldn't work if the rows get ids that are all over the place.
Could anyone please clarify what would or should happen, and if the mathematical solution is safe?
A multirow insert is an atomic operation in MySQL (both MyISAM and InnoDB). Since the table will be locked for writing during this operations, no other rows will be inserted/updated during it's execution.
This means IDs will in fact be consecutive (unless auto-increment-increment option is set to something different than 1
Auto increment does exactly that, it auto-increments - i.e. each new row next the numerically next ID. MySQL does not re-use IDs of rows that were deleted.
Your solution is safe because write operations aquire a table lock, so no other inserts can happen while your operation completes - so you will get n contiguous auto-increment values for n inserted rows.