You are here


Query performance comparison between MariaDB ColumnStore and other Storage Engines

Storage Engines like InnoDB, Aria and MyISAM are Row Stores. They store rows one after the other in blocks or even directly in a single file (MyISAM). On the other hand a Column Store like MariaDB ColumnStore stores all the same attributes (columns) of the rows together in chunks.

This is how the table sales_fact looks like:

SQL Query Tuning - Performance

How could the following SQL queries be improved performance wise and otherwise and can you also explain why your change is more optimal?

Please consider, when testing, that your results are not confused by the Query Cache or by reading data from your I/O system which are an order of magnitude faster (Query Cache) or slower (I/O) than the in-memory behaviour.


Creating synthetic data sets for tuning SQL queries

When it comes to SQL Query tuning with customers we often get the slow running SQL query and possibly, in good cases, also the table structure. But very often, for various reasons, we do not get the data.

MySQL single query performance - the truth!

MySQL single query performance - the truth!

As suggested by morgo I did a little test for the same query and the same data-set mentioned in Impact of column types on MySQL JOIN performance but looking into an other dimension: the time (aka MySQL versions).

The answer

To make it short. As a good consultant the answer must be: "It depends!" :-)

Impact of column types on MySQL JOIN performance

Taxonomy upgrade extras: 

In our MySQL trainings and consulting engagements we tell our customers always to use the smallest possible data type to get better query performance. Especially for the JOIN columns.

MySQL Queries taggen

Taxonomy upgrade extras: 

Früher, lange, lange ist's her, konnte man den folgenden Trick verwenden um MySQL Queries in der Applikation zu taggen:

SELECT /* My Application Tag */ * FROM test;

Im Slow Query Log und im General Query Log ist das SQL Query dann wie folgt erschienen:

# Time: 111020 22:03:33
# User@Host: root[root] @ localhost []  Id:  1335
# Query_time: 17.873938  Lock_time: 0.007952 Rows_sent: 12048576  Rows_examined: 12048576
use test;
SET timestamp=1319141013;
SELECT /* My Application Tag */ * FROM test;


Subscribe to RSS - query