Сложные запросы в MySQL: state STATISTICS и optimizer_search_depth

Проблема: громоздкий и очень медленный запрос MySQL, пример вывода монитора innotop:

CXN   When  Load  QPS    Slow QCacheHit KCacheHit BpsIn   BpsOut
local Now   0.00  286.87   0   68.14%    99.20%   279.27k  1.14M
local Total 0.00  259.85   3   71.51%    99.08%   219.76k  1.44M
CXN  Cmd   ID  User   Host        DB     Time     Query
local Query 13 bitrix 192.168.0.1 bitrix 01:01:07 SELECT DISTINCT
local Query 15 bitrix 192.168.0.1 bitrix    12:37 SELECT DISTINCT

Сервер БД (MySQL 5.0.32, Innodb) достаточно загружен: 200-300 запросов в секунду, обмен данными > 1МБ/сек (BpsOut). Запрос ужасающей длительности (более часа!) находится в статусе statistics:

mysql> show full processlist;
| 13 | bitrix | 192.168.0.1:45057 | bitrix | Query | 3612 | statistics | SELECT ...

Использование DISTINCT vs EXISTS vs GROUP BY в подзапросах

Интересное наблюдение за поведением Oracle CBO на примере трёх идентичных (по результату) запросов:

1
select b.comm from bonus b where b.ename in
(select distinct e.ename from emp e where e.mgr >0);
2

select b.comm from bonus b where exists
(select 1 from emp e where e.ename = b.ename and e.mgr >0);
3

select b.comm from bonus b where b.ename in
(select e.ename from emp e where e.mgr >0 group by e.ename);

Блокировки при использовании AUTO_INCREMENT столбцов в MySQL Innodb

Новость о том, что разработчики MySQL серьёзно переработали блокировки этого типа и соответственно продвинули свою СУБД по пути масштабируемости, давно уже новостью не является  (см. InnoDB auto-inc scalability fixed, сентябрь 2007). Однако многие стабильные дистрибутивы Linux, например, Ubuntu 8.04LTS включают в себя пакет MySQL server версии 5.0, для которой проблема блокировок AUTO-INC вполне актуальна. Практический пример типичной проблемы и решения.

LAMP+CMS окружение, активный веб-магазин, десятки тысяч хитов в сутки. MySQL 5.032, обычная нагрузка на сервер ~ 300 запросов в секунду. Проблема возникала при выполнении пакетной загрузки данных о товарах PHP-скриптом: 100-200 тысяч записей, во время выполнения нагрузка на сервер ~ 1000 запросов в секунду, в логе выполнения – ошибка:

Deadlock found when trying to get lock; try restarting transaction

MySQL: блокировки и persistent connection

Поскольку в процессе работы сталкиваюсь, кроме Oracle, с более “свежими” вариантами реализации идеи СУБД, в дальнейшем буду описывать чем-то замечательные и недостаточно (imho) описанные особенности реализации серверов MySQL и MS SQL в части производительности.

Итак, MySQL 5.0.67, Innodb, нагруженный LAMP-проект с высокой OLTP-активностью: веб-сайт активно посещается, контент активно дополняется и редактируется. Периодически начали появляться ошибки типа:

MySQL Query Error: UPDATE some_stat_table SET ...
[Lock wait timeout exceeded; try restarting transaction]

как следствие – блокировка работы всего сайта вплоть до перезапуска MySQL сервера специалистами хостера.

Как открыть БД с повреждёнными (недоступными) log-файлами

Практический опыт восстановления базы данных

Oracle версии 9.2.0.6 в режиме NOARCHIVELOG, ~1.5 ТБ, после серьёзного сбоя файловой системы и “ручного” запуска утилиты fsck.ext2 файлы данных оказались в /lost+found поименоваными номерами inod’ов, controlfile отсутствуют (пропали при восстановлении – 3 штуки :), redolog-файлы, как выяснилось, повреждены.