| InnoDB DELETE/INSERT vs. UPDATE in transaction [message #1317] |
Fri, 25 May 2007 09:51  |
puzzles Messages: 2 Registered: May 2007 |
Junior Member |
|
|
Hi,
I have an InnoDB table with approximately 300 rows, which is regenerated every 3 seconds. (This is a redundant statistics table for a website with a *very* heavy load.)
Right now, the generation of the table is done in a transaction by deleting all rows and then inserting all necessary new ones. My question is, would it be faster (does it make any difference at all) to not DELETE/INSERT the rows, but do an INSERT ... ON DUPLICATE KEY UPDATE query and then delete the rows that were unaffected by this operation (and thus, are now obsolete)?
Thanks.
|
|
|
| Re: InnoDB DELETE/INSERT vs. UPDATE in transaction [message #1320 is a reply to message #1317 ] |
Sat, 26 May 2007 06:15   |
Speeple Messages: 91 Registered: August 2006 |
Member |
|
|
Depends on the cardinality.
If by using INSERT .. ON DUPE.. leaves you DELETING 80% of rows, performance might suffer.
Maybe in that case it's best to do TRUNCATE->CREATE->INSERT.
300 rows isn't too large a data set to populate (depending on datatypes used).
Only way to get a definitive answer is to benchmark each method.
Martin Gallagher | Speeple: The latest news
|
|
|
|
|
| Re: InnoDB DELETE/INSERT vs. UPDATE in transaction [message #1333 is a reply to message #1317 ] |
Tue, 29 May 2007 04:42  |
puzzles Messages: 2 Registered: May 2007 |
Junior Member |
|
|
Hi all,
Thanks for your replies.
The reason I chose InnoDB and the DELETE/INSERT method is that it's very important that we get consistent data from the database at all times. With InnoDB, I can do my updates (DEL/INS) in a transaction and then COMMIT the changes in one step, meaning that all reads from the table will result in "correct" data.
The problem with the MEMORY (or HEAP) storage engine is that it doesn't support transactions, so in that case, the DEL/INS method is no longer usable. (Having people read an empty table, even for just a split second is not an option here.) The same goes for TRUNCATE, as you can't use it in a transaction, since it drops and recreates the table.
Anyway, thanks for your suggestions. I'll try benchmarking both methods and see what I come up with that way.
Thanks.
|
|
|