where 0 = 1 |
Post Reply |
Author | |
yapadu
Senior Member Joined: 12 May 2005 Status: Offline Points: 297 |
Post Options
Thanks(0)
Posted: 17 June 2010 at 6:15pm |
I am having some database issues today, mysql. When using the thread monitor, I see a lot of locked queries.
Most of them look like this: select * from tblmsgs where 0 = 1 This seems like a strange query. I ran the query myself and it is normally quick, but sometimes the database is locked and it takes over 180 seconds. |
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
leeH
Newbie Joined: 22 October 2007 Status: Offline Points: 7 |
Post Options
Thanks(0)
|
I've been fighting database problems for years now. Today I changed the tables to InnoDB and I have not had one issue since! So far that cured my database issues...
Lee
|
|
yapadu
Senior Member Joined: 12 May 2005 Status: Offline Points: 297 |
Post Options
Thanks(0)
|
I have never had database issues that I have noticed in the past (too small I guess). I have been monitoring my situation for a couple of hours, it does not happen all the time but there is some query that is locking the table and seems to take a while to complete.
I have not tracked down the offending query yet. I checked my tables and the breakdown is as follows: tbl_filters InnoDB tbl_localdomains InnoDB tbl_logindomains InnoDB tblbl_attachments InnoDB tblbl_countries InnoDB tblbl_domains InnoDB tblbl_emailfrom InnoDB tblbl_emailsto InnoDB tblbl_honeypotblockedips InnoDB tblbl_honeypotemails InnoDB tblbl_ips InnoDB tblbl_keywords InnoDB tblbl_maps InnoDB tblbl_surlbl InnoDB tbllogins InnoDB tblmsgs MyISAM < tblquarantine MyISAM < tblrejectcodes MyISAM < tblreloadtableinfo InnoDB tblservers MyISAM < tblwl_authorizedtoemails InnoDB tblwl_autowhitelistforcedeliveryInnoDB tblwl_domainips InnoDB tblwl_emailsfrom InnoDB tblwl_eaiilsto InnoDB tblwl_keywords InnoDB So I have a few MyISAM, but mostly InnoDB. I checked the database scripts that create the tables, and according to those scripts I should have all InnoDB tables. I don't know why some of my tables are MyISAM. So Roberto, did SF on mysql ever use MyISAM or did my tables change in error somehow? Because of the record locking on InnoDB, vs table locking on MyISAM I would think InnoDB would be the better choice here. I don't like to make changes to the database on which any software I did not make runs, so I am really amazed those few tables are MyISAM. Should I change them back Roberto? |
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
The SQl statement:
select * from tblmsgs where 0 = 1 is used internally by SpamFilter to return an empty recordset so that rows can then be appended to it, and then added to the database. In regards to the MyISAM/InnoDB, all the quarantine-related tables are created with MyISAM as it "should" perform better with massive row INSERTs and very few SELECTs. All the tables used by SpamFilter "Enterprise" are InnoDB as they are smaller (by several orders of magnitude) when compared to the quarantine tables, and are used mainly with SELECT statements, and so InnoDB "should" perform better there. Notice the two "should"s.... At the end, if based on your experience/server load, it's preferable to change the table format to improve performance, you can very well override our recommendations if you notice improvements :-)
|
|
yapadu
Senior Member Joined: 12 May 2005 Status: Offline Points: 297 |
Post Options
Thanks(0)
|
So my MyISAM tables were inherited from before enterprise came out.
I am going to switch to InnoDB and see how it goes with that, since I don't like the table locking when reading. I do quite a bit of reading from the table to generate reports for users etc. |
|
--------------------------------------------------------------
I am a user of SF, not an employee. Use any advice offered at your own risk. |
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.148 seconds.