В поисках программиста PHP

У вас PHP скрипту из MySQL передается набор данных в 13 миллионов строк?

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

select SQL_CALC_FOUND_ROWS * from limit

Вот здесь это описано подробно

http://wbtools.ru/?forum=53

zexis, абсолютно с вами согласен!

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

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

Самое страшное для программиста это оптимизация чужого кошмарного кода.

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

pupseg, я знаю, что Вам дискомфортно уходить от топика, потому что вернуться в него намного тяжелее. Но все же я хочу подтвердить слова Lopas о том, что все это намного меньшей кровью делается руками сисадмина. А именно: настройкой кэша MySQL. Потому что 13 миллионов строк - это нет ничего для современного сайта. На шареде таких сотни крутятся. Коль уж мы в теме про администрирование, покажите конфиг MySQL и объем памяти на сервере.

А я "слыхал", что многие толковые граждане сулят расстрел на месте с лишением всех прав за mysqlизмы.

Не так страшен черт, как его малюют, у меня была в чем-то похожая ситуация. Вы хоть приблизительно представляете: конкретно для вас как долго и как дорого? Уверены что клиент этого не оплатит? 🍿

Есть такие вещи, как объем базы, конкретной выборки (13+ млн), etc. Кучу вещей вы упустили, на самом деле.

myhand, напишите яснее.

Вы хотите сказать что использование cспецифических возможностей mysql таких как SQL_CALC_FOUND_ROWS и limit не правильно?

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

Этого лучше избегать. Покуда вы не можете себе обещать со 100% уверенностью, что хотите завязать себя на mysql навеки.

Дело даже не в выигрыше. "Тюнинг" в данном случае выглядит, скорее, "костылем". Не исключаю, что им можно замазать проблему на время, но надо-ли?

SQL_CALC_FOUND_ROWS не всегда даёт ощутимый выигрыш, а чаще наоборот (см комментарии к статье по ссылке).

pupseg, что за движок-то (можно в личку, если инфа "неДляВсех"). И судя по

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

Оно вообще (для СУБД) так называется.. и делается обычно на уровне администрирования БД

p.s. Переписать движок на 5.4, попутно оптимизируя (в уме держим аптайм) - задача кхм-кхм.. специфичная.

deleteaaaaaad