Spec-Zone .ru
спецификации, руководства, описания, API
|
Кэш запроса хранит текст a SELECT
оператор вместе с соответствующим результатом, который был отправлен
клиенту. Если идентичный оператор получается позже, сервер получает следствия кэша запроса вместо того, чтобы
анализировать и выполнить оператор снова. Кэш запроса совместно используется среди сеансов, таким образом, набор
результатов, сгенерированный одним клиентом, может быть отправлен в ответ на тот же самый запрос, выпущенный
другим клиентом.
Кэш запроса может быть полезным в среде, где у Вас есть таблицы, которые не изменяются очень часто и для которого сервер получает много идентичных запросов. Это - типичная ситуация для многих веб-серверов, которые генерируют много динамических страниц, основанных на контенте базы данных.
Кэш запроса не возвращает устаревшие данные. Когда таблицы изменяются, любые соответствующие записи в кэше запроса сбрасываются.
Кэш запроса не работает в среде, где у Вас есть многократные mysqld серверы, обновляющие то же самое MyISAM
таблицы.
Кэш запроса используется для готовых операторов при условиях, описанных в Разделе 8.9.3.1, "Как Кэш Запроса Работает".
С MySQL 5.6.5 кэш запроса не поддерживается для разделенных таблиц, и автоматически отключается для запросов, включающих разделенные таблицы. Кэш запроса не может быть включен для таких запросов. (Ошибка #53775)
Некоторые данные о производительности для кэша запроса следуют. Эти результаты были сгенерированы, выполняя комплект сравнительного теста MySQL на Альфа-системе 2×500 МГц Linux с RAM на 2 Гбайт и кэшем запроса 64 МБ.
Если все запросы, которые Вы выполняете, просты (такие как выбор строки от таблицы с одной строкой), но все еще отличаются так, чтобы запросы не могли кэшироваться, издержки для того, чтобы иметь активный кэш запроса составляют 13 %. Это могло быть расценено как худший вариант развития событий. В действительности запросы имеют тенденцию быть намного более сложными, таким образом, издержки обычно значительно ниже.
Поиски единственной строки в таблице единственной строки на 238 % быстрее с кэшем запроса чем без этого. Это может быть расценено как близко к минимальному ускорению, которое будет ожидаться для запроса, который кэшируется.
Чтобы отключить кэш запроса при запуске сервера, установите query_cache_size
системная переменная к 0. Отключая код кэша запроса, нет никаких
значимых издержек.
Кэш запроса предлагает потенциал для существенного улучшения производительности, но не предполагайте, что это сделает так при всех обстоятельствах. С некоторыми конфигурациями кэша запроса или рабочими нагрузками сервера, Вы могли бы фактически видеть снижение производительности:
Будьте осторожны о калибровке чрезмерно большого кэша запроса, который увеличивает издержки, требуемые поддержать кэш, возможно вне преимущества включения этому. Размеры в десятках мегабайтов обычно выгодны. Размеры в сотнях мегабайтов не могли бы быть.
Рабочая нагрузка сервера имеет существенный эффект на эффективность кэша запроса.
Соединение запроса, состоящее почти полностью из фиксированного набора SELECT
операторы, намного более вероятно, извлекут выгоду из
включения кэшу чем соединение в который частый INSERT
операторы вызывают непрерывное аннулирование результатов в кэше. В некоторых случаях обходное решение
должно использовать SQL_NO_CACHE
опция, чтобы предотвратить следствия даже
вводящий кэш для SELECT
операторы, которые используют часто изменяемые таблицы. (См.
Раздел 8.9.3.2, "Кэш Запроса SELECT
Опции".)
Чтобы проверить, что включение кэшу запроса выгодно, протестируйте работу своего сервера MySQL с кэшем, включенным и отключенным. Затем повторно тестируйте периодически, потому что эффективность кэша запроса может измениться, как рабочая нагрузка сервера изменяется.