Когда использовать SQL_NO_CACHE

Я просматриваю свои запросы, и я читал статьи о том, как вы должны использовать SQL_NO_CACHE в запросах SELECT. Это меня смутило, потому что в каждой статье в конце есть другой вывод о том, когда использовать это. Один блог, который я прочитал, сказал, что вы должны использовать его, если у вас одинаковые запросы и уникальны. В другом блоге я читал, что вы должны использовать его, когда вам нужно извлечь информацию, которая никогда не изменится.

Может кто-нибудь объяснить, когда это хорошая практика, чтобы использовать это? Я знаю, что это было задано раньше, но чтение многих статей не помогло, особенно когда люди говорят, что используют этот метод в разных ситуациях. Я сделал некоторые теоретические ситуации, может кто-нибудь сказать мне, полезно ли использовать SQL_NO_CACHE. Спасибо, и я извиняюсь за повторный вопрос. Я просто очень смущен.

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

  2. Вы выбираете userID во время проверки входа, запрос выполняется только во время проверки регистрации.

  3. Вы выбираете некоторые данные из таблицы a для обновления поля в таблице b, следует ли использовать SQL_NO_CACHE для выбора таблицы a?

Спасибо.

Ответы

Ответ 1

SQL_NO_CACHE

Просто добавьте SQL_NO_CACHE после части SELECT оператора SELECT и перед списком полей. Первый запрос ниже будет использовать кеш запроса, если он включен, и запрос кэшируется:

SELECT * FROM table WHERE search= 'keyword'; //lets take 1ms

Второй запрос ниже не будет использовать кеш запросов:

SELECT SQL_NO_CACHE * FROM table WHERE search= 'keyword'; //lets take ~0.2ms at 2nd time

Это особенно полезно при анализе запроса; если кеш запросов включен, хотя первый запрос может занять некоторое время, второй и последующие запросы почти мгновенно. С помощью SQL_NO_CACHE вы можете быть уверены, что кеш запросов не используется и может безопасно сравнивать время выполнения. Совет SQL_NO_CACHE отключает встроенный механизм кэширования запросов MySQL для конкретного запроса. Вы можете помочь MySQL сделать кеш запросов более эффективным, используя этот намек на очень динамичные запросы (например, поиск по ключевым словам или отчет, который работает только по ночам). Убедитесь, что кеширование запросов включено, иначе нет необходимости в этой команде.

какие SQL_CACHE и SQL_NO_CACHE?

Параметры SQL_CACHE и SQL_NO_CACHE влияют на кеширование результатов запроса в кеше запросов. SQL_CACHE сообщает MySQL хранить результат в кеше запроса, если он кэшируемый, а значение системной переменной query_cache_type равно 2 или DEMAND. С SQL_NO_CACHE сервер не использует кеш запросов. Он не проверяет кеш запросов, чтобы убедиться, что он уже кэширован, и не кэширует результат запроса. (Из-за ограничения в синтаксическом анализаторе пробел должен предшествовать ключевому слову SQL_NO_CACHE и следовать ему, а непространство, такое как новая строка, заставляет сервер проверять кеш запросов, чтобы узнать, уже ли кэширован результат.)

NO_CACHE в соответствии с моим мнением может быть использован, если "CACHE" включен, а данные в db динамически обновляются, т.е. Кэш данных db нельзя использовать, например: сохранение хэша пароля пользователя, который мы не можем полагаться на CACHE, поскольку существует частая возможность изменения данных

Обновления полезных сценариев

1) заставить не использовать кеш для проверки скорости запроса

Ответ 2

Чтобы ответить на ваш вопрос, вам сначала нужно понять, как работает кеш запросов MySQL. Очень хорошая статья об этом можно найти здесь. Ключевыми аспектами являются то, что кеш синхронизируется с данными:

Кэш запросов не возвращает устаревшие данные. Когда таблицы изменяются, все соответствующие записи в кеше запросов очищаются.

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

Ответ 3

Самое очевидное время, которое я бы выбрал для подавления кэширования, - это когда я не хочу, чтобы результат запроса в кеше (очевидно?).

Если я буду запускать запрос только один раз, тогда нет смысла перемещать данные, находящиеся в кеше, чтобы освободить место для данных, которые никогда не будут удалены из кеша.

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

Третий сценарий - это когда есть много простых запросов на выбор одной таблицы, возвращающих очень маленькие массивы данных (например, с использованием тривиального ORM). В этом случае использование кэширования запросов, скорее всего, будет медленнее, чем обход его вообще - СУБД будет тратить больше времени на управление кешем запросов, чем на чтение данных из пула буферов/системного кеша.

Как говорит Тот, кеш искажает любые профилирования/бенчмаркинга, но кеш запросов не является единственным местом, где данные буферируются/кэшируются.

Вы выбираете некоторые данные из таблицы a для обновления поля в таблице b, следует ли использовать SQL_NO_CACHE для выбора таблицы a?

Нет. Кэш автоматически недействителен, когда базовые данные изменяются (из чего исходит большая часть стоимости простых запросов).

Ответ 4

Единственный раз, когда я использовал его, - это профилирование запросов (EXPLAIN extended...).

При выполнении запроса несколько раз (очень важный шаг для "разогрева" сервера), он будет кэшироваться, поэтому профилировщик выдаст неверные результаты.

В зависимости от ситуации я также использую:

SET SESSION query_cache_type = OFF