Over last few years I’ve been suggesting more people to disable Query Cache than to enable it. It can cause contention problems as well as stalls and due to coarse invalidation is not as efficient as it could be. These are however mostly due to neglect Query Cache received over almost 10 years, with very [...]
MySQL Limitations Part 4: One thread per connection
October 27, 2010 By 14 Comments
This is the third in a series on what’s seriously limiting MySQL in core use cases (links: part 1, 2, 3). This post is about the way MySQL handles connections, allocating one thread per connection to the server.
Sharing an auto_increment value across multiple MySQL tables
October 4, 2010 By 9 Comments
The title is SEO bait – you can’t do it. We’ve seen a few recurring patterns trying to achieve similar – and I thought I would share with you my favorite two: Option #1: Use a table to insert into, and grab the insert_id:
1 2 3 4 5 | CREATE TABLE option1 (id int not null primary key auto_increment) engine=innodb; # each insert does one operations to get the value: INSERT INTO option1 VALUES (NULL); # $connection->insert_id(); |
Option #2: Use a table with one just row:
1 2 3 4 5 6 | CREATE TABLE option2 (id int not null primary key) engine=innodb; INSERT INTO option2 VALUES (1); # start from 1 # each insert does two operations to get the value: UPDATE option2 SET id=@id:=id+1; SELECT @id; |
Why you should ignore MySQL’s key cache hit ratio
February 28, 2010 By 28 Comments
I have not caused a fist fight in a while, so it’s time to take off the gloves. I claim that somewhere around of 99% of advice about tuning MySQL’s key cache hit ratio is wrong, even when you hear it from experts. There are two major problems with the key buffer hit ratio, and [...]
Tokyo Tyrant -The Extras Part III : Write Bottleneck
November 12, 2009 By 3 Comments
This is part 3 of my Tyrant extra’s, part 1 focused on durability, part 2 focused on the perceived performance wall. #3. Tokyo Cabinet Can have only a single writer thread, bottlenecking performance When writing an application using Tokyo Cabinet only one connection can be opened as a “writerâ€Â while the rest are readers. Tyrant [...]
Talking MySQL to Sphinx
April 19, 2009 By 4 Comments
In the recently released Sphinx version 0.9.9-rc2 there is a support for MySQL wire protocol and SphinxQL – SQL-like language to query Sphinx indexes. This support is currently in its early preview stage but it is still fun to play with. A thing to mention – unlike MySQL Storage Engines, some of which as InfoBright [...]
How much memory can MySQL use in the worst case?
February 12, 2009 By 17 Comments
I vaguely recall a couple of blog posts recently asking something like “what’s the formula to compute mysqld’s worst-case maximum memory usage?” Various formulas are in wide use, but none of them is fully correct. Here’s why: you can’t write an equation for it.
Fix of InnoDB/XtraDB scalability of rollback segment
January 18, 2009 By 9 Comments
Recently I wrote about InnoDB scalability on 24-core box, and we made research of scalability problems in sysbench write workload (benchmark emulates intensive insert/delete queries). By our results the problem is in concurrency on rollback segment, which by default is single and all transactions are serialized accessing to segment. Fortunately InnoDB internally has mechanism to [...]
Announce: Front End Performance Optimization
October 10, 2008 By 8 Comments
I guess many of you know us and so our company for MySQL related services. It is true this is majority of our business at this point but it is far from everything. Our goal in reality is to help people to build and operate quality systems, typically web sites, which means we help customers [...]
How network can impact MySQL Operations ?
September 1, 2008 By 5 Comments
This week I’ve worked with the customer doing certain work during maintenance window which involved a lot of data copying around between MySQL boxes. We had prepared well and had measured how fast we could copy the data between servers of these kind connected to the same network, and we did the same thing before. [...]
