Shard-Query is an open source tool kit which helps improve the performance of queries against a MySQL database by distributing the work over multiple machines and/or multiple cores. This is similar to the divide and conquer approach that Hive takes in combination with Hadoop. Shard-Query applies a clever approach to parallelism which allows it to [...]
Flexviews – part 3 – improving query performance using materialized views
April 4, 2011 By 20 Comments
Combating “data drift” In my first post in this series, I described materialized views (MVs). An MV is essentially a cached result set at one point in time. The contents of the MV will become incorrect (out of sync) when the underlying data changes. This loss of synchronization is sometimes called drift. This is conceptually [...]
Moving from MyISAM to Innodb or XtraDB. Basics
November 22, 2010 By 2 Comments
I do not know if it is because we’re hosting a free webinar on migrating MyISAM to Innodb or some other reason but recently I see a lot of questions about migration from MyISAM to Innodb. Webinar will cover the process in a lot more details though I would like to go over basics in [...]
Shard-Query adds parallelism to queries
November 15, 2010 By 18 Comments
Preamble: On performance, workload and scalability: MySQL has always been focused on OLTP workloads. In fact, both Percona Server and MySQL 5.5.7rc have numerous performance improvements which benefit workloads that have high concurrency. Typical OLTP workloads feature numerous clients (perhaps hundreds or thousands) each reading and writing small chunks of data. The recent improvements to [...]
A workaround for the performance problems of TEMPTABLE views
May 19, 2010 By 7 Comments
MySQL supports two different algorithms for views: the MERGE algorithm and the TEMPTABLE algorithm. These two algorithms differ greatly. A view which uses the MERGE algorithm can merge filter conditions into the view query itself. This has significant performance advantages over TEMPTABLE views. A view which uses the TEMPTABLE algorithm will have to compute the [...]
Debugging problems with row based replication
May 6, 2010 By 12 Comments
MySQL 5.1 introduces row based binary logging. In fact, the default binary logging format in GA versions of MySQL 5.1 is ‘MIXED’ STATEMENT*; The binlog_format variable can still be changed per sessions which means it is possible that some of your binary log entries will be written in a row-based fashion instead of the [...]
When the subselect runs faster
March 18, 2010 By 9 Comments
A few weeks ago, we had a query optimization request from one of our customer. The query was very simple like:
1 | SELECT * FROM `table` WHERE (col1='A'||col1='B') ORDER BY id DESC LIMIT 20 OFFSET 0 |
This column in the table is looks like this:
1 | `col1` enum('A','B','C','CD','DE','F','G','HI') default NULL |
The table have 549252 rows and of course, there is an index on the col1. MySQL estimated the cardinality of that index as [...]
Air traffic queries in InfiniDB: early alpha
November 2, 2009 By 19 Comments
As Calpont announced availability of InfiniDB I surely couldn’t miss a chance to compare it with previously tested databases in the same environment. See my previous posts on this topic: Analyzing air traffic performance with InfoBright and MonetDB Air traffic queries in LucidDB I could not run all queries against InfiniDB and I met some [...]
MySQL-Memcached or NOSQL Tokyo Tyrant – part 3
October 19, 2009 By 25 Comments
This is part 3 of our series. In part 1 we talked about boosting performance with memcached on top of MySQL, in Part 2 we talked about running 100% outside the data with memcached, and now in Part 3 we are going to look at a possible solution to free you from the database. The [...]
Multi Column indexes vs Index Merge
September 19, 2009 By 31 Comments
The mistake I commonly see among MySQL users is how indexes are created. Quite commonly people just index individual columns as they are referenced in where clause thinking this is the optimal indexing strategy. For example if I would have something like AGE=18 AND STATE=’CA’ they would create 2 separate indexes on AGE and STATE [...]
