By using INSERT .. ON DUPLICATE KEY UPDATE instead of REPLACE.
According to the document, if the row having the primary key already exists, 'INSERT .. ON DUPLICATE KEY UPDATE' will perform 'UPDATE' whereas 'REPLACE' will perform 'DELETE' + 'INSERT'. Thus the latter can be less efficient than a simple UPDATE because it involves more disk I/O and index maintenance, even when the data hasn't changed.
-
syncml (slow query found on prod) -
versioning (slow query found on prod) -
catalog (slow query found on prod) -
full_text (slow query found on prod) -
accounting_transaction ( DELETE+INSERTpattern, number of rows per uid differ, 1 or 2) -
stock ( DELETE+INSERTpattern, number of rows per uid differ, many for Group Calendar Assignment, 1 or 2 for other portal types) -
category ( DELETE+INSERTpattern, not easy)
(SQLite3 equivalent is UPSERT > @xiaowu.zhang)
This merge request only focuses on simple REPLACE usage.
The important difference between INSERT .. ON DUPLICATE KEY UPDATE and REPLACE is the values of unspecified columns, which are reset to the default in the former, whereas are kept in the latter. This is why we have some = DEFAULT, for timestamp columns and security related columns, in this merge request.
/cc @vpelletier @jerome