mysql_query

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

Т.е. взять $x = mysq_qury(бла бла бла) и засунуть этот $x куда-либо в кэш, например в переменную типа varchar.

Можно так сделать в теории? Или я фантазер?

Сериализуем результат и пишем в файл.
(Добавление)
Я имею в виду результат выполнения функций mysql_fetch_assoc и т.д.

а можно ли тоже самое проделать с ресурсом который отправляется на съедение функции mysql_fetch_assoc?

(Отредактировано автором: 16 Июля, 2012 - 16:13:12)

alxfro имхо в этом мало смысла
мускул очень хорошо сам кэширует запросы
и основные потери идут на перегон результатов(рядов)
их и имеет смысл кэшировать на стороне пхп
и быстрее будет если получится пользовать memcached
http://php.net/manual/ru/book.memcache.php

Не стал предлогать в силу того, что далеко ни все хостинги предоставляют это удовольствие.

alxfro, то что собираетесь кешировать не содержит результата, это всего лишь указатель который при следующей сессии уже будет не валидным.

Дело вот в чем.

Я для доступа к базе использую класс sql. Там у мну есть функция, открывающая соединение (постоянное, одно) и соответственно другие функции выборки/вставки и так далее.

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

Сейчас гляну в сторону memcashed....... или как его там.


Глянул.
Цитата:


т.е. не получится кэшировать

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

- а это вообще иная функциональность, и она предоставляется самой СУБД. Если запрос возможно закешировать, то СУБД в следующий после кеширования раз не будет исполнять его полностью внось, а выдаст вместо этого результат из кеша.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Вернее сказать - это удивительная штука MySQL. Другие СУБД кэшируют план запроса (как самую компактную, но энергоёмкую часть) и оперируемые данные, а не результат каждого запроса.


Вытаскиваете весь результат в массив (или иную структуру, которая может сериализоваться) - и пишете в кэш.

-----
PostgreSQL DBA

Мелкий
А, ну верно, но, поскольку речь идет о mysql_query, я опустил эти подробности.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

с этим проблем нет

ну вот я делаю select * from x where 1 и мне никакой кэш не отдает. выдает на живую.

Приведите пож-ста пример по вашим словам выше, в каком случае используется кэш?

А Вы прямо так и не узнаете. Смотрите время выполнения скрипта. Если запрос в КЭШЕ то время будет на порядок меньше. Но надо учитывать, что объем КЭШ-а не безграничен.