2011-02-10 4 views
0

У меня есть приложение, размещенное на sandbox.promls.netMysql Php, запросы очень медленно

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

Это запрос, я выполнения (это мнение):

select SQL_CALC_FOUND_ROWS id , name, contact, email_contact, phone_contact, address, phone, fax, email, website, creation_date, last_modification, zipcode, longitude, latitude, gmtoffset, dstoffset, area_id, area, status , logo, type, owner_id, users, created_by, created_by_id 
    from companies_listing 
    limit 0,15 

Это займет 19.6522991657 секунд, чтобы выполнить. Помоги мне, пожалуйста!

структура зрения заключается в следующем:

вид структура выглядит следующим образом:

DROP VIEW IF EXISTS `companies_listing`; 
CREATE OR REPLACE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` 
    SQL SECURITY DEFINER VIEW `companies_listing` AS 
    select `c`.`id` AS `id`, `c`.`name` AS `name`,`c`.`contact` AS `contact`, 
    `c`.`phone_contact` AS `phone_contact`,`c`.`email_contact` AS `email_contact`, 
    `c`.`address` AS `address`,`c`.`phone` AS `phone`,`c`.`fax` AS `fax`, 
    `c`.`owner_id` AS `owner_id`,`c`.`email` AS `email`, 
    `c`.`website` AS `website`,`c`.`creation_date` AS `creation_date`, 
    `c`.`last_modification` AS `last_modification`,`c`.`zipcode` AS `zipcode`, 
    `c`.`type` AS `type`,`c`.`status` AS `status`,`a`.`description` AS `area`, 
    `c`.`area_id` AS `area_id`,`c`.`logo` AS `logo`, 
    `c`.`created_by` AS `creator_id`,`u`.`fullname` AS `creator`, 
    (select count(0) AS `count(*)` from `users` `uu` 
     where (`uu`.`company_id` = `c`.`id`) 
    ) AS `users` 
    from (
     (`company` `c` 
     join `areas` `a` 
     on((`a`.`id` = `c`.`area_id`)) 
     ) 
     join `users` `u` on((`u`.`id` = `c`.`created_by`)) 
    ); 

Query explain select id , name, contact, email_contact, phone_contact, address, 
       phone, fax, email, website, creation_date, last_modification, 
       area_id, area, status , logo, type, owner_id, users, creator, 
       creator_id 
       from companies_listing, Thu Feb 10 17:45:37 2011 

id select_type    table  type  possible_keys key key_len ref rows Extra 
1 PRIMARY     <derived2> ALL  10    (null) 
2 DERIVED     c   ALL  FK_company_1_company    18 (null) 
2 DERIVED     u   eq_ref  PRIMARY PRIMARY 4 inmobili.c.created_by 1 (null) 
2 DERIVED     a   eq_ref  PRIMARY PRIMARY 4 inmobili.c.area_id 1 (null) 
3 DEPENDENT SUBQUERY  uu   ref fk_user_company fk_user_company 4 inmobili.c.id 1 Using index 
+0

Ну, не могли бы вы опубликовать определение вида и его план выполнения? (запуск с ' EXPLAIN SELECT 'вместо просто' SELECT') Невозможно ничего рассказать с количеством данных, которые вы нам дали. – Piskvor

+0

Ничего себе. Как выглядит «EXPLAIN»? (Просто добавьте «объяснять» в инструкцию select в phpMyAdmin, если у вас есть это.) –

+0

Не могли бы вы включить некоторое представление о структуре таблицы, а также о количестве строк в таблице? Есть сотни причин, по которым запрос на базу данных может идти медленно, от плохого дизайна схемы, плохого или отсутствующего использования индексов, до неадекватных ресурсов на сервере. –

ответ

1

Я обнаружил, что использование SQL_CALC_FOUND_ROWS очень медленно все и все .. и что это почти быстрее просто взять и реплицировать запрос без ограничения, чем использовать mysql_num_rows для генерации количества строк, которые существуют.

Позвольте мне знать, если это помогает

+0

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

0
  • Те круглые скобки в вашем предложении FROM не добавляя разборчивости, и они оказывают влияние на эффективность (как основной запрос становится «производным», когда он не должен)
  • вы должны сделать индексы на всех colums, что вы вступающих/запрашивая по формуле (`c`.`area_id` и `c`.`created_by` являются очевидными
+0

был создан phpmyadmin. –

+0

@ Ангел Эстрада: ... и? Я не пытаюсь обвинить вас, я указываю возможные области для улучшения. phpMyAdmin, AFAIK, не пытается каким-либо образом оптимизировать ваш запрос - он сочтет это вместе, да, но он не будет стараться быть особенно эффективным. – Piskvor

+0

привет, хорошо. извините, я не пытался это отразить. кстати, позвольте мне сказать вам, что моя проблема решена, я действительно оптимизирую свои запросы, но были и другие проблемы: я использовал excesive использование шифрования данных, что делает мой скрипт очень медленным. я знаю, что знаю. если вы знаете один класс, который делает шифрование более быстрым. пожалуйста, дайте мне знать, спасибо заранее и спасибо agaen за помощь, позвольте мне сказать вам, что ваши комментарии были действительно полезными –

Смежные вопросы