You may not realize it, but in MariaDB 5.2 and earlier and in MySQL up to version 5.5, START TRANSACTION WITH CONSISTENT SNAPSHOT does not give any guarantees of consistency between different storage engines.

For example, suppose you have two transactions which run in parallel:

Transaction T1:

BEGIN;
    SET @t = NOW();
    UPDATE xtradb_table SET a= @t WHERE id = 5;
    UPDATE pbxt_table SET b= @t WHERE id = 5;
    COMMIT;

Transaction T2:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
    START TRANSACTION WITH CONSISTENT SNAPSHOT;
    SELECT t1.a, t2.b
      FROM xtradb_table t1 INNER JOIN pbxt_table t2 ON t1.id=t2.id
    WHERE t1.id = 5;

In the above case, it is possible, even with a "consistent" snapshot, to see the changes in a transaction only in InnoDB/XtraDB tables, and not in PBXT tables.

Naturally, it would be much better if the changes were visible no matter the …

The information here was adapted from the AskMonty Knowledgebase.

There are two main parts to MariaDB and MySQL: The mysqld server and whatever client you use to interact with the server. The server is absolutely essential and must remain up and running. mysqld is normally very reliable, but there are rare occasions when it will fail. When mysqld fails hard (or core dump) it will, by default, write a stack trace in the 'hostname'.err file in the database directory. However, in some cases this is not enough to find out exactly what happened.

If you ever run into a situation where mysqld crashes and the 'hostname'.err file does not contain enough information for your DBA or support provider to diagnose the problem, you may need to use what is known as a "debug" build to produce a "full stack trace" and a core file. …

Whenever I start a new project with MySQL or MariaDB I am tempted to jump in and start creating my schema and tables with nothing more than a basic outline of the requirements. Often the justification I give myself is that the sooner I have something up and running, the better off I'll be, and besides, there will be plenty of time to sort things out later. Even when I am absolutely sure my ad-hoc schema is only for "development purposes" and will "never ever be used in production" it often is.

A lot of grief can be avoided if time is taken right at the start, before any tables are defined, to plan. This is big picture time and every stakeholder, from IT to the developers to management and even to marketing, needs to be involved. If for no other reason than to set expectations.

Right at the start, everyone involved in the project needs to know that there is no perfect data definition, and no one …

One issue that developers often run into is needing or wanting to run a development version of MariaDB or MySQL on their desktop when there is already a production version installed. You may want to try out a new feature, or experiment with a patch, or maybe you're developing a new storage engine, or just having fun hacking on the code. Whatever the reason, when this happens to me I often want to be able to run the non-standard version without replacing my currently installed version.

Fortunately, the process for doing so is easy. The instructions below are adapted from the Running MariaDB from the source directory article in the AskMonty Knowledgebase.

Before beginning, make sure you shut down your running instance of mysqld before starting your test instance. It is possible to run multiple mysqlds on the same server, but doing so is …

A common error in SQL is with quotes. Luckily, compared to other databases, MariaDB and MySQL are very forgiving.

For example, suppose I have a "products" table for an online store. If I want to look up every product which has a price of 5.99 or more I might use the following query:

MariaDB [crashcourse]> select prod_id, prod_name, prod_price from products
    -> where prod_price >= 5.99;
+---------+----------------+------------+
| prod_id | prod_name      | prod_price |
+---------+----------------+------------+
| ANV01   | .5 ton anvil   |       5.99 |
| ANV02   | 1 ton anvil    |       9.99 |
| ANV03   | 2 ton anvil    |      14.99 |
| OL1     | Oil can        |       8.99 |
| TNT2    | TNT (5 sticks) |      10.00 |
| FB      | Bird seed      |      10.00 |
| SAFE    | Safe           |      50.00 |
| DTNTR   | Detonator      |      13.00 |
| JP1000  | JetPack 1000   |      35.00 |
| JP2000  | JetPack 2000   |      55.00 | …

A customer of ours had an interesting problem regarding a query that was taking too long, around 55s. Looking at the query with the query profiler we found that it was spending most of its time in the "statistics" phase. Now the query was pretty complex, it contained nearly 20 tables with INNER JOINs, LEFT JOINs and even some subqueries. However the tables were small and fetching all the data shouldn't have taken the 55 seconds the query was taking. The problem was that the optimiser was spending too much time evaluating and finding the optimal execution plan.

There are two options in MySQL with which you can control the optimiser's behaviour a bit. The first one is optimizer_prune_level. The pruner discards non-optimal execution plans early without evaluating them fully. It is turned on by default and is not recommended to turn off unless there's a really good reason. For testing purposes we turned the pruner off for this query, but after …