Оптимизация объединения нескольких представлений MySQL

Question

У меня есть несколько представлений в моей базе данных, в которых я пытаюсь выполнить JOIN, когда определенные запросы становятся очень сложными.В худшем случае мне пришлось бы объединить 3 представления со следующей статистикой:

• Представление 1 содержит 60 КБ + строк с 26 полями.
• Представление 2 имеет 60 КБ + строк с 15 полями.
• Представление 3 содержит 80K + строк с 8 полями.

Объединение представлений 1 и 2 не вызывает проблем, но каждый раз, когда я пытаюсь присоединиться к третьему представлению, запрос зависает.Мне интересно, есть ли какие-нибудь лучшие практики, которым я должен следовать, чтобы эти запросы не зависали.Я пытался использовать наименьшие возможные поля (средние / маленькие, если это возможно, т. Д.).

Мы используем версию сообщества MySQL 5.0.92 с таблицами MyISAM.Не уверен, что InnoDB будет более эффективным.

В качестве последнего средства я подумал о том, чтобы разделить один запрос на два, перейти к представлениям 1 и 2 с первым запросом, а затем просмотреть 3 по отдельности с помощью третьего.Есть ли минус в этом, кроме как сделать 2 запроса?

Спасибо.

Answer 1

Вам нужно использовать EXPLAIN , чтобы понять, почему производительность низкая.

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

Answer 2

Я собираюсь опубликовать свои комментарии в качестве ответа:

1) Посмотрите на команду EXPLAIN и посмотрите, что она говорит.выполнение отдельных взглядов.Являются ли они такими же быстрыми, как вы думаете?

3) Столбцы, которые вы используете в своих предложениях WHERE или JOIN, имеют ли базовые таблицы индексы, которые к ним относятся?Что следует иметь в виду:

Составной индекс (индекс с более чем одним столбцом) со столбцами (a, b) не поможет при запросе только для b.Это помогает с a, и a + b, но не только с b.Вот почему один добавленный вами индекс улучшил ситуацию

4) Используете ли вы все столбцы и все представления?Если вы не хотите, было бы проще взглянуть на представления и вместо этого придумать запрос?

Answer 3

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