Коли використовувати перегляди в MySQL?

Коли створюється таблиці з декількох об'єднань для використання в аналізі, коли краще використовувати представлення даних, а не створювати нову таблицю?

Однією з причин, що я вважаю за краще використовувати представлення даних, є те, що схема бази даних була розроблена нашим адміністратором з Ruby, і я не знайомий з Ruby. Я можу попросити створити таблиці, але це потребує додаткового кроку, і я хотів би більше гнучкості при розробці / тестуванні нових з'єднань.

Я почав використовувати перегляди, відповівши на відповідне запитання щодо SO ( Коли використовувати R, коли використовувати SQL ). Відповідь, що голосує вгорі, починається "виконайте маніпуляції з даними в SQL, поки дані не опиняться в одній таблиці, а потім зробіть решту в Р."

Я почав використовувати перегляди, але зіткнувся з кількома проблемами з переглядами:

1. запити значно повільніші
2. Перегляди не вивантажуються із виробничої в резервну базу даних, яку я використовую для аналізу.

Чи підходять підходи для цього використання? Якщо так, чи слід очікувати штрафного виконання? Чи є спосіб пришвидшити запити щодо переглядів?

Перегляди в MySQL обробляються за допомогою одного з двох різних алгоритмів: MERGEабо TEMPTABLE. MERGEце просто розширення запиту відповідними псевдонімами. TEMPTABLEце саме те, що це звучить, представлення переносить результати у тимчасову таблицю перед запуском пункту WHERE, і в ній немає індексів.

"Третій" варіант - UNDEFINEDце вказує MySQL вибрати відповідний алгоритм. MySQL буде намагатися використовувати, MERGEоскільки він більш ефективний. Головний кавер:

Якщо алгоритм MERGE не може бути використаний, замість нього слід використовувати тимчасову таблицю. MERGE не можна використовувати, якщо представлення містить будь-яку з наступних конструкцій:

• Сукупні функції (SUM (), MIN (), MAX (), COUNT () тощо)

• ДИСТИНКТ

• ГРУПА ПО

• ВИДАЛЕНО

• ОБМЕЖЕННЯ

• Союз або Союз ВСЕ

• Підзапит у списку вибору

• Посилається лише на буквальні значення (у цьому випадку немає базової таблиці)

[src]

Я б ризикну здогадатися, що ваші VIEWS вимагають алгоритму TEMPTABLE, викликаючи проблеми з продуктивністю.

Ось справді стара публікація в блозі про ефективність переглядів у MySQL, і вона, схоже, не стала краще.

Однак, в кінці тунелю може бути трохи світла щодо тимчасових таблиць, що не містять індексів (спричиняючи повне сканування таблиці). У 5.6 :

У випадках, коли необхідна матеріалізація для підзапиту в пункті FROM, оптимізатор може прискорити доступ до результату, додавши індекс до матеріалізованої таблиці. ... Після додавання індексу оптимізатор може обробити матеріалізовану похідну таблицю так само, як і звичайну таблицю з індексом, і це також виграє аналогічно від створеного індексу. Витрати на створення індексу незначні порівняно з витратами на виконання запиту без індексу.

Як вказує @ypercube, MariaDB 5.3 додав таку ж оптимізацію. У цій статті є цікавий огляд процесу:

Оптимізація застосовується, тоді отримана таблиця не може бути об'єднана в її батьківську SELECT, що відбувається, коли похідна таблиця не відповідає критеріям для об'єднання VIEW

Перегляди - це засоби безпеки. Ви не хочете, щоб певний користувач чи програма знали, де знаходиться ваша таблиця даних, ви надаєте представлення лише потрібних стовпців.

Пам'ятайте, що представлення завжди погіршують продуктивність, подібні запити повинні зберігатися в процедурах і функціях, а не в представленнях.

Щоб здійснити налаштування запитів, завжди дотримуйтесь кращих практик, уникайте використання функцій у пунктах WHERE, створюйте індекси для прискорення вибору, але не зловживайте цим, індексуючи погіршує вставки, оновлення та видалення.

Існує добра документація, яка може допомогти вам: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

Я думаю, погляди - це заздалегідь визначена структура (немає даних) для об'єднання таблиць в одну для подолання з декількох запитів таблиці, яка може бути використана з реальних даних для швидких реляційних запитів ...