Вот здесь видно, что именно update самый долгий: https://t.me/ru_mysql/37229 Или это не то и надо именно с processlist попробовать?
вы кеш выключили? всеравно тупит?
Нет пока, а это можно сделать без презагрузки mysql?
Удивительная штука!! Похоже, что даже просто добавление SQL_NO_CACHE в SELECT из этой таблицы, решил вопрос с INSERT 😃🔥 Это ж получается, что просто очистка кэша могла идти до 40 секунд? 🧐 И это время не указывается в show profiles запроса, что сильно ускорило бы поиск проблемы.
На каждое изменение данных в таблице - мускуль признает кеш этой таблицы "устаревшим" (очищает или нет его - не помню) Но почему "висит" не каждый инзерт, а только раз в Х минут/секунд?.... Или все же зависал каждый инзерт? (Просто интересно для себя докопаться) А можете ещё версию сообщить, пожалуйста?
там же было sql_cache.cc
Я не очень понимаю, что значит этот sql_cache.cc Это виртуальный файл, где хранится кеш? В итоге он и сейчас там остался, но запрос идет очень быстро. Я его не отключил в конфиге, поэтому он никуда не делся, как я понял.
это файл исходного кода
Я это объясняю тем, что кэш просто пустой. Раньше если между вставками проходило мало времени они, они были быстрыми. Если много, то за это время успевал накапливаться большой кэш, т.к. чтения этой таблицы очень много у меня и на чистку этого большого кэша уходило много времени. Получается, чем больше накапливался кэш с помощью SELECT, тем дольше он чистился в INSERT. Это также объясняет, почему у меня на локальной машине эта же база работала быстро. Я на ней только INSERT делал, но не накапливал кэш с помощью тысяч SELECT'ов. Вот как я это понял.
Версия сервера: 5.7.29-0ubuntu0.18.04.1-log - (Ubuntu)
в 8ке это безобразие выключено и вырезано
Т.е. там вообще нет кэша запросов в принципе?
Обсуждают сегодня