Я хотел бы оптимизировать свои php-скрипты, на самом деле я реализую memcached (он сокращает время с: 30 секунд до 5 секунд) для php.Сначала подумайте, что вы должны увидеть скрипт на app.promls.net, на его сборку уйдет около 3 секунд (просмотрите исходник в конце, и вы увидите окно комментария с указанием времени выполнения).
далее думает, что я оптимизирую свой оператор выбора, используя объяснение:
SELECT SQL_CALC_FOUND_ROWS p.id , p.type, p.bathrooms, p.bedrooms, p.for_sale, p.for_rent, p.rent_price, p.sale_price, p.min_price, p.mid_price, p.hig_price, p.units, p.negotiation, p.status, p.square_meters, p.commission, p.address, p.currency_type, p.creation_date, p.modified_date, p.parent, p.property_name, p.area_id, p.amenities, p.unit_number, p.levels, p.for_vacational, p.construction_year, p.construction_density, p.plot_meters, p.community_fees, p.garbage_tax, p.mortage, p.accompanied_visit, p.sale_sign, (select up.path from uploads up where up.property_id = p.id order by position asc,id asc limit 0,1) as image, p.ref_catastral, p.vacational_term, p.property_keys, p.owner_id, p.property_type , pt.name_es as category, ci.description as city, ci.id as city_id, es.description as estate, es.parent as estate_id, co.description as country, co.parent as country_id, u.id as brokerid, u.fullname as brokername, u.phone brokerphone, u.cellphone brokermobile , u.username as brokeremail, c.address as companyaddress, c.phone as companyphone, c.name as companyname, c.website companyweb, c.email companyemail, c.id as companyid FROM properties p inner join property_types pt on pt.id = p.property_type inner join areas ci on ci.id = p.area_id inner join areas es on es.id = ci.parent inner join areas co on co.id = es.parent inner join users u on u.id = p.created_by inner join company c on c.id = p.company_id where p.status in('active','active-rented','active-sold') order by p.min_price asc, p.mid_price asc, p.hig_price asc, p.rent_price asc, p.sale_price asc limit 0, 10
объяснение:
> 1, 'PRIMARY', 'p', 'ALL',
> 'property_area,property_status', '',
> '', '', 142, 'Using where; Using
> temporary; Using filesort' 1,
> 'PRIMARY', 'c', 'ref', 'PRIMARY',
> 'PRIMARY', '4',
> 'inmobili.p.company_id', 1, 'Using
> where' 1, 'PRIMARY', 'pt', 'eq_ref',
> 'PRIMARY', 'PRIMARY', '4',
> 'inmobili.p.property_type', 1, 'Using
> where' 1, 'PRIMARY', 'u', 'ALL',
> 'PRIMARY', '', '', '', 4, 'Using
> where' 1, 'PRIMARY', 'ci', 'eq_ref',
> 'PRIMARY', 'PRIMARY', '4',
> 'inmobili.p.area_id', 1, '' 1,
> 'PRIMARY', 'es', 'eq_ref', 'PRIMARY',
> 'PRIMARY', '4', 'inmobili.ci.parent',
> 1, '' 1, 'PRIMARY', 'co', 'eq_ref',
> 'PRIMARY', 'PRIMARY', '4',
> 'inmobili.es.parent', 1, '' 2,
> 'DEPENDENT SUBQUERY', 'up', 'ref',
> 'property_uploads',
> 'property_uploads', '4',
> 'inmobili.p.id', 5, 'Using where;
> Using filesort'
, как вы можете видеть, он возвращает мне 142 строки из свойств таблицыи временная таблица, потому что у where есть следующее условие:
where p.status in('active','active-sold','active-rented');
, чтобы исправить, что я реализую индекс на p.status.но несоответствие происходит, когда я использую где только с одним значением как:
where p.status in('active');
, это возвращает мне только 77 строк и дополнительно: «использующий где; использующий временный; использующий файловую сортировку» в объяснении;если только изменить условие where, но если я снимаю условие порядка, оно делает те же 77 строк и дополнительно: «используя где;», поэтому я хотел бы знать, как я могу оптимизировать MySQL, используя объяснение, и когда выбор содержит «порядок»операторы "or" group by ".
Кстати, я слышал, что использование хранимых процедур быстрее, чем простой выбор из php, но при обращении к источнику wordpress не используется процедура, поэтому я предполагаю, что использовать процедурыэто не решение проблемы.
Как бы я ни думал, чтобы использовать hiphop для php, возможно, это могло бы помочь.
Я использую выделенный сервер.Конфигурация для php должна быть в порядке, потому что у меня есть другой поддомен, который загружается наиболее быстро, чем это приложение, сценарий такой же, но база данных - это firebird, и я реализую memcached и процедуры хранения.
Как вы думаете, мне нужно вернуться к firebird или mysql может справиться с этим?
Я очень ценю вашу помощь, если вы видите, что мое приложение выполняет сценарий за 30 секунд, поэтому мне действительно нужно оптимизироватьэто;
скажите мне, если вам нужна дополнительная информация, я буду абсолютно доступен для ее предоставления!позволяет общаться по MSN или Skype, если хотите.
заранее спасибо