В последние пол года у меня создается двойственное впечатление от использования MySQL. Не хочется давать оценку работе проведённой Oracle, как управляющей компанией, но очень хочется высказаться по поводу того, что уже 5 релизов не могу дождаться стабильной версии MySQL, которая позволит нормально работать.

5.5.19
Вышел долгожданный релиз в котором пофиксили багу bugs.mysql.com/bug.php?id=56299, благодаря которой каждое переключение логов на нашей БД приходилось мониторить, в виду возможного зависания прода из-за репликации bugs.mysql.com/bug.php?id=61186.
Пока тестировали релиз поняли, что при использовании партиций MySQL безбожно течет. Разработчики утверждают, что это не он течет, а память фрагментируется blogs.innodb.com/wp/2011/12/improving-innodb-memory-usage-continued
image
А! т.е. если у меня операционка не может использовать память, которой попользовался MySQL, это конечно не мускуль виновать а ОС.
5.5.21
Дождался фикса бага bugs.mysql.com/bug.php?id=57480. Бэкпортом с 5.6.5 пришел фикс, благодаря которому MySQL не надо перегружать каждый месяц, ввиду заполнения swap. Но тут возник новый сюрприз! Который конечно старый, но для PCI DSS асессеров является красной тряпкой, ибо в БД можно попасть без пароля: seclists.org/oss-sec/2012/q2/493. Проблема была хорошо освещена на хабре habrahabr.ru/post/145641. Все версии до 5.5.22 уязвимы. Сами мы не быстрые, тестируемся, качаем исходники патчим.
5.5.25
Пока патчим и тестим выходит 5.5.25. Ну вроде фиксов там много, решили её ставить. Месяц назад запустили процесс тестирования данной версии. Пишу тикет, тут бах сюрприз! Исходники этой версии пропали с сайта. Патч есть, собрать не можем, ибо качать исходники неоткуда. Причина тривиальна bugs.mysql.com/bug.php?id=65745. Update первичного ключа (не знаю кому в голову пришло update'тить первичный ключ) вызывает рекурсивное изменение данных, что приводит к заполнению всего места на HDD.
5.5.25a
Ура вышла новая версия. Уж там то все должно работать. Проверяем работу: внезапно один из разработчиков говрит, что у него MySQL падает на любом запросе. Проверяем. И правда, если из партиционированной таблицы запросить данные за несуществующий период, то MySQL падает с ошибкой 
12:06:58 UTC - mysqld got signal 8 ;
This could be because you hit a bug.
...
Thread pointer: 0x4169f30
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ff9fa384e58 thread_stack 0x30000
/opt/mysql-5.5.25a/bin/mysqld(my_print_stacktrace+0x29)[0x75feb9]
...
/opt/mysql-5.5.25a/bin/mysqld(pfs_spawn_thread+0x54)[0x879cf4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7efc)[0x7ffa669e8efc]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ffa65d5b59d]

Проверяем — уязвимы все версии до 5.5.22, но в 5.5.22 можно зайти без пароля. Что делать не знаю. Сидим чешем репу. У меня к примеру после запуска этого скрипта (который мы методом тыка писали целый день) перегружается Ubuntu.
use test_mysql_crash;
drop table if exists test_table;

create table test_table (
  agad_id int(10) unsigned not null auto_increment,
  partition_key int(8) not null default '0',
  caaf_caaf_id int(10) unsigned default null,
  primary key (agad_id,partition_key),
  key idx_1 (partition_key),
  key idx_2 (caaf_caaf_id)
) engine=innodb
partition by range (partition_key)
(partition test_table_20120717 values less than (20120718) engine = innodb,
 partition test_table_20120718 values less than (20120719) engine = innodb,
 partition test_table_20120719 values less than (20120720) engine = innodb,
 partition test_table_20120720 values less than (20120721) engine = innodb,
 partition test_table_20120721 values less than (20120722) engine = innodb);

drop procedure if exists ui_test_mysql_crash;
delimiter $$
create procedure ui_test_mysql_crash()
 main_sql:
  begin
    declare v_sql_core                     text;
    set v_sql_core              =
          concat(
            '                  explain select caaf_caaf_id, ',
            '                         partition_key ',
            '                    from test_table ',
            '                   where partition_key between ? and ? ',
            '                  group by caaf_caaf_id, partition_key'
          );
    set @sv_ddl_statement        = v_sql_core;
    set @sv_partition_key_from   = 20120801;
    set @sv_partition_key_to     = 20120831;

    prepare v_stmt from @sv_ddl_statement;
    execute v_stmt using @sv_partition_key_from, @sv_partition_key_to;

    deallocate prepare v_stmt;
  end
$$
delimiter ;
call ui_test_mysql_crash;

Ну что ж комментим баг bugs.mysql.com/bug.php?id=65587 и ждем…

P.S. конечно все события не хронологичны, просто хотелось описать, что во всех последних версиях что-то не так…

Update: shagguboy верно отметил — в одном баге написано, что в 5.5.26 последний баг уже исправлен, за что ему спасибо, а я да — опять жду следующую версию (ИМХО крайне символично)