简体   繁体   中英

SQL DELETE performance

delete from a A where a.ID = 132.

The table A contains around 5000 records and A.ID is the primary key in the table A. But it is taking a long time to delete . Sometimes its getting timed out also . That table contains three indexes and it is referenced by three foreign keys . Can anyone explain me why its taking long time even though we are deleting based on the primary key . And please tell me some way to optimize this problem ...?

Possible causes:

1) cascading delete operations

2) trigger(s)

3) the type of your primary key column is something other than an integer, thereby forcing a type conversion on each pk value to do the comparison. this requires a full table scan.

4) does your query really end in a dot like you posted it in the question? if so, the number may considered to be a floating point number instead of an integer, thereby causing a type conversion similar to 3)

5) your delete query is waiting for some other slow query to release a lock

Obviously it should not be taking a long time. However, there isn't enough information here to figure out exactly why. I can tell you, though, that you should focus on the Foreign Keys.

These can slow things down if they impose constraints from other, much larger, tables. You may also find out that your timeouts are due to integrity checks that prevent the delete (then the question is why you aren't getting exceptions instead of a timeout).

My next step would be to remove the foreign keys and then check performance. Then add each one back in at a time and check performance as you go.

Are other operations (eg Inserts, Selects, Updates) taking a long time?

First thought: Indexes on foreign keys?

  • This is related to cascading deletes mentioned
  • All child tables muts be checked and if you have a total of 500,000 child rows, this might take some time of course...

Second thought: Triggers firing?

  • On this table or on child tables or trying to cascade via code etc
  • God forbid, cursor for each row in DELETED...

Try to update the statistics. 5000 rows is not a big deal. If you're doing this regularly you should schedule maintenance on that table as well (ie re-build indexes, update stats etc.)

As others have observed, the probable suspects are the foreign keys.

Firstly because the ON DELETE CASCADE can gather momentum if the dependent tables in turn are referenced by other tables, which in turn may be referenced, and so on.

Secondly, because other users may have locks on the rows which need to be deleted. This is the most likely cause of the timeouts. Quite how this works will depend on the flavour and version of your database. For instance, older versions of Oracle (<=8.0) needed to lock the entire dependent table unless the foreign key columns were indexed.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM