MySQL Create View и производительность

Question

У меня следующий вопрос.У меня есть две таблицы, и я хочу хранить их отдельно.Однако в моем приложении мне нужно регулярно выполнять операции UNION над ними, поэтому мне нужно рассматривать их как единое целое.Я думаю, что это не очень хорошо с точки зрения производительности.Я думал о создании следующего представления:

CREATE VIEW merged_tables(fields from both tables) AS
  SELECT * FROM table_a
UNION
  SELECT * FROM table_b

Как это влияет на производительность запроса SELECT?Имеет ли это какое-либо реальное влияние (внутреннее представление отличается) или просто вопрос использования более простого запроса для выбора?

Спасибо за любую помощь.

Answer 1

Использование UNION внутри представления не будет отличаться по производительности от использования UNION в дискретном операторе SELECT. Поскольку вы используете SELECT * в обеих таблицах и не требует внутренней сложности (например, нет предложений JOINS или WHERE), на самом деле не будет никакого способа его дальнейшей оптимизации.

Однако, если таблицы содержат одинаковые данные и вы хотите, чтобы они были логически разделены, вы можете рассмотреть возможность их хранения в одной таблице с логическим столбцом, который указывает, была бы строка в противном случае резидентом table_a table_b. Вы получаете способ разделять строки и избегаете путаницы с UNION тогда, и на производительность также не оказывает существенного влияния.

Answer 2

Это просто вопрос использования более простого запроса для выбора.Разницы в скорости не будет, однако стоимость запроса объединения не должна быть намного хуже (в большинстве случаев), чем если бы вы хранили все данные в одной таблице.

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

 CREATE VIEW table_a AS SELECT * FROM table_all WHERE rec_type = 'A'
 CREATE VIEW table_b AS SELECT * FROM table_all WHERE rec_type = 'B'

Поскольку это неагрегированные таблицы с одной таблицейПРОСМОТР, вы можете использовать их как таблицы в INSERT, UPDATE, DELETE и SELECT, но у вас есть преимущество в том, что вы также можете программировать против table_all, когда это имеет смысл.Преимущество этого решения перед вашим решением заключается в том, что вы можете обновлять данные как для table_a, table_b , так и table_all, и у вас нет двух физических таблиц для обслуживания.