запрос SQL присоединяется к нескольким таблицам - слишком медленный (8 таблиц)

В зависимости от объема данных в таблицах может потребоваться разместить индексы в столбцах, к которым выполняется соединение. Часто медленная скорость запросов сводится к отсутствию индекса в нужном месте.

Также:

ЛЕВЫЕ СОЕДИНЕНИЯ медленнее, чем ВНУТРЕННИЕ СОЕДИНЕНИЯ (хотя это зависит от того, что вы делаете точно) - можете ли вы выполнить то, что вы Ищите с внутренними соединениями?

Было бы немного полезно, если бы вы могли опубликовать план объяснения запроса.

Но, прежде всего, у вас есть индексы для всех полей, используемых в соединении? что-то вроде CREATE INDEX ix_t2_id для t2 (t2_id, t2_name);

Вместо соединений вы можете сделать что-то вроде

SELECT t1_id, 
    (select t2_name from t2 where t1_id = t2_id), 
    (select t3_name from t3 where t1_id = t3_id), 
    (select t4_name from t4 where t1_id = t4_id), 
    (select t5_name from t5 where t1_id = t5_id), 
    (select t6_name from t6 where t1_id = t6_id), 
    (select t7_name from t7 where t1_id = t7_id), 
    (select t8_name from t8 where t1_id = t8_id), 
    (select t9_name from t9 where t1_id = t9_id) 
FROM t1 

Но, с хорошим планировщиком запросов, это не должно отличаться от объединений.

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

Чтобы повысить производительность, вам нужно либо уменьшить набор результатов, либо выполнить неприятный трюк (например, сделать денормализованную копию данных).

О каком количестве данных мы говорим? Возможно, у вас много данных, и, поскольку в конце процесса запроса выполняется условие where, вы объединяете огромные объемы данных перед их фильтрацией.

В этом случае лучше отфильтровать данные, как только возможно, так что если вы можете ограничить данные из T1 в первом внутреннем выделении, все остальные объединения будут объединяться с более ограниченным набором данных.

Select <your fields> from
(
Select * from t1 where t1_id = t1_value
) t1

Inner join t2
on t1.ID = t2.ID
...

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

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

SELECT  t1_id, t2_name 
FROM    t1 LEFT JOIN t2 ON (t1_id = t2_id)
union 
SELECT  t1_id, t3_name 
FROM    t1 LEFT JOIN t3 ON (t1_id = t3_id)

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

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

Из вашего плана запросов я могу сделать вывод, что таблицы, называемые s , n и q , не имеют указатель на поле, к которому они присоединяются.

Поскольку в этих таблицах много строк (около 400 000 строк в их декартовом произведении) и единственный способ MySQL do JOIN использует NESTED LOOPS , это действительно будет длиться вечно.

Создайте индекс для этих таблиц или определите объединенное поле как PRIMARY KEY .

I had a similar problem with several lookup tables joining to a large table with all id fields indexed. To monitor the effect of the joins on query time execution, I ran my query several times (limiting to first 100 rows), adding a Join to an additional table each time. After joining 12 tables, there was no significant change in query execution time. By the time I had joined the 13th table the execution time jumped to a 1 second; 14th table 4 seconds, 15th table 20 s, 16th 90 seconds.

Keijro's suggestion to use a correlated subqueries instead of joins e.g.

SELECT t1_id, 
        (select t2_name from t2 where t1_id = t2_id), 
        (select t3_name from t3 where t1_id = t3_id), 
        (select t4_name from t4 where t1_id = t4_id), 
        (select t5_name from t5 where t1_id = t5_id), 
        (select t6_name from t6 where t1_id = t6_id), 
        (select t7_name from t7 where t1_id = t7_id), 
        (select t8_name from t8 where t1_id = t8_id), 
        (select t9_name from t9 where t1_id = t9_id)  FROM t1

improved query performance dramatically. In fact the subqueries did not seem to lengthen the time to execute the query (the query was almost instanteous).

I am a little suprised as I thought correlated subqueries perform worse than joins.

Depending on your version of SQL server, simply putting your query into a stored procedure may make a big difference. Try this after you have tried the other optimizations first.(Yes, I know there are cached execution plans and other internal server optimizations, but in my practical real-world experience, stored procedures can execute faster.)