Ускорение выполнения запроса MySQL

[Gulik]

Всем привет.
Есть такой запрос:

SELECT
  PA.ID,
  PA.OldPACode,
  PA.PACode,
  PA.ID_PropertyKind,
  PA.ID_Street,
  PA.AssertDate,
  PA.FromDate,
  PA.ToDate,
  PA.ID_Employee,
  PA.ID_Terminal,
  PA.OldOwnerCode,
  PA.Home,
  PA.HomeCode,
  PA.Building,
  PA.BuildingCode,
  PA.Doorway,
  PA.Floor,
  PA.Flat,
  PA.FlatCode,
  PA.OwnerCode,
  PA.Suffix,
  PA.ID_Owner,
  CONCAT((SELECT Type FROM Town WHERE (SELECT ID_Town FROM Street WHERE PA.ID_Street = ID) = ID), 
    (SELECT Name FROM Town WHERE (SELECT ID_Town FROM Street WHERE PA.ID_Street = ID) = ID)) as Town,
  (SELECT Code FROM Town WHERE (SELECT ID_Town FROM Street WHERE PA.ID_Street = ID) = ID) as TownCode,
  (SELECT ID_Town FROM Street WHERE PA.ID_Street = ID) as ID_Town,
  CONCAT((SELECT Type FROM Street WHERE PA.ID_Street = ID), 
   (SELECT Nm FROM Street WHERE PA.ID_Street = ID)) as Street,
  (SELECT Code FROM Street WHERE PA.ID_Street = ID) as StreetCode,
  (SELECT Type FROM Owner WHERE PA.ID_Owner = ID) as OwnerType,
  (SELECT ShortName FROM Owner WHERE PA.ID_Owner = ID) as PAOwner,
  (SELECT Name FROM Terminal WHERE PA.ID_Terminal = ID) as Terminal,
  (SELECT TerminalCode FROM Terminal WHERE PA.ID_Terminal = ID) as TerminalCode,
  (SELECT Name FROM PropertyKind WHERE PA.ID_PropertyKind = ID) as PAPropertyKind,
  (SELECT Name FROM Employee WHERE PA.ID_Employee = ID) as Employee
FROM
  PersonalAccount PA

В результате получается более 4000 записей
Но на его выполнение уходит больше минуты
Это строка получена после выполнения запроса (HeidiSQL):
/* 0 rows affected, 4,073 rows found. Duration for 1 query: 1,391 sec. (+ 116,297 sec. network) */
Вопрос как можно ускорить выполнение этого запроса?
При этом использование LIMIT крайне не удобно.
До этого прога была на Access и запрос выполнялся за 1 сек.

[Stilet]

А что этот жуткий запроц делает? (делать должен)

[Gulik]

Возможно я не понял вопроса, но отвечу как понял.
По сути просто делает выборку из главной таблицы (т.е. список лицевых счетов организации выводит). Но из-за присоединенных таблиц жутко долго выбирает. Если делать выборку по другому то возникают проблемы с редактированием и удалением записей.

SELECT
  PA.ID,
  PA.OldPACode,
  PA.PACode,
  PA.ID_PropertyKind,
  PA.ID_Street,
  PA.AssertDate,
  PA.FromDate,
  PA.ToDate,
  PA.ID_Employee,
  PA.ID_Terminal,
  PA.OldOwnerCode,
  PA.Home,
  PA.HomeCode,
  PA.Building,
  PA.BuildingCode,
  PA.Doorway,
  PA.Floor,
  PA.Flat,
  PA.FlatCode,
  PA.OwnerCode,
  PA.Suffix,
  PA.ID_Owner,
  E.Name as Employee
FROM
  PersonalAccount PA, Employee E
WHERE
  PA.ID_Employee = E.ID

[Stilet]

Но из-за присоединенных таблиц жутко долго выбирает.

А индексы везде нужные прописаны?
Уже поздно структуру менять?

[Аватар]

Конечно не ручаюсь, без отладки тяжело, но если убрать все вложенные запросы (через JOIN) то должно быть существенно быстрей

SELECT
  PA.ID,
  PA.OldPACode,
  PA.PACode,
  PA.ID_PropertyKind,
  PA.ID_Street,
  PA.AssertDate,
  PA.FromDate,
  PA.ToDate,
  PA.ID_Employee,
  PA.ID_Terminal,
  PA.OldOwnerCode,
  PA.Home,
  PA.HomeCode,
  PA.Building,
  PA.BuildingCode,
  PA.Doorway,
  PA.Floor,
  PA.Flat,
  PA.FlatCode,
  PA.OwnerCode,
  PA.Suffix,
  PA.ID_Owner,
  CONCAT(Tn.Type,Tn.Name) as Town,
  Tn.Code as TownCode,
  St.ID_Town as ID_Town,
  CONCAT(St.Type,St.Nm) as Street,
  St.Code as StreetCode,
  Ow.Type as OwnerType,
  Ow.ShortName as PAOwner,
  Te.Name as Terminal,
  Te.TerminalCode as TerminalCode,
  Pr.Name as PAPropertyKind,
  Em.Name as Employee
FROM
  PersonalAccount PA
    LEFT JOIN PropertyKind Pr ON Pr.ID=PA.ID_PropertyKind
    LEFT JOIN Employee Em ON Em.ID=PA.ID_Employee
    LEFT JOIN Owner Ow ON Ow.ID=PA.ID_Owner
    LEFT JOIN Terminal Te ON Te.ID=PA.ID_Terminal
    LEFT JOIN Street St ON St.ID=PA.ID_Street
    LEFT JOIN Town Tn ON Tn.ID=St.ID_Town

[Gulik]

Stilet
Нет, структуру менять не поздно. Спасибо, что напомнил про индексы. Щас буду копать в этом направлении.

Аватар
Да, скорость выполнения запроса увеличилась.
/* 0 rows affected, 4,073 rows found. Duration for 1 query: 6,891 sec. (+ 56,078 sec. network) */
Но все равно минута, это много...

[Stilet]

Нет, структуру менять не поздно.

Тогда может стоит подумать над новой более оптимальной структурой? Я бы прежде всего об этом задумался.
т.е. какие будут запросы, на считывание с "густой" реляцией или будет постоянная запись-редактирование - структуру нужно строить исходя из ответов на эти вопросы.

[Gulik]

Stilet
Спасибо, за советы, дело было в индексах, в таблице Owner поле ID не содержало индекса, после его установки все залетало.
/* 0 rows affected, 4,073 rows found. Duration for 1 query: 0,021 sec. (+ 0,192 sec. network) */
Да, таблица будет постоянно редактироваться и из всех вариантов запросов этот был самым оптимальным (т.к. в других случаях при сохранении возникали различные ошибки (прим. "Недостаточно сведений для обновления ключевого поля", или удаление записей из присоединенных таблиц)), вот только затормозил

[Stilet]

и из всех вариантов запросов этот был самым оптимальным

И всетки я бы JOINами решал задачу...