myhand, я не утверждал такой VPS вообще не обновляется. Обновления связанные с безопасностью можно и нужно ставить. Они как правило, не портят поведение программы. Тем более, что если специально не портить пакетную систему всякими репозитариями, дистрибутивы обновлять достаточно просто даже начинающему.
А конкретно эти баги оптимизатора проявляются при переходе на другую мажорную версию mysql. То есть, когда администратору шило попадет в одно место.
myhand, ну вот пойди и поучи их там в багтрекере единственной правильной точке зрения.
На VPS, в который никто не лазит такие баги не возникнут внезапно.
ну давайте предметнее http://bugs.mysql.com/bug.php?id=42094
http://bugs.mysql.com/bug.php?id=37264
http://bugs.mysql.com/bug.php?id=41109
и эти баги не исправлены.
с апгрейдом практически с любой на любую мажорную версию что-нибудь у кого-нибудь вылезает.
Нигде в документации по mysql не написано , что апгрейд с 5.0 на 5.1 может изменить планы запросов и в худшую сторону. и так что ничего не поможет кроме ручного формирования плана. Многие профпригодные этого не знают. Я предполагаю, даже большинство не знает.
Просто дерьмо случается и я бы хотел быть подальше когда оно случится.
myhand, но я не хочу даже чтобы после предупреждения что-то меняли. Я прекрасно понимаю зачем мне удобные версии софта и все риски связанные с использованием старых версий.
Даже если мне дают 3 месяца на подготовку, зачем мне вообще этот лишний геморрой?
Любое даже самое невинное изменение с точки зрения админа изменение может стать проблемой.
myhand, а мне нравится VPS, потому что софт внутри персонал НЕ ТРОГАЕТ. никакой внезапный апгрейд или что там обычно им в голову приходит на администрируемом лучшими умами современности премиум шареде , ничего не поломает. Если клиент благоразумно не тыкает куда попало, то может случиться, что на VPS у него будет меньше проблем. И клиент точно знает когда и зачем происходят изменения конфигурации - только если он сам нанял разово админа. А на шареде никто клиента не спрашивает.
Прочитали на хабре статью про mariadb, ручки зачесались и поперли устанавливать. Или, например, непрошенный апгрейд с php5.2 до php5.3.
Сложно выбрать лучшее и всем однозначно советовать, короче.
Andreyka, но ведь есть еще журнал innodb и его нельзя поместить в чистый раздел без файловой системы. Он очень важен для восстановления после перезагрузок и сбоев.
Есть где облажаться оптимизировать.
LEOnidUKG, нет так не лучше - все равно не видно как именно созданы индексы. обычно используют оператор show create table XXX; потом show index from XXX. Планы EXPLAIN, реальное количество затронутых строк в разнице SHOW STATUS и вообще еще кучу инструментов.
Если не хотите вслепую мыкаться, то надо все это изучить. И администратору так и передайте.
Но вообще, все так вслепую работают. SQL ведь и был создан для работы вслепую чтобы избавить программиста от императивного мышления. Ничего это знать не нужно, пока оно не начнет тормозить.
LEOnidUKG, смысла смотреть конфиг без всех остальных данных о сервере нет. Всех остальных, которых ты все равно не знаешь как показать. И данные о сортировках противоречивые приводишь.
Пиши уже и как-нибудь опытным путем найдешь что быстрее.
Andreyka, какая может быть личность у бота? нет смысла что-то доказывать и аргументировать - он на это не запрограммирован.
но все-таки передайте вашему создателю следующую мысль:
Несмотря на многократное резервирование всего и вся в банках (которое все равно им не помогает), в субд и файловых системах существуют механизмы позволяющие избежать последствий внезапных падений и перезагрузок. Потому что никакого волшебного администратора, который настроит и зарезервирует железо чтобы вообще не падало, нет даже в банках.
И уж точно ТС не стоит считать любую даже очень продуманную первоначальную настройку VPS полностью исключающей проблемы. Когда-нибудь обязательно понадобится администратор.
