How to shrink the ibdata file by transporting tables with Trite

You’ve probably had some troubles with the shared InnoDB tablespace stored in the ibdata file. Especially when it has grown for some reasons and reached a critical size.

This behavior occurs in some cases, due to excessive rollback segments growth or during a migration from a unique shared tablespace to a file-per-table configuration for example.

In this post, I would like to explain how to shrink the ibdata file after an unwanted file growth in a file-per-table configuration.
Note that the process could be done without Trite but the tool avoids to write the script used to transport tables yourself.

Continue reading “How to shrink the ibdata file by transporting tables with Trite” »

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 :

How I use twitter to follow the MySQL Community

Here is a perfect post to read during your holidays :-)
There are many ways to get news on the internet : blogs, rss feeds, facebook, linkedin, twitter…
What I want to talk about here is how I use twitter to follow the MySQL Community and how I stay up to date of the latest news.
I use twitter only for focus on the MySQL news and the MySQL community, that’s why I would like to share this experience with you.

Step 1 : Choose your friends

Q: What is the most complicated with Twitter ?
A: Read all the tweets that we receive every day

Of course it can be complicated and that takes a long long time…
That’s why you must choose who is your best friends carefully.

Except for the MySQL rock stars, I advise you to use TweetStats before to blindly follow anyone who tweeted a dark grigri about MySQL.
It’s very simple, just enter the username of the woman, man, firm or product you want to follow on the home page of Tweestats and let the magic gone.
This tool let you know exactly how many tweets a user published by month (or day).

I recommend to follow only the people who don’t publish more than 100 tweets per month (or 4 tweets per day).
Yes, only 4 tweets per day, if you have 100 friends, this means you have to read 400 tweets per day. Are you really able to read all of them ?!
And don’t forget that behind the Tweet there is often a link…

Step 2 :  Lists, Search and tools

Lists are one of the most interesting Twitter feature and I’m sure many of you don’t use them.
Lists are useful in many cases, take a look at this two examples  :

  • You use Twitter to track different types of information (Family and Friends, Sports, MySQL, Geek news…)
  • The people you follow are cosmopolitan and speak different languages
So, how to stay focused on the MySQL news across this jungle ?
I use TweetDeck to read through the lists, one list for the UK/US twittos, another one for the French twittos and a special column for my favorites.



Another really awesome feature of TweetDeck is the research in live streaming, perfect for tracking a live events.
For example, I’m currently using 4 search columns : “MySQL OR Percona OR MariaDB“, “#perconalive“, “MySQL AND slides”  and “#OSCON


Step 3 : The best way to tweet


If you want that your tweets are broadcast in a perfect fluidity, you need to use a Buffer.
This tool helps you to schedule your tweets, on twitter and linkedIn (very useful now that twitter no longer speak to linkedIn)


Q: Why I really need to use Bufferapp ?
A: Because your followers don’t want to receive all your tweets in the same time ;-)


And this tool will also let you know if your tweets are read, this is why you write them, isn’t it ?


Step 4 : One more thing (or two)


I like to backup my own tweets because these tweets are often some links to articles that I like.
My other vice is to receive my favorite tweets via email.
To do that, I put the internet to work for me with ifttt.

These two rules send my own tweets in my Evernote and send me an email for each favorite tweet, automatically !
Really awesome when I wish to find an old tweet in my Evernote or when I press the “favorite” button in TweetBot.


If you want to follow me, I always tweet about MySQL !

Fatal timeout !

There are several parameters to set a timeout on MySQL :

But I would like to focus on wait_timeout (or interactive_timeout depending on how you connect)

This timeout allows MySQL to automatically close a connection in case of non-activity during the time defined by this parameter (default value is 28000 seconds).

The problem I wish to explain here may happen when this timeout is set to a low value (about 10 to 30 seconds).

Indeed, in this case, this timeout may have serious consequences, look at that :
[The wait_timeout parameter is set to 10 seconds in this case]

You are connected through the standard MySQL client and you need to run a delete query (bypass autocommit) :

  • mysql> start transaction;
  • [ You wait more than 10s because a friend calls your attention about the latest news on iphone 5 ! ]
  • mysql> delete from most_valuable_table;

Your problem starts here because you forgot the where clause !
After the delete command, MySQL said :

ERROR 2006 (HY000): MySQL server has gone awayNo connection. Trying to reconnect... Connection id:    98 Current database: masterQuery OK, 33698541 rows affected (0.01 sec)

This simply means that the connection was lost and the last order re-submitted.
Then, you try to cancel your incomplete “delete” with a rollback command (your heart beats faster now…) :

  • mysql> rollback;
  • mysql> select * from most_valuable_table;

This select returns 0 rows, cruel !

It isn’t a mistake, the “start transaction” order was lost when MySQL has gone away.
The rollback is no longer possible. Bye bye to your 33.000.000 of rows !

It’s time to go to vacation…