Percona Live : MySQL Conference and Expo 2013 (Slides, tweets and more…)


MySQL Conference & Expo






This year again, the MySQL Conference and Expo, hosted by Percona, smells like a wonderful event.
I haven’t the chance to attend this event but I would like to share with you the soul of this one.
I’ll try to share latest news, tweets and slides from the event in this live post.

Stay tuned and come back!

Breaking news!

highlighted tweets



An incomplete list of what your developers would like to know before migrating to MySQL 5.5

A few years ago, I asked to check with me in the long (very long) change history of MySQL 5.5 documentation what are the changes in relation to the SQL syntax.
Chris Calender helped me to retrieve a list of the main changes, thanks again Chris.

Today, I would like to share this list with you.
It is simply a curated transcript of what you might find in the documentation but I’m sure it can help some of you.

INTO clause in nested SELECT statements

Previously, the parser accepted an INTO clause in nested SELECT statements, which is invalid because such statements must return their results to the outer context. As of MySQL 5.5.3, this syntax is no longer permitted and statements that use it must be changed.

Table aliases in DELETE statements

In MySQL 5.5.3, several changes were made to alias resolution in multiple-table DELETE statements so that it is no longer possible to have inconsistent or ambiguous table aliases.

In MySQL 5.1.23, alias declarations outside the table_references part of the statement were disallowed for the USING variant of multiple-table DELETE syntax, to reduce the possibility of ambiguous aliases that could lead to ambiguous statements that have unexpected results such as deleting rows from the wrong table.

As of MySQL 5.5.3, alias declarations outside table_references are disallowed for all multiple-table DELETE statements. Alias declarations are permitted only in the table_references part.


  • DELETE FROM t1 AS a2 USING t1 AS a1 INNER JOIN t2 AS a2;
  • DELETE t1 AS a2 FROM t1 AS a1 INNER JOIN t2 AS a2;


  • DELETE t1 FROM t1 AS a1 INNER JOIN t2 AS a2;

Previously, for alias references in the list of tables from which to delete rows in a multiple-table delete, the default database is used unless one is specified explicitly. For example, if the default database is db1, the following statement does not work because the unqualified alias reference a2 is interpreted as having a database of db1:

  • DELETE a1, a2 FROM db1.t1 AS a1 INNER JOIN db2.t2 AS a2 WHERE;

To correctly match an alias that refers to a table outside the default database, you must explicitly qualify the reference with the name of the proper database:

  • DELETE a1, db2.a2 FROM db1.t1 AS a1 INNER JOIN db2.t2 AS a2 WHERE;

As of MySQL 5.5.3, alias resolution does not require qualification and alias references should not be qualified with the database name. Qualified names are interpreted as referring to tables, not aliases.

Statements containing alias constructs that are no longer permitted must be rewritten.

New reserved words

There are several new reserved words in 5.5 what were not reserved in 5.1.
So if you are using any of these as table names, etc., then you’ll need to surround them with backticks (`)

  • SLOW



As of MySQL 5.5.3, due to work done for Bug #989, FLUSH TABLES is not permitted when there is an active LOCK TABLES … READ.
To provide a workaround for this restriction, FLUSH TABLES has a new variant, FLUSH TABLES tbl_list WITH READ LOCK, that enables tables to be flushed and locked in a single operation.
As a result of this change, applications that previously used this statement sequence to lock and flush tables will fail:

  • LOCK TABLES tbl_list READ;
  • FLUSH TABLES tbl_list;

Such applications should now use this statement instead:



Fast truncation

As of MySQL 5.5.7, InnoDB always uses the fast truncation technique, equivalent to DROP TABLE and CREATE TABLE.
It no longer performs a row-by-row delete for tables with parent-child foreign key relationships.
TRUNCATE TABLE returns an error for such tables.
Modify your SQL to issue DELETE FROM table_name for such tables instead.

TIMESTAMP display width

In very old versions of MySQL (prior to 4.1), the TIMESTAMP data type supported a display width, which was silently ignored beginning with MySQL 4.1.
This is deprecated in MySQL 5.1, and removed altogether in MySQL 5.5.

The display width is no longer supporter for TIMESTAMP data type in MySQL 5.5

Aliases and wildcards

Aliases for wildcards (as in SELECT t.* AS 'alias' FROM t) are no longer accepted and result in an error.
Previously, such aliases were ignored silently. (Bug #27249)

Scientific notation

In addition to these official parts of the MySQL release notes, Sheeri write a post about floats, doubles ans scientific notation between MySQL 5.1 and MySQL 5.5 :


This list is incomplete because I’m sure you have your own tips to share.

Source :

The strange commit behavior and the invisible Xid_log_event

Did you see this when you are migrating from your lovely MySQL 5.1 to MySQL 5.5?
Oh, sorry, you remain attached to your pretty 4.1. Yes, I know, MyISAM has become so important in your life…

Ok, seriously, I would like to share this little observation I made recently when switching to MySQL 5.5 on one slave.
You can see below two graphs for the transactional activity, there is exactly the same volume of update, delete and insert queries :

MySQL 5.1

Screenshot 2013-04-15 at 06.34.23 PM

MySQL 5.5Screenshot 2013-04-15 at 06.32.42 PM

But the gray area represents the number of commit per second.
I find that I have much more commit with MySQL 5.5, why?
The first question I asked to myself was whether MySQL was telling the truth…

And I had three options to know the truth :

  • The com_commit counter : I compared the number of begin and commit during ten minutes
    • MySQL 5.1 : I got much more begin than commit
    • MySQL 5.5 : I got exactly the same result between begin and commit
  • The relay logs : In a sample of logs, I compared the number of begin and commit 
    • MySQL 5.1 : I got exactly the same result between begin and commit
    • MySQL 5.5 : I got exactly the same result between begin and commit
  • The genaral log : I compared the number of begin and commit during ten minutes
    • MySQL 5.1 : I got exactly the same result between begin and commit
    • MySQL 5.5 : I got exactly the same result between begin and commit

Hum, ok, the com_commit counter want to play with me!

Let’s go in the general log, I had two kinds of commit output :

Query COMMIT /* implicit, from Xid_log_event */

So, I called a friend : Hey Google, what is this (f…) Xid_log_event?

Hum, it smells replication…

Yes, you guessed it, the commit statements from the replication stream are not recorded in the com_commit counter in 5.1.
But the begin statements are recorded in the com_begin counter…

Look at your own slave servers and compare!


An incomplete guide to linux system configuration for MySQL

As a former Oracle DBA, I know how the system and the database are linked.
The first one who told me that the installation of Oracle has never been a problem is a liar!
Yes, your database and your system are the best of friends, you must respect that.

I’d make a list of linux system settings to configure a MySQL databases server and share my sources with you.
In return, I would like you to share your sources with the community by publishing your tips in the comments.



  • This parameter allows to specify how the kernel must manage the memory swap
  • Default value : 60 (Range 0 to 100)
  • Value to set : 0 (it will swap only to avoid an out of memory condition)
  • How to set a new non-persistent value :  sysctl -w vm.swappiness=0
  • How to store a new persistent value : add vm.swappiness=0 in the /etc/sysctl.conf file


I/O Scheduler


  • The I/O scheduler manages and optimizes priorities of I/O requests
  • Default value : device driver dependent
  • Range of values : noop / deadline / anticipatory / cfq
  • Value to set : noop
  • How to set a new persistent value : echo noop >/sys/block/[DEVICE]/queue/scheduler


Mounting options


  • These options are set during the filesystem mount process
  • Default value : rw
  • Value to set ext4 : rw,nosuid,noatime,data=ordered
  • Value to set xfs : nobarrier
  • How to store a new persistent value : add these options in the /etc/fstab file


I/O queue size


  • This queue stores incoming I/O requests
  • Default value : 128 (No range)
  • Value to set : Hey Dude, you have to test, no magic value for this parameter
  • How to set a new persistent value :  echo 100000 > /sys/block/[DEVICE]/queue/nr_requests


Dirty ratio


  • These settings are used to tune the VM subsystem about dirty data
  • Default value : 10 and 20
  • Value to set : Again, you should test. You can try 5 and 60 to begin
  • How to set a new non-persistent value :
    • echo 5 > /proc/sys/vm/dirty_background_ratio
    • echo 60 > /proc/sys/vm/dirty_ratio
  • How to store a new persistent value : Add these parameters to the /etc/sysctl.conf file
    • vm.dirty_background_ratio = 5
    • vm.dirty_ratio = 60

NUMA Architecture


Note that all of these tips focus on optimizing I/O.
The first three tips can be considered as really interesting.
I recommend you to read the sources before any change.

Remember to test every changes before to put them in production.

Now, let us know how you setup your system for MySQL.

Sources :