I'm relatively new to mySQL so please be easy on me.
I have an application which does a lot of this:
UPDATE table SET state='something' WHERE primary_key=x
on a couple tables that look like this (simplified):
CREATE TABLE table (
primary_key INT UNSIGNED AUTO_INCREMENT,
....
state ENUM( 'thing1', 'thing2'.....) NOT NULL,
PRIMARY KEY (primary_key)
) /*! ENGINE = INNODB */ ;
So I'm updating one row at a time, but doing it a lot of times, from a lot of clients (50-500) a handful of times per minute per client. I don't really wrap the updates (or any other SQL calls for that matter) inside transactions because I only need each statement to be atomic, not a sequence of statements. I'm not locking tables because I expect the database will lock what it needs (row-level using InnoDB) when the UPDATE executes.
When I run with InnoDB versions of the table, I find that the writes fail to occur a small percentage of the time. I have not happened upon any errors to let me know this is happening, but over time the states become out of sync with reality and the whole system dies a slow death as the states don't make sense any more.
With ISAM tables, the database runs "correctly" in that no writes are lost, but all the clients are blocking on the write long on the table so that performance is pretty poor - correct but poor.
I'm under the impression that this is a case where InnoDB should clearly outshine ISAM. Since ISAM locks tables, its performance problem makes sense to me. It should excel under a heavy-read load. In the SQL WorkBench, I see that the connections to InnoDB versions of the table clear very quickly -- but a small fraction of the writes must be failing because over time the states don't make sense. Same application, just changing the type of the table.
I have tested the InnoDB engine (and ISAM) in mySQL 5.1.48 and 5.1.50, 64b for Windows.
Is this a known issue; is there a configuration I need to do; is my UPDATE statement malformed or does it need to be wrapped inside some kind of transaction? I have not been able to find any information that seems relevant.
Thanks.
I have an application which does a lot of this:
UPDATE table SET state='something' WHERE primary_key=x
on a couple tables that look like this (simplified):
CREATE TABLE table (
primary_key INT UNSIGNED AUTO_INCREMENT,
....
state ENUM( 'thing1', 'thing2'.....) NOT NULL,
PRIMARY KEY (primary_key)
) /*! ENGINE = INNODB */ ;
So I'm updating one row at a time, but doing it a lot of times, from a lot of clients (50-500) a handful of times per minute per client. I don't really wrap the updates (or any other SQL calls for that matter) inside transactions because I only need each statement to be atomic, not a sequence of statements. I'm not locking tables because I expect the database will lock what it needs (row-level using InnoDB) when the UPDATE executes.
When I run with InnoDB versions of the table, I find that the writes fail to occur a small percentage of the time. I have not happened upon any errors to let me know this is happening, but over time the states become out of sync with reality and the whole system dies a slow death as the states don't make sense any more.
With ISAM tables, the database runs "correctly" in that no writes are lost, but all the clients are blocking on the write long on the table so that performance is pretty poor - correct but poor.
I'm under the impression that this is a case where InnoDB should clearly outshine ISAM. Since ISAM locks tables, its performance problem makes sense to me. It should excel under a heavy-read load. In the SQL WorkBench, I see that the connections to InnoDB versions of the table clear very quickly -- but a small fraction of the writes must be failing because over time the states don't make sense. Same application, just changing the type of the table.
I have tested the InnoDB engine (and ISAM) in mySQL 5.1.48 and 5.1.50, 64b for Windows.
Is this a known issue; is there a configuration I need to do; is my UPDATE statement malformed or does it need to be wrapped inside some kind of transaction? I have not been able to find any information that seems relevant.
Thanks.