MySQL'de görünümler ne zaman kullanılır?

Analizde kullanılmak üzere birden fazla birleşimden tablolar oluştururken, görünümleri yeni bir tablo oluşturmak yerine kullanmak ne zaman tercih edilir?

Görünümleri kullanmayı tercih etmemin bir nedeni, veritabanı şemasının yöneticimiz tarafından Ruby içinden geliştirildiğinden ve Ruby'ye aşina olmamamdır. Tabloların oluşturulmasını talep edebilirim, ancak ek bir adım gerektirir ve yeni bağlantılar geliştirirken / test ederken daha fazla esneklik istiyorum.

SO ile ilgili bir sorunun cevabını izleyen görünümleri kullanmaya başladım (ne zaman R, ne zaman SQL kullanılır ). En çok oy alan cevap başlıyor "veri tek bir tabloya gelinceye kadar SQL'deki veri manipülasyonlarını yapın ve gerisini R" de yapın. "

Görünümleri kullanmaya başladım, ancak görünümlerle ilgili birkaç sorunla karşılaştım:

1. sorgular çok daha yavaş
2. Üretimden, analiz için kullandığım yedekleme veritabanına atılmıyor.

Görünümler bu kullanım için uygun mu? Eğer öyleyse, performans cezası beklemeli miyim? Görünümlerle ilgili sorguları hızlandırmanın bir yolu var mı?

MySQL'deki görünümler iki farklı algoritmadan biri kullanılarak ele alınır: MERGEveya TEMPTABLE. MERGEbasitçe uygun takma adlarla bir sorgu genişletme TEMPTABLEgöründüğü gibi, görünüm WHERE yan tümcesini çalıştırmadan önce sonuçları geçici bir tabloya yerleştiriyor ve üzerinde dizin yok.

'Üçüncü' seçeneği, UNDEFINEDMySQL'e uygun algoritmayı seçmesini söyler. MySQL kullanmaya çalışacak MERGEçünkü daha verimli. Ana ihtar:

MERGE algoritması kullanılamıyorsa, bunun yerine geçici bir tablo kullanılmalıdır. Görünüm aşağıdaki yapılardan birini içeriyorsa MERGE kullanılamaz:

• Toplama işlevleri (SUM (), MIN (), MAX (), COUNT () vb.)

• DISTINCT

• GRUP TARAFINDAN

• HAVING

• SINIR

• BİRLİK veya BİRLİK TÜMÜ

• Seçim listesindeki alt sorgu

• Yalnızca değişmez değerleri ifade eder (bu durumda, altta yatan tablo yoktur)

[Src]

VIEWS'iniz TEMPTABLE algoritmasını gerektirdiğini ve performans sorunlarına neden olduğunu tahmin ediyorum.

İşte MySQL'deki görüşlerin performansıyla ilgili gerçekten eski bir blog yazısı ve daha iyi anlaşılmadığı görülüyor.

Bununla birlikte, tünelin sonunda, indeks içermeyen (tam tablo taramalarına neden olan) geçici tablolar konusuna biraz ışık olabilir. In 5.6 :

FROM yan tümcesinde bir alt sorgu için materyalizasyon gerektiğinde, optimizer materyalize tablosuna bir dizin ekleyerek sonuca erişimi hızlandırabilir. ... Dizini ekledikten sonra, en iyi duruma getirici, maddileştirilmiş türetilmiş tabloyu, bir dizin içeren normal bir tabloyla aynı şekilde işlemden geçirebilir ve oluşturulan dizinden benzer şekilde yararlanır. Dizin oluşturmanın ek yükü, dizin olmadan sorgu yürütme maliyetine kıyasla önemsizdir.

@Ypercube işaret ettiği gibi, MariaDB 5.3 aynı optimizasyon ekledi. Bu makalede süreçle ilgili ilginç bir genel bakış var:

Optimizasyon uygulandıktan sonra türetilmiş tablo, birleştirilmiş VIEW için ölçütlere uymadığında ortaya çıkan, SELECT ana parametresine birleştirilemedi.

Görüşler güvenlik araçlarıdır. Belirli bir kullanıcının veya uygulamanın veri tablonuzun nerede olduğunu bilmesini istemiyorsanız, yalnızca ihtiyaç duyduğu sütunları içeren bir görünüm sağlar.

Görünümlerin performansı her zaman azalttığını unutmayın; benzer sorgular görünümler değil, saklı yordamlar ve işlevler olmalıdır.

Bir sorgu ayarlaması yapmak için her zaman en iyi uygulamaları takip edin, WHERE yan tümcelerinde işlev kullanmaktan kaçının, seçimleri hızlandırmak için dizinler oluşturun, ancak kötüye kullanmayın; bozulan ekleri, güncellemeleri ve silmeyi endeksler.

Size yardımcı olabilecek iyi belgeler var: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

Bence görünümler, birden fazla tablo sorgusunun üstesinden gelmek için tabloları bir araya getirmek için önceden tanımlanmış yapıdır (veri yok), hızlı ilişkisel sorgulama için gerçek verilerden kullanılabilir ...