Performance of Delete/Insert vs. Update

In looking at objects that are a high load on our database I found a Stored Procedure that is has the highest CPU usage on our system and it is a simple procedure that based on 5 parameters it deletes the record based on the 2 key fields (Unique) and then does an insert of a record with the 5 parameter fields (which match the columns in the table.

To me I though this is inefficient and it should be only doing an insert if the row is not found, otherwise doing an update.

How can I best test this out or know if I am correct?

The table has over 10 million rows with three indexes.
GNiessenAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kent OlsenDBACommented:
Generally, I would expect a simple update to be much faster than a delete/insert cycle.  

On an update cycle, if the two key columns aren't changed, that index won't need to be updated.  An Insert/Delete cycle will have to update the indexes twice, and the new row is likely to be stored at the end of the table instead of the original location.  That could have a performance impact depending on how data is later accessed.

Are all of the indexes on the keys?  If not, which columns?


Good Luck,
Kent
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lcohanDatabase AnalystCommented:
Here are some questions you need to answer in order to understand the impact of delete/insert(bad in my opinion) vs a simple update if record exists:
1. Does the table has any clustered index? if yes this is one reason your cpu and io are high as cluster is rebuilt with each delete/insert
2. does table has triggers that fire on delete/insert? Another reason for high cpu and io.
3. Are there any missing indexes? you need to check your query plans for that.
0
GNiessenAuthor Commented:
Yes, all keys (column 1 and 2) are part of the Primary Index.  The third and forth columns are separately indexed for cross-reference.  

This table contains rows that are updated 2-5 times over their life.  And with about 15,000 added each day, I figure that is about 50,000 changes a day.
0
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

Kent OlsenDBACommented:
An UPDATE will keep the data in place (unless the size of a varchar item grows the row beyond the available space in the block) and only update the index on columns 3 and 4.

Unless there's a very unique set of circumstances, an UPDATE will be a lot faster than the DELETE/INSERT cycle that you're currently using.


Kent
0
GNiessenAuthor Commented:
Is it better to do a select on the Keys and then do IF EXISTS:

IF EXISTS (select * from MyTable where Col1 = @pCol1 and Col2 = @pCol2)
  UPDATE MyTable SET Col3 = @pCol3, Col4 = @pCol4, Col5 = @pCol5 
  WHERE  Col1 = @pCol1 and Col2 = @pCol2
ELSE
  INSERT MyTable (Col1, Col2, Col3, Col4, Col5) 
    SELECT @pCol1,@pCol2,@pCol3,@pCol4,@pCol5

Open in new window


, or can I do an UPDATE and then check if there were any rows effected?

UPDATE MyTable SET Col3 = @pCol3, Col4 = @pCol4, Col5 = @pCol5 
  WHERE  Col1 = @pCol1 and Col2 = @pCol2
SELECT @rc = @@ROWCOUNT
IF @rc = 0 THEN
  INSERT MyTable (Col1, Col2, Col3, Col4, Col5) 
    SELECT @pCol1,@pCol2,@pCol3,@pCol4,@pCol5

Open in new window

0
Kent OlsenDBACommented:
On SQL Server 2005 or higher (and DB2, and Oracle, and, etc.) use the MERGE statement.

MERGE INTO mytable t0
AS
(
  SELECT * FROM mytable
) t1
ON (t0.primary_key = t1.primary_key)
WHEN MATCHED
  THEN UPDATE SET ....
WHEN NOT MATCHED
  THEN INSERT ....


Kent
0
GNiessenAuthor Commented:
I thought MERGE was not available in 2005.  I know it is in 2008.  But I am in SQL Server 2005.  And I get errors on MERGE.
0
lcohanDatabase AnalystCommented:
In my opinion the IF EXISTS is the best.
You could use @@ROWCOUNT to get the number of rows affected by last SQL statement.
0
Kent OlsenDBACommented:
Oops.  You're correct.  I forget that SQL Server was a bit behind the curve on this one.  :)


Kent
0
lcohanDatabase AnalystCommented:
Just add the WITH (ROWLOCK) to the UPDATE like below in case you have a large number of rows to update so SQL wont decide to lock that table or pages due to lock escalation mechanism

IF EXISTS (select * from MyTable where Col1 = @pCol1 and Col2 = @pCol2)
  UPDATE MyTable WITH (ROWLOCK) SET Col3 = @pCol3, Col4 = @pCol4, Col5 = @pCol5
  WHERE  Col1 = @pCol1 and Col2 = @pCol2
ELSE
  INSERT MyTable (Col1, Col2, Col3, Col4, Col5)
    SELECT @pCol1,@pCol2,@pCol3,@pCol4,@pCol5
0
Scott PletcherSenior DBACommented:
Testing has shown that sometimes you get a performance gain by using a constant instead of * in an EXISTS check:


IF EXISTS (select 1 from MyTable where Col1 = @pCol1 and Col2 = @pCol2)
  UPDATE MyTable
  SET Col3 = @pCol3, Col4 = @pCol4, Col5 = @pCol5
  WHERE  Col1 = @pCol1 and Col2 = @pCol2
ELSE
  INSERT MyTable (Col1, Col2, Col3, Col4, Col5)
  SELECT @pCol1,@pCol2,@pCol3,@pCol4,@pCol5
0
GNiessenAuthor Commented:
That should help.  Testing it now.
0
GNiessenAuthor Commented:
I tried to increase points, but it didn't work.  Any idea why?
0
GNiessenAuthor Commented:
I am increasing to 500.  I will finish testing tomorrow morning.  It all looks good now.  I just got distracted by another effort.
0
GNiessenAuthor Commented:
The original process had a cost of 0.085 for an update (0.042 for Delete and 0.043 for an insert).  The new process is 0.243 (0.0003 for the Select and 0.024 for the update).  Multiplied by 50,000 time, that adds up.

Thanks
0
Kent OlsenDBACommented:
Just to clarify, is the new process time 0.0243 or 0.243?

Kent   :)
0
GNiessenAuthor Commented:
Yes, 0.0243.  :-)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2005

From novice to tech pro — start learning today.