Comments on: REPLACE INTO: think twice

By: shlomi

shlomi — Wed, 04 Aug 2010 11:00:19 +0000

@ricardo,

Agreed on bulk updates.

Nevertheless it is common to see people using REPLACE INTO when they could have used INSERT INTO … ON DUPLICATE KEY UPDATE for single rows.

By: ricardo

ricardo — Wed, 04 Aug 2010 09:11:10 +0000

i think you’re missing the point of the replace query. It is not meant to substitute insert on duplicate key update, but it is the only solution if you want to do bulk updates coming from a subquery. insert on duplicate key update works well if you want to update a few rows at a time, not sure how u can use it to update thousands of rows w/ a single subquery.

By: saviola

saviola — Wed, 23 Jun 2010 12:31:33 +0000

The two statements have different impact for INNODb table.
The REPLACE INTO acts as DELETE/INSERT for duplicates.
The INSERT ON DUPLIACTE UPDATE is true update.

If you have a child table defined with “on delete CASCADE”, the REPLACE INTO will delete the child record too.

I will use INSERT ON DUPLICATE rather than the REPLACE INTO for the above reason.

By: Brian

Brian — Wed, 29 Apr 2009 20:56:25 +0000

It is worth noting, however, that performing an INSERT/ON DUPLICATE KEY UPDATE, because of its dual nature, will not give predictable results when requesting the “last insert ID” from the DB engine. The last insert ID is only updated when the engine performs an update.

By: shlomi

shlomi — Thu, 18 Dec 2008 05:46:59 +0000

Mike – exactly my point. I have the (unconfirmed) feeling most people are just using REPLACE INTO to do an “insert if not exists or update if exists”, in which case it is not the optimal solution.

Steve – thanks for sharing

By: Steve W

Steve W — Wed, 17 Dec 2008 16:19:09 +0000

I would add that the ON DUPLICATE KEY performs the operation much faster then a REPLACE INTO. It’s probably obvious that this true, but it can cut the processing time more then half if you don’t have that many updates to run.

On just a 256 row database, my page execution times went from 1.2 seconds to .43 seconds. This was doing a REPLACE into on all the rows (running the same sql twice). By updating it to do the ON DUPLICATE, the same script is much faster.

The database is running some triggers and stored procedures to update a random row scheme. By not having the DELETE/INSERT these triggers are never called. YMMV on the actual speed increase.

It takes a bit more planning with PHP scripts to account for the unique keys and not include them in the ON DUPLICATE portion, but it’s worth it.

By: mike

mike — Wed, 17 Dec 2008 09:36:21 +0000

This has bitten me a couple times, and usually what I really want is the ON DUPLICATE KEY, not the REPLACE INTO. Not for space reusage but for the row with the unique key I wanted to update if it existed.

By: shlomi

shlomi — Wed, 17 Dec 2008 08:51:49 +0000

Arjen, thanks,

With regard to re-using the index slot, 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 don’t think the slot can be reused. What do you think?

With regard to having more than one row removed – nice! I’ve never encountered such a situation. But still it seems to me more a hack. I agree that it must be used appropriately.

By: Arjen Lentz

Arjen Lentz — Wed, 17 Dec 2008 08:32:13 +0000

Two things…

REPLACE is completely different from the INSERT … ON DUPLICATE KEY UPDATE … because replace removes and replaces rows complete whereas the no dup key update construct allows you to update values in the existing row.

If I remember correctly, MySQL will actually re-use the index slot, if possible, so it’s not as inefficient as you might think. In any case, the alternative equivalent to REPLACE is DELETE+INSERT, which is definitely no faster and quite likely slower.

By the way, REPLACE can actually delete more than one row, this can happen if you also have other UNIQUE constraints. Again, this can be a very useful feature, when used appropriately.