>>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо.
> Несколько примеров:
> - Использование LIMIT x,y (нет в MSSQL, к примеру) вообще limit offset поддерживается в том числе и в MySQL и в PostgreSQL и Oracle
> - Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в
> ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется
> с подзапросами)
explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в MySQL работают быстрее подзапросов.
> - Для TokuDB - создание всех необходимых индексов, без оглядки на скорость
> модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс
> даже при обилии модификаций
Это вообще специфика движка и к приложению никакого отношения не имеет.
> - Правильное партиционирование таблиц
Это тоже не имеет никакого отношения к приложению
> - Приведение типов столбцов в связках (в MySQL с этим очень строго)
Это уже вопросы к разработчикам.
> - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора
Это тоже не имеет никакого отношения к приложению.
> Пример специфики - например, избавление от full scan / больших range scan
> по мере возможности. В принципе актуально для любого движка. Партиционирование и
> использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборки
Это точно так же делается на PosgtreSQL различия минимальны.
> и анализа в код (хранимки / клиент), максимизация использования индексов. Использование
> движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree
> отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц
> для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем
> сканирования). Построение покрывающих индексов. И так далее.
Это может делятся уже и после того как приложение запущено и это вот как раз при разработке вообще можно не учитывать.
> Предложите лучше для _большой_ сети (>2500 хостов).
К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно не мешает ему иметь ужасный код в основе ;)
> И чем это поможет? Только давайте конкретно, без воды: где именно в
> заббиксе производительности поможет транзакционность?
Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL.
У нас чинилось переходом на PostgreSQL, где с записью все лучше.
> Не встретил даже на InnoDB. А на TokuDB это вообще не проблема.
TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как работа housekeeper приводила к стоянию колом MySQL сервера. Да и в целом нагрузка на сервер была больше.
> Вот не поверишь - ни разу не встал колом на записи,
> зато на чтении постоянно вставал колом в огромных range read.
Вот увы не поверю. Основная проблема это запись. Которая затем выливается в проблемы при чтении.
> Пока не переписал ряд запросов. Основная проблема там - это массированные range
> scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000
> триггеров, причем встает раком...
Основная проблема криворукость писателей zabbix которые часто даже в explain не удосуживаются посмотреть.
