Продолжаю возится с MySQL и получаю удовольствие от хорошо продуманного концепта для своих задач.

Возник вопрос о технике кеширования запрос в части query plan и кеша данных.

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

Вопрос по кешированию InnoDB, опять же сравниваю с MS SQL. Для снятия нагрузки SQL-сервер как правило предоставляет сервисы кеширования планов выполнения и данных.

В MS SQL такое кеширование параметрическое . В смысле что даже для SP или даже динамического SQL вы может закешировать запрос если он нестатический только на переменные-аргументы.

Внимание вопрос. Умеет ли MySQL в InnoDB делает параметрическое кеширование для запросов в хранимых процедурах следующего типа?

select .... from .... where ID=MyVar, где MyVar - переменная в хранимке

Или нет никакой разницы с вызовом просто динамического SQL?

ScareCrowобщего кеща планов в MYQSL нет.
что то есть но только для соединения, и умирает вместе с ним.

Это не очень страшно. Можно для сервера сделать warn up алгоритм, который прогревает кеши. Так в и MS SQL обпытными разработчиками делается к слову. Хотя вроде кеши есть, но их правильная конфигурация зависит от "обучения кеша". Поэтому опытные разрабы и админы имеют наборы скриптов для "прогрева". Обычно правда их запускают после перезагрузки сервера, чтобы у пользователей несколько часов не комотозила база.

Вопрос в другой. Там сами-то MySQL что кеширует?
- Планы?
- Данные?

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

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

В принципе все современные App Servers имеют свои дополнительные механизмы кеширования. Правда интенсивное применение их обычно приводит к понятию "очереди" и обработки большинства запросов по одному без параллелизма вообще. Тут и обходы дедлоков заложены. Но резко падает производительность такой архитектуры, например MS Project Server в такой коме именно потому что так и сделан.

Поэтому пока я избегаю таких подходов.

Кеш в MS SQL это куски таблиц, а не запросы. Иногда куски рабочих таблиц если используется "карусель" из MS SQL Enterprise.

Но надо понимать, что сейчас велика нагрузка на App Server в логике. Поэтому различие SQL-серверов в известной степени стираются.

Можно закешировать и результаты запросов. Например считать типовые таблицы-справочники. А на клиент грузить плоскую основную таблицу раскрывая ключи не через join, а через одиночные запросы. Я как-то и для MS SQL такой фокус делал.

Повышает производительность умеренно, но сильно уменьшает дедлоки как раз.

В принципе как сделан MyISAM ему сильно кеши-то и не нужны. Он как раз быстр, потому что нет типовых SQL-заморочек вокруг него.