mysql bug: EXISTS + GROUP BY

Простой запрос в приложении клиента может давать ошибочный результат

mysql> SELECT s2.NAME
,COUNT(DISTINCT s2.CONTENT_ID) as CNT
,MAX(s1.DATE)
FROM s2 INNER JOIN s1 ON (s2.CONTENT_ID=s1.ID)
WHERE EXISTS (SELECT 1 FROM content_group sg
WHERE s1.ID = sg.CONTENT_ID AND sg.GROUP_ID IN (2))
GROUP BY s2.NAME;
Empty set (0.01 sec)

Интересно, что если исключить из запроса или GROUP BY, или EXISTS – результат становится правильным – ожидаемо непустым

MySQL: использование временных таблиц на диске для таблиц с TEXT/BLOB столбцами

В документации MySQL указаны случаи, когда temporary tables не могут быть перенесены в память (Memory (HEAP) Storage Engine) и MySQL использует для временных таблиц MyISAM, первый из которых:

• Присутствие TEXT или BLOB столбца в таблице

Не совсем понятно, где должен присутствовать LOB столбец- в списке SELECT, условиях WHERE, конструкциях ORDER BY, GROUP BY?

Интересно, в каких случаях MySQL будет создавать для временных данных таблицы на диске, что фиксируется статистикой Created_tmp_disk_tables для запросов к таблицам с TEXT или BLOB столбцами.

Сложные запросы в 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 ...

Блокировки при использовании 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 сервера специалистами хостера.