> вообще limit offset поддерживается в том числе и в MySQL и в
> PostgreSQL и Oracle В MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL, и в PGSQL, и в Oracle.
> explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в
> MySQL работают быстрее подзапросов.
Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые.
> Это вообще специфика движка и к приложению никакого отношения не имеет.
Мы же о специфике и говорили? Ее надо учитывать, если хочется получить результат выше среднего в сложных условиях и по пересеченной местности. Если средний или около того - то сойдёт что угодно.
>> - Правильное партиционирование таблиц
> Это тоже не имеет никакого отношения к приложению
Имеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне быть написаны с учётом оного.
>> - Приведение типов столбцов в связках (в MySQL с этим очень строго)
> Это уже вопросы к разработчикам.
Именно. В MSSQL не так строго. Но это - специфика.
>> - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора
> Это тоже не имеет никакого отношения к приложению.
Имеет, причём 100%.
> Это может делятся уже и после того как приложение запущено и это
> вот как раз при разработке вообще можно не учитывать.
Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со стабильностью, увы.
>> Предложите лучше для _большой_ сети (>2500 хостов).
> К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно
> не мешает ему иметь ужасный код в основе ;)
Если он по фичам лучше всего - то это не "хреновое решение"? Да, оно может и ужасно по коду, но при этом оно минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже, в общем, не блещут - ресурсов им надо немеряно.
> Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL.
Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да и в InnoDB их нет, если не злоупотреблять столбцами и индексами, и сознательно строить базу с максимальным обходом блокировок.
> У нас чинилось переходом на PostgreSQL, где с записью все лучше.
У нас все проще - после переписывания нескольких запросов всё встало на места с чтением. А с записью проблем не было и нет.
Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать не буду.
> TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как
> работа housekeeper приводила к стоянию колом MySQL сервера.
Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки обрабатывают по 1 элементу за 1 раз, хотя можно было оптом обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились, может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел - но его вообще в статистике не видно.
> Вот увы не поверю. Основная проблема это запись.
У нас ситуация иная. Колом вставало именно чтение, причем записи в этот момент не было. Несколько переписанных запросов - и больше колом не встает ничего.
