Задать вопрос
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Akina,
    В MySQL это Controlling the Query Optimizer. Ну и у Машки что-то похожее - искать лень.


    Спасибо! Поизучаю.

    Вообще-то зря. Они развелись настолько давно, что их следует воспринимать как принципиально разные, хотя и высокосовместимые, СУБД.


    Лучше "перебздеть", чем "недобздеть"...:)

    Vitsliputsli,
    А зачем спешить переходить? Переходите тогда, когда результаты тестирования новой версии вас устроят. Сейчас похоже рано (хотя я не верю в оптимизатор, который никогда не ошибается).
    Например, некоторые до сих пор используют mysql 5.7, и не только потому что все подводные камни известны, просто 8ка показывает себя хуже при тестировании. И несмотря на проблемы 5.7, стабильность важнее.


    Ну согласен, в принципе. Просто само приложение позволяет работать на последней версии(хотя её функции и не использует) + сопутствующее ПО с этим приложением будет дальше обновляться + само приложение...

    Есть у меня привычка к тому же: брать последнюю стабильную версию ПО, если это позволяет...особенно при крупном изменении инфраструктуры как бы "заодно"...потом допиливать "мелкие" погрешности и ехать далее...

    Если бы это был проект, который постоянно не допиливается - то ехал он бы хоть на 4 версии и бог с ним...)

    Ипатьев,
    Я бы не рассматривал эту проблему как некий баг 11 версии.
    А считаю, что это такой стандартный взбрык оптимизатора. Просто вот он вылез именно на этом запросе после апгрейда. Так совпало.


    Ну и я, как бы, не расстроен сильно...но охота понять тогда: как строить теперь такие структуры...если оптимизатор так быстро "переобулся" получается...))
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Если так подумать...то теперь даже в "ходовых" запросах надёжнее самому решать какие индексы лучше "юзать" БД? Гемор же?
    Ну с другой стороны - качественнее...типа...
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Ипатьев,

    Я думаю, имеет смысл написать куда-нибудь в группу поддержки MariaDB. Приложив результаты show index from table для всех таблиц.


    Могу попробовать сделать дамп обезличенных данных и даже выделить VM для тестов...но думаю вряд ли это поможет :)
    Мне кажется они то в курсе...только нам ещё не довели: как дальше проектировать лучше...))
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Akina,
    Обновить и актуализировать статистику, чтобы не ждать пока оно само наберётся, можно запросом ANALYZE TABLE.


    Я так делал пока искал решение с USE INDEX...+ до этого сервак дня 3 работал...

    Влиять на план выполнения отдельного запроса вы можете тюнингом - либо хинтами запроса (как вы использовали USE INDEX, ещё можете попробовать STRAIGHT_JOIN), либо хинтами оптимизатора. Либо вы можете настроить работу оптимизатора глобально, тюнингом используемого "комплекта" стоимостей.


    Можно подробнее: где почитать про "глобально" ? Ещё бы в сравнении с 10'кой...типа какие глобальные настройки у них отличаются...и где они "подкручиваются" тогда в таком случае?

    Если в вашем случае "куча" - это более десятка, то рассмотрите вариант с сохранением этого списка во временной индексированной таблице и использованием INNER JOIN либо WHERE EXISTS вместо WHERE IN.


    Там условие с IN даже убрать можно...всё равно индекс "другой" подставляет при JOIN без USE...

    Ипатьев,
    Сам недавно столкнулся с точно таким же поведением. Мария (впрочем, когда работал с Му, то же самое случалось) точно так же перекособочила порядок таблиц в запросе и получила какое-то дикое время выполнения. Заставил использовать мой порядок джойнов через STRAIGHT_JOIN, и всё залетало. Но вот как это лечить на системном уровне - и сам не знаю. Принимаю такие закидоны как данность и лечу вот хинтами.

    Причём у меня БД не менялась, это новый запрос на старых данных.


    Вот и у меня вопрос именно в этом...типа с фига ли такие оптимизации считаются лучшими(по мнению инженеров 11 версии) ?
    Если набор данных прям один из самых "ходовых"...тобишь есть большая таблица с данными и к ней прилеплено пару справочников через JOIN...

    Хм. Кстати, а что за настройки-то?
    Ну и традиционно - в первую очередь размер innodb_buffer_pool_size?
    Может быть, 11-ке тупо требуется больше памяти, индекс не влезает в оперативку и она срывается в построчное чтение? Может, я конечно глупость говорю, но лишний раз проверить буфер innodb всё равно не помешает.


    Две VM есть...по 32ГБ оперативки...innodb_buffer_pool_size под 70% от RAM.
    Делал даже так...тупо у VM с 10 версией рубил до 8ГБ оперативку и она всё равно выбирала правильный индекс!
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Akina,
    Rsa97,
    Vitaly Karasik,
    ThunderCat,
    Sanes,
    Melkij,
    d'Ivan,

    Ребята, я в курсе, что Вы "что-то" знаете...дайте направление...в этом несправидливом мире :)
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    UPD3:
    Переезжая с 10 на 11 версию я был уверен, что всё будет "чики-пуки" - ибо начиная даже с 5 версии в этом проекте запросы без "финтов" - тобишь стандарнтые - как в примере выше...
    Отсюда и удивление...вот в чём вопрос...
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Vitsliputsli,

    оптимизатору чтобы построить хороший план, нужно понимать какие данные и в какой пропорции лежат в таблицах. Тупой пример, вы залили в таблицу много данных, а оптимизатор думает что она маленькая и вместо использования индекса пойдет фул-сканом. Разумеется это не так глупо работает, но при больших и быстрых изменениях лучше все таки вручную попросить собрать статистику, на всякий случай.

    Ну, в моём случае, получается, что даже "в наглую" переехав на 11 версию...и прожив несколько дней - сам движок MariaDB не смог собрать стату и даже на третий день выбрать другой индекс? Или что Вы имеете ввиду?
    Я конечно нашёл инфу, что разные версии MySQL/MariaDB бывает работают по-разному, в том числе и с индексами...НО, блин, в таких "ходовых" ситуациях координально "бросаться" произодительностью....мне кажется: либо - я - "дурак" - либо должно быть объяснение более внятное :)

    Указать какой индекс использовать - нормально. Но, нужно быть очень аккуратным, если вы знаете что распределение данных не изменится, то хорошо. Чаще всего, в работающем проекте распределение данных более менее постоянно, и указание конкретных индексов надежнее.


    Тут согласен. НО, раз уж версия у меня более новая - то хочется понимать её "оптимизации", чтобы постоянно не указывать индексы в запросах...это же вроде не "излишнее" требование, а вполне адекватное. Верно же?

    И еще, USE - это рекомендация, оптимизатор может на нее забить, прям чтоб гарантировано нужен FORCE.


    Да, верно. Я начал с USE...ибо понять "откуда" мне начинает "верить" движок БД...

    UPD:

    Либо я что-то проектирую неправильно - относительно инженеров MariaDB...помогите)

    UPD2:

    Как дальше с этим жить и лопатить проекты с JOIN'ами(это грубо говоря) при переносе?
    Гуглил уже обо всём между 10 vs 11...там всякая чепуха - но не об этом...
    Написано
  • MySQL/MariaDB. 10 vs 11 version. Индексы. Странное поведение?

    Fernus
    @Fernus Автор вопроса
    Vitsliputsli, Именно так...просто: почему?

    Стату некогда было собирать...исправил подобные запросы методом, что привёл выше...но нормально ли это?
    Написано
  • Как удобно тестировать корректную обработку состояния гонки в laravel?

    Fernus
    @Fernus
    Но бывают случаи, когда пользователь может быть удален и создан заново, например при регистрации по номеру телефона - когда пользователь долго не пользуется номером и потом номер передается другому человеку. Тогда признак уникальности надо снять и добавить SoftDeletes.


    Может лучше сделать составной уникальный индекс номер + deleted_at тогда в таком случае ?
    Написано
  • Как установить линукс на ноутбук с флешки?

    Fernus
    @Fernus
    Ventoy раз запариться и поставить на флешку...и потом тупо как в папку закидывать любые образы...

    До этого я так же под каждую ОС флешку стряпал...потом надоело...запилил всё на одну и втыкаю когда-чё-надо...

    У меня с неё даже win 11 взлетал нормально...там правда пару дровишек на флешку лучше сразу закинуть...но не суть...
    Написано
  • Какую кодировку выбрать для немецкого языка?

    Fernus
    @Fernus
    Ипатьев, ну я прям в документацию же ссылку дал...там и кодировка видно какая нужна...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    tukreb, Ну у каждого свой опыт))
    Я тоже самое прошёл только с 2005 примерно...под каждые задачи - своё решение...

    P.S.:
    Лучший код - процедурный под задачу...но, кому - "оно" - надо... :)
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    tukreb, Половина Laravel построена на Симфони...тут как рассматривать решения...есть и у Симвофни просто "изделия" - а не "решения"... :)
    Написано
  • Как создать авторизацию для подключения к websocket серверу reverb (не к каналам, именно серверу)?

    Fernus
    @Fernus
    Alex Alc,

    Уж очень много нашёл недостатков и, если верить issues в офф репозитории, даже есть некоторые актуальные уязвимости.

    Можны ссылки на уязвимости именно? Что-то не нашёл "тех" - которые можно "прикрыть"...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    mrFlyer,

    Подстроился ... раньше increment не кидал событие updated, а в 10ке вот стал.

    Вот "по-человечески" 10-ка получается ведёт себя логичнее...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    mrFlyer,
    Из документации:

    Метод wasChanged определяет, были ли изменены какие-либо атрибуты при последнем сохранении модели в текущем цикле запроса.


    Тобишь в Вашем примере кода - "цикл запроса" заканчивается на increment, но по факту full_name(из Ваших слов не меняется в БД).

    Тут, как подумать:

    - Либо "циклом" считается экземпляр модели(book);
    - Либо "само сохранение по факту" (save) - чего по факту не сделано.

    Отсюда и непонимание...+ при increment логично, что срабатывает событие update...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    mrFlyer, А, ну тут...уже подстраивайся под "цепочку" событий логики приложения...
    Это нормально. Просто продумай "цепочку действий" в зависимости от событий и "хотелок"...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    mrFlyer, Я не просматривал методы глубоко внутри Laravel в данном случае...
    Тогда подождём ещё кого-нибудь...но поведение тогда нелогично выглядит...хотя с другой стороны - есть другие причины: "почему" не сохранилось full_name по факту...

    Наверняка в bug report по Laravel это где-то уже рассмотрено...
    Написано
  • Почему при вызове метода increment модели wasChanged принимает значение true у других аттрибутов?

    Fernus
    @Fernus
    Возможно, потому что, ты взял экземпляр "book" и сначала присовил ему full_name, затем сделал increment и тем самым "сохранив" этот экземпляр "book", и, далее, "ожидаешь/проверяешь" на changed этот же экземпляр...не?

    UPD:

    Почему тут true? Ведь full_name в базе не обновился ...

    По факту реально так? В базе действительно не обновился full_name?
    Тогда странное поведение ORM...хотя тут как подумать...
    Написано