FanatPHP

Сферический вопрос в вакууме, причём без возможности уточнения, поскольку «проект был».
«медленные запросы» — насколько медленные?
«сайт с посещаемостью» — с какой посещаемостью?
«потому что запросы на поиск» — так может, это поиск вынести отдельно на Сфинкс?

То есть, выяснить, что там — кривая настройка сервера mysql, кивые таблицы или кривые запросы — не представляется возможным.
Но вопрос, как всегда, формируется в самом общем виде — «где тот волшебный гвоздь, по которому 1 раз ударить — и всё сразу залетает?»

Ну ок. В самом общем виде оптимизация запросов (неважно — частых или нечастых) заключается в оптимизации запросов.
Оптимизированный запрос выполняется (допустим) 0.001 секунды. То есть, БД может обслужить 60 тысяч одновременно сидящих пользователей.

Берем EXPLAIN и смотрим. Если он говорит, что с запросом все окей, просматриваем ровно столько записей, сколько нужно — 5-10, но все равно запрос исполняется медленно (насколько конкретно медленно — в секундах?) то смотрим, SHOW ENGINE [engine] STATUS. Там уже надо опять же смотреть по месту, решать, чего серверу не хватает.

После того, как мы убедились, что все меры по оптимизации SQL приняты, то только тогда занимаемся кэшированием, заменой полл на пуш и т.д.

То есть, действуем как программист — а именно, разбираемся с конкретной проблемой, и ищем решение конкретно для неё.
А не придумываем от балды заплатку для лечения симптома, оставляя болезнь развиваться и дальше.

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

По-моему, там довольно ясно написано.
Если планируем использовать или писать DBAL для работы с Mysql — то mysqli.
Если от привычки обращаться напрямую к функциям API избавиться никак не получается — то только PDO, поскольку эта библиотека частично реализует функции DBAL, а большая часть тонкостей, реализованных в mysqli, разработчику никогда в жизни не понадобится.

Вам не нужно никакое кэширование.
Вам нужно оптимизировать свои запросы.
«100 договоров и больше» — смешная цифра. По такому количеству любые выборки должны считаться предельно быстро, в сотые доли секунд.
Даже если тупо выбирать все сто договоров в скрипт и считать руками.

Кэширование должно применяться только после того, как оптимизированы запросы.
А сейчас вы пытаетесь поставить турбонаддув на машину, не сняв её с ручника.

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

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