Comments on: INSERT ON DUPLICATE KEY UPDATE and REPLACE INTO

By: vitamin-R

vitamin-R — Fri, 30 Dec 2011 18:16:17 +0000

Juan, just make your log table InnoDb too, to get rid of the table locks.

Use something like “ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8″ if you need it to use less disk space.

By: Juan

Juan — Wed, 26 Oct 2011 08:46:37 +0000

I’m using a trigger on an innodb table that “dumps” any updates to the table to a myisam table holding a log of updates.
The update table has the same primary key than the primary table.
The idea is to keep the last change for every primary key (well, I don’t dump the whole rows, but only some selected fields that I need in the log).
The trigger uses INSERT ON DUPLICATE KEY UPDATE to achieve that.
The problem is that I find many locked queries in the db as soon as there’s a bit of update activity over the primary table. It even looks like there might be some deadlock (or I don’t find an explanation for such long locks in so many queries), but I can’t find any reason in the code for that.
I was wondering if INSERT … UPDATE might lock for read access (or lock only the index, or something simmilar) while checking for key value existence, as inserts in myisam are concurrent with reads, and then try to lock for write access when performing the update. This would lead to a deadlock when trying to upgrade two read locks to write locks or any equivalent situation.
My version is 5.1.49-3-log.
Is it possible that a problem like the one I described is really happenning?
Might a REPLACE solve the issue? Would it work right where INSERT … UPDATE locks?

By: s.mateev

s.mateev — Wed, 23 Jun 2010 12:46:04 +0000

Consider the following:

DROP TABLE IF EXISTS `person`;
CREATE TABLE `person` (
`person_id` int(11) NOT NULL auto_increment,
`name` varchar(60) character set utf8 NOT NULL,
`social_security_number` bigint(20) NOT NULL,
PRIMARY KEY (`person_id`),
UNIQUE KEY `social_security_number` (`social_security_number`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

TRUNCATE TABLE person;
INSERT INTO person (name, social_security_number) VALUES (â€˜Aliceâ€™, 123456);
INSERT INTO person (name, social_security_number) VALUES (â€˜Bobâ€™, 787878);
REPLACE INTO person (name, social_security_number) VALUES (â€˜Bobâ€™, 787878);

Both on InnoDB and on MyISAM, the results are:

+———–+——-+————————+
| person_id | name | social_security_number |
+———–+——-+————————+
| 1 | Alice | 123456 |
| 3 | Bob | 787878 |
+———–+——-+————————+

If the primary key value changes, I think the slot can’t be reused.

With regard to having more than one row removed â€“ nice! I agree that it must be used appropriately.

By: Ayman

Ayman — Wed, 23 Jun 2010 10:01:54 +0000

Thanks for all who share their knowledge here.
I guess I need to use the REPLACE statement, but there is a question in my head:
If the auto-increment primary key is 7 now (for example), after doing REPLACE for the 7th row or less than 7, what will be the next auto-increment value? will it be 8 or 9?

By: Jeff

Jeff — Fri, 04 Sep 2009 20:42:49 +0000

One benefit of REPLACE over UPDATE is the DELAYED feature, which comes in handy.

By: Possible improvement with caches | reexport

Possible improvement with caches | reexport — Sun, 13 Jul 2008 15:55:47 +0000

[...] http://www.mysqlperformanceblog.com/2007/01/18/insert-on-duplicate-key-u… High performance [...]

By: G Barnes

G Barnes — Sun, 13 Apr 2008 15:46:03 +0000

I have two identical tables named Table1 and Table2 on two computers respectivaly. There are two fields in each, “ITEM” and “SOLD”. In both tables, “ITEM” is the primary key. Is there a way to merge Table1 into Table2 with something similar to INSERT ON DUPLICATE UPDATE sold =sold +(the first table’s sold value)? Thus if Table1 contains 10 (in the sold field) and Table2 contains 20. I want the total in Table 2 to be 30. Is this possible?

By: P.ANBALAGAN

P.ANBALAGAN — Mon, 10 Mar 2008 07:14:41 +0000

I WANT QUERY FOR TO INSERT MORE 100000 RECORDS IN A TABLE.

By: Jonathan Haddad

Jonathan Haddad — Wed, 07 Feb 2007 19:03:12 +0000

Jerry:
Thanks for the tip – I’ll be sure to keep that in mind. For the most part, in what I do, INSERT ON DUPLICATE UPDATE is what I need to use, especially knowing the cascading keys issue.

By: John Ventimiglia

John Ventimiglia — Wed, 31 Jan 2007 15:02:12 +0000

Also related to Jerrys comments, REPLACE will use the next available # on auto-increment fields, which may not always be desired.