That's a really fascinating post. Definitely worth the time to read. Thanks.
One of the things I don't understand is how the ACID properties carry over. InnoDB is fully transactional and ACID-compliant, but how does it manage this without the SQL locking that was slowing it down? Said another way, if the table/row locking overhead from SQL queries was such a problem, why is it in MySQL at all?
Also, the problems he identified don't seem like they should be problems. Shouldn't you be able to all but eliminate SQL parse costs with prepared statements? Why are his PK inserts and reads causing table locks (since Google tells me you can turn this off)? This strikes me as weird.
Comments
That's a really fascinating post. Definitely worth the time to read. Thanks.
One of the things I don't understand is how the ACID properties carry over. InnoDB is fully transactional and ACID-compliant, but how does it manage this without the SQL locking that was slowing it down? Said another way, if the table/row locking overhead from SQL queries was such a problem, why is it in MySQL at all?
Also, the problems he identified don't seem like they should be problems. Shouldn't you be able to all but eliminate SQL parse costs with prepared statements? Why are his PK inserts and reads causing table locks (since Google tells me you can turn this off)? This strikes me as weird.