What are practical differences between `REPLACE` and `INSERT ... ON DUPLICATE KEY UPDATE` in MySQL?

REPLACE internally performs a delete and then an insert. This can cause problems if you have a foreign key constraint pointing at that row. In this situation the REPLACE could fail or worse: if your foreign key is set to cascade delete, the REPLACE will cause rows from other tables to be deleted. This can happen even though the constraint was satisfied both before and after the REPLACE operation.

Using INSERT ... ON DUPLICATE KEY UPDATE avoids this problem and is therefore prefered.

To answer the question in terms of performance, I did a test using both the methods

Replace Into involves:
1.Try insert on the table
2. If 1 fails, delete row and insert new row

Insert on Duplicate Key Update involves:
1.Try insert on table
2.If 1 fails, update row

If all the steps involved are inserts, there should be no difference in performance. The speed has to depend on the number of updates involved. Worst case is when all the statements are updates

I have tried both the statements on my InnoDB table involving 62,510 entries (only updates). On camparing speeds:
Replace Into: 77.411 seconds
Insert on Duplicate Key Update: 2.446 seconds

Insert on Duplicate Key update is almost 32 times faster.

Table Size: 1,249,250 rows with 12 columns on an Amazon m3.medium

When using REPLACE instead of INSERT ... ON DUPLICATE KEY UPDATE, I sometimes observe key locking or deadlock problems when multiple queries arrive quickly for a given key. The atomicity of the latter (in addition to not causing cascade deletes) is all the more reason to use it.