индексы и ускорение «полученных» запросов

Question

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

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

 
SELECT eventdate.id, 
     eventdate.eid, 
     eventdate.date, 
     eventdate.time, 
     eventdate.title, 
     eventdate.address, 
     eventdate.rank, 
     eventdate.city, 
     eventdate.state, 
     eventdate.name, 
     source.link, 
     type, 
     eventdate.img 
FROM source 
RIGHT OUTER JOIN 
(
    SELECT event.id, 
      event.date, 
      users.name, 
      users.rank, 
      users.eid, 
      event.address, 
      event.city, 
      event.state, 
      event.lat, 
      event.`long`, 
      GROUP_CONCAT(types.type SEPARATOR ' | ') AS type 
    FROM event FORCE INDEX (latlong_idx) 
    JOIN users ON event.uid = users.id 
    JOIN types ON users.tid=types.id 
    WHERE `long` BETWEEN -74.36829174058 AND -73.64365405942 
    AND lat BETWEEN 40.35195025942 AND 41.07658794058 
    AND event.date >= '2009-10-15' 
    GROUP BY event.id, event.date 
    ORDER BY event.date, users.rank DESC 
    LIMIT 0, 20 
)eventdate 
ON eventdate.uid = source.uid 
AND eventdate.date = source.date; 

и объяснить это

 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 
| id | select_type | table  | type | possible_keys | key   | key_len | ref       | rows | Extra       | 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 
| 1 | PRIMARY  |   | ALL | NULL   | NULL  | NULL | NULL       | 20 |         | 
| 1 | PRIMARY  | source  | ref | iddate_idx | iddate_idx | 7  | eventdate.id,eventdate.date | 156 |         | 
| 2 | DERIVED  | event  | ALL | latlong_idx | NULL  | NULL | NULL       | 19500 | Using temporary; Using filesort | 
| 2 | DERIVED  | types  | ref | eid_idx  | eid_idx  | 4  | active.event.id    | 10674 | Using index      | 
| 2 | DERIVED  | users  | eq_ref | id_idx  | id_idx  | 4  | active.types.id    |  1 | Using where      | 
+----+-------------+------------+--------+---------------+-------------+---------+------------------------------+-------+---------------------------------+ 

Я попытался с помощью «индекса силы» на LatLong, но это не похоже, чтобы ускорить процесс в все.

Это производная таблица, которая вызывает медленные ответы? Если да, то есть ли способ повысить эффективность этого?

-------- EDIT ------------- Я попытался улучшить форматирование, чтобы сделать его более удобным для чтения, а также

я бегу Тот же самый запрос меняется только «WHERE заявление как

 
WHERE users.id = (
SELECT users.id 
FROM users 
WHERE uidname = 'frankt1' 
ORDER BY users.approved DESC , users.rank DESC 
LIMIT 1) 
AND date & gt ; = '2009-10-15' 
GROUP BY date 
ORDER BY date) 

Этот запрос выполняется в 0,006 секунд

объяснить как выглядит

 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 
| id | select_type | table  | type | possible_keys | key   | key_len | ref       | rows | Extra   | 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 
| 1 | PRIMARY  |   | ALL | NULL   | NULL   | NULL | NULL       | 42 |    | 
| 1 | PRIMARY  | source  | ref | iddate_idx | iddate_idx | 7  | eventdate.id,eventdate.date | 156 |    | 
| 2 | DERIVED  | users  | const | id_idx  | id_idx  | 4  |        | 1 |    | 
| 2 | DERIVED  | event  | range | eiddate_idx | eiddate_idx | 7  | NULL       | 24 | Using where | 
| 2 | DERIVED  | types  | ref | eid_idx  | eid_idx  | 4  | active.event.bid    | 3 | Using index | 
| 3 | SUBQUERY | users  | ALL | idname_idx | idname_idx | 767  |        | 5 | Using filesort | 
+----+-------------+------------+-------+---------------+---------------+---------+------------------------------+------+----------------+ 

Answer 1

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

В начале убедитесь, что все поля вашего идентификатора проиндексированы, но лучше убедитесь, что ваш дизайн действителен. Я не знаю, где СТАРТ смотреть на ваш SQL - даже после того, как я переформатировал его для вас.

Обратите внимание, что «использование индексов» означает, что вам необходимо выдать правильные инструкции при СОЗДАНИИ или ALTER используемых таблицах. См., Например, MySql 5.0 create indexes