Forum Moderators: open

Message Too Old, No Replies

lot of update statements

         

vaggos

4:59 pm on Dec 30, 2007 (gmt 0)

10+ Year Member



Hello,

I have some trouble with a script that is doing huge amount of update statements, and is locking a table all the time.

The update is like this 'update $xx_table set $v bbb=$bbb,lastview='$time' where id='$id'

It just saving some values each time, updating some numbers in the database.

What I could possible do to be able to do the update statements but not locking the tables almost all the time which brings the perfomance down?

Thanks for your time.

ZydoSEO

6:34 pm on Dec 30, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I'm not sure how much you've researched this, but MySQL does table level locking for certain types of tables, page level locking for others, and row level locking for yet other types of tables...

Perhaps this article will help.

[dev.mysql.com...]

It's hard to say what your problem might be, not knowing your application, how it is coded, use of transactions, etc.

[edited by: ZydoSEO at 6:36 pm (utc) on Dec. 30, 2007]

vaggos

8:22 pm on Dec 30, 2007 (gmt 0)

10+ Year Member



Thanks for the link, it's MyISAM so I can't use row locking.

I will try to give lower priority for update statements and see how it goes. I have lots of SELECTS and many updates on the same tables.

ZydoSEO

10:42 pm on Dec 30, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



It's hard to give suggestions sometimes without knowing the application and how it's coded, but we used to have code in our system like the following:

BEGIN TRANSACTION

perform some logic to determine what the update statement needs to look like
Execute the update statement
perform some logic to determine what the insert statement needs to look like for a log table
Execute the insert statement
...

COMMIT TRANSACTION

So a lot of the time spent inside the transaction with tables locked was actually executing application logic or trying to dynamically build the SQL statements or stored proc calls. We found that 95% of the time inside the transaction in some cases was spent performing non-DB logic.

We greatly reduced time inside the transaction (and thus reducing the time that tables were locked) by executing all of the logic first to build a collection or array of SQL statements which need to be executed and THEN beginning a transaction, cycling through the array executing each statement, and then committing the transaction. So the logic above then became something along the lines of:

perform some logic to determine what the update statement needs to look like
Insert the update statement into collection/array
perform some logic to determine what the insert statement needs to look like for a log table
Insert the insert statement into collection/array
...
BEGIN TRANSACTION
For i = 1 to upperbound of collection/array
Execute the SQL in collection/array[i]
COMMIT TRANSACTION

This should help minimize the amount of time the tables are locked.

Sorry for the pseudocode... But hopefully it gets the point across.

[edited by: ZydoSEO at 10:44 pm (utc) on Dec. 30, 2007]

lammert

2:57 pm on Dec 31, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Transactions are not supported on MyISAM so that is not the problem in this case.

A possible solution might be to convert the offending table to InnoDB because it supports row locking. Please be aware that the InnoDB database driver in general takes more time per statement to execute compared to the MyISAM driver so it might not be a solution if you have a very busy system.

vaggos

5:02 pm on Dec 31, 2007 (gmt 0)

10+ Year Member




The updates are not so important I mean that I don't care if they delay or something. It just adds a new value to the previous value stored in these two rows.