Czy widok jest szybszy niż proste zapytanie?
Jest
select * from myView
Szybciej niż samo zapytanie, aby utworzyć widok (aby mieć ten sam resultSet):
select * from ([query to create same resultSet as myView])
?
Nie jest dla mnie do końca jasne, czy Widok używa jakiegoś buforowania, co czyni go szybszym w porównaniu z prostym zapytaniem.
14 answers
Tak, widoki mogą mieć przypisany indeks klastrowy, a kiedy to zrobią, będą przechowywać tymczasowe wyniki, które mogą przyspieszyć wynikowe zapytania.
Update: przynajmniej trzy osoby zagłosowały na mnie. Z całym szacunkiem, uważam, że są one po prostu błędne; własna dokumentacja Microsoftu bardzo jasno pokazuje, że widoki mogą poprawić wydajność.
Po pierwsze, proste widoki są rozszerzane na miejscu, więc nie przyczyniają się bezpośrednio do poprawy wydajności - tyle to prawda. jednakże, zindeksowane widoki mogą radykalnie poprawić wydajność.
Pozwól mi przejść bezpośrednio do dokumentacji:
Po utworzeniu unikalnego klastrowego indeksu w widoku, zbiór wyników widoku jest natychmiast materializowany i przechowywany w fizycznej pamięci w bazie danych, oszczędzając koszty wykonania tej kosztownej operacji w czasie wykonywania.
Po drugie, te zindeksowane widoki mogą działać nawet wtedy, gdy nie są bezpośrednio odwołuje się do innego zapytania jako optymalizator użyje ich zamiast odniesienia do tabeli, gdy będzie to właściwe.
Znowu dokumentacja:
Widok zindeksowany może być używany w wykonywaniu zapytania na dwa sposoby. Zapytanie może odwoływać się bezpośrednio do widoku zindeksowanego lub, co ważniejsze, optymalizator zapytań może wybrać Widok, jeśli stwierdzi, że widok można zastąpić niektórymi lub wszystkimi zapytaniami w planie zapytań o najniższym koszcie. W drugim przypadku Widok zindeksowany jest używane zamiast bazowych tabel i ich zwykłych indeksów. Widok nie musi być odwoływany w zapytaniu, aby optymalizator zapytań mógł go używać podczas wykonywania zapytań. Dzięki temu istniejące aplikacje mogą korzystać z nowo utworzonych widoków indeksowanych bez zmiany tych aplikacji.
Ta dokumentacja, jak również wykresy demonstrujące ulepszenia wydajności, można znaleźć tutaj .
Update 2: Odpowiedź została skrytykowana na podstawie że to "indeks" zapewnia przewagę wydajności, a nie "Widok"."Jednak można to łatwo obalić.
Powiedzmy, że jesteśmy firmą programistyczną w małym kraju; użyję Litwy jako przykładu. Sprzedajemy oprogramowanie na całym świecie i przechowujemy nasze dane w bazie danych SQL Server. Odnosimy sukcesy i w ciągu kilku lat mamy ponad 1 000 000 rekordów. Jednak często musimy zgłaszać sprzedaż do celów podatkowych i okazuje się, że sprzedaliśmy tylko 100 kopii naszego oprogramowania w naszym ojczyzna. Tworząc zindeksowany Widok tylko litewskich rekordów, możemy przechowywać potrzebne rekordy w zindeksowanym buforze, jak opisano w dokumentacji MS. Gdy w 2008 roku uruchomimy nasze raporty sprzedaży na Litwie, nasze zapytanie przeszukiwane będzie przez Indeks o głębokości zaledwie 7(Log2 (100) z kilkoma nieużywanymi listkami). Gdybyśmy mieli zrobić to samo bez widoku i po prostu opierając się na indeksie do tabeli, musielibyśmy przejść drzewo indeksów z głębokością wyszukiwania 21!
Sam widok zapewniłby nam przewagę wydajnościową (3x) nad prostym użyciem samego indeksu. Próbowałem użyć prawdziwego przykładu, ale zauważ, że prosta lista litewskich sprzedaży dałaby nam jeszcze większą przewagę.
Zauważ, że używam tylko prostego drzewa b dla mojego przykładu. Chociaż jestem dość pewien, że SQL Server używa jakiegoś wariantu drzewa b, nie znam szczegółów. Niemniej jednak, punkt trzyma.
Update 3: pojawiło się pytanie o tym, czy Widok Zindeksowany używa tylko indeksu umieszczonego w tabeli bazowej. Oznacza to, że parafrazując: "widok zindeksowany jest tylko odpowiednikiem standardowego indeksu i nie oferuje nic nowego ani unikalnego dla widoku."Gdyby to była prawda, oczywiście, to powyższa analiza byłaby błędna! Pozwól mi podać cytat z Dokumentacji Microsoftu, który pokazuje, dlaczego uważam, że ta krytyka nie jest poprawna lub prawdziwa: {]}
Używanie indeksów w celu poprawy wydajności zapytań nie jest nową koncepcją; jednak widoki indeksowane zapewniają dodatkowe korzyści wydajnościowe, których nie można osiągnąć przy użyciu standardowych indeksów.
Wraz z powyższym cytatem dotyczącym trwałości danych w fizycznym magazynie i innych informacji w dokumentacji o tym, jak indeksy są tworzone w widokach, myślę, że można bezpiecznie powiedzieć, że indeksowany widok to , a nie tylko buforowany Select SQL, który używa indeksu zdefiniowanego w głównej tabeli. Tak więc nadal podtrzymuję tę odpowiedź.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-15 12:47:16
Ogólnie rzecz biorąc, nie. widoki są używane przede wszystkim dla wygody i bezpieczeństwa, a nie dla poprawy prędkości.
To powiedziawszy, SQL Server 2000 i nowsze mają specjalną funkcję o nazwie zindeksowane widoki , Które mogą znacznie poprawić wydajność, ale musisz utworzyć zindeksowane widoki zgodnie z bardzo specyficznym zestawem wytycznych .
W książkach Online jest ważne odniesienie do rozdzielczości widoku.
Oto artykuł opisujący korzyści i tworzenie zindeksowanych widoków :
Od wielu lat Microsoft® SQL Server™ wspiera możliwość tworzenia wirtualne tabele zwane widokami. Historycznie poglądy te służyły tym główne cele:
Aby zapewnić mechanizm bezpieczeństwa, który ogranicza użytkowników do pewnego podzbioru dane w jednej lub kilku tabelach bazowych.
Aby zapewnić mechanizm umożliwiający Programiści do dostosowania jak użytkownicy mogą logicznie Przeglądaj dane zapisane w bazie stoły.
Z SQL Server 2000, funkcjonalność widoków SQL Server została rozszerzony w celu zapewnienia wydajności systemu korzyści. Możliwe jest stworzenie unikalny indeks klastrowy w widoku, jako jak również indeksy niezakłócone, do poprawa wydajności dostępu do danych na najbardziej złożone zapytania. W SQL Server 2000 i 2005, widok, który ma unikalny indeks klastrowy jest określany jako widok zindeksowany.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-15 22:20:50
W SQL Server przynajmniej plany zapytań są przechowywane w buforze planu zarówno dla widoków, jak i zwykłych zapytań SQL, opartych na parametrach zapytania/widoku. W obu przypadkach są one usuwane z pamięci podręcznej, gdy były nieużywane przez wystarczająco długi czas i miejsce jest potrzebne na inne nowo przesłane zapytanie. Po czym, jeśli to samo zapytanie zostanie wydane, jest rekompilowane, a plan jest umieszczany z powrotem w pamięci podręcznej. Więc nie, nie ma różnicy, biorąc pod uwagę, że używasz ponownie tego samego zapytania SQL i tego samego widoku z tą samą częstotliwością.
Oczywiście, ogólnie rzecz biorąc, widok, z samej natury (że ktoś myślał, że był używany wystarczająco często, aby przekształcić go w widok) jest na ogół bardziej prawdopodobny do "ponownego użycia" niż dowolne dowolne polecenie SQL.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-13 14:21:56
EDIT: myliłem się i powinieneś zobaczyć znaki odpowiedzi powyżej.
Nie mogę mówić z doświadczenia z SQL Server , ale dla większości baz danych odpowiedź brzmiałaby nie. Jedyną potencjalną korzyścią, jaką można uzyskać, pod względem wydajności, z korzystania z widoku, jest to, że może on potencjalnie utworzyć pewne ścieżki dostępu na podstawie zapytania. Głównym powodem użycia widoku jest uproszczenie zapytania lub standaryzacja sposobu dostępu do niektórych danych w tabeli. Ogólnie rzecz biorąc, nie uzyskaj korzyści z wydajności. Ale mogę się mylić.
Chciałbym wymyślić umiarkowanie bardziej skomplikowany przykład i czas go zobaczyć.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:47:32
Może być szybciej, jeśli stworzysz zmaterializowany widok (z wiązaniem schematu). Widoki niematerialne wykonują się tak samo jak zwykłe zapytanie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-08-27 18:17:59
Rozumiem, że jakiś czas temu Widok byłby szybszy, ponieważ SQL Server mógłby przechowywać plan wykonania, a następnie po prostu go używać, zamiast próbować go rozgryźć w locie. Myślę, że wzrost wydajności w dzisiejszych czasach nie jest prawdopodobnie tak wielki, jak kiedyś, ale muszę się domyślać, że będzie jakaś marginalna poprawa, aby korzystać z widoku.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-08-27 18:18:47
Spodziewam się, że te dwa zapytania będą działać identycznie. Widok jest niczym innym jak zapisaną definicją zapytania, nie ma buforowania ani przechowywania danych dla widoku. Optymalizator skutecznie zmieni Twoje pierwsze zapytanie w drugie podczas jego uruchamiania.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-13 14:14:41
Zdecydowanie widok jest lepszy niż zagnieżdżone zapytanie dla SQL Server. Nie wiedząc dokładnie, dlaczego jest lepiej (dopóki nie przeczytałem posta Marka Brittinghama), przeprowadziłem kilka testów i doświadczyłem niemal szokującej poprawy wydajności podczas korzystania z widoku w porównaniu z zagnieżdżonym zapytaniem. Po uruchomieniu każdej wersji zapytania kilkaset razy z rzędu, wersja widoku zapytania została ukończona w połowie czasu. To dla mnie wystarczający dowód.
Nie ma praktycznej różnicy i jeśli przeczytasz BOL, przekonasz się, że zawsze twój zwykły stary SQL SELECT * z X korzysta z buforowania planu itp.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-13 14:15:14
Powinien być jakiś trywialny zysk w przechowywaniu planu wykonania, ale będzie znikomy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-13 14:31:45
Celem widoku jest używanie zapytania w kółko. W tym celu SQL Server, Oracle itp. zazwyczaj udostępnia "buforowaną " lub" skompilowaną " wersję widoku, poprawiając w ten sposób jego wydajność. Ogólnie rzecz biorąc, powinno to działać lepiej niż "proste" zapytanie, choć jeśli zapytanie jest naprawdę bardzo proste, korzyści mogą być znikome.
Teraz, jeśli robisz złożone zapytanie, Utwórz widok.
Według mnie korzystanie z widoku jest trochę szybsze niż zwykłe zapytanie. Moja procedura składowana trwała około 25 minut (praca z różnymi większymi zestawami rekordów i wieloma połączeniami) i po użyciu widoku (bez klastra) wydajność była tylko trochę szybsza, ale wcale nie znacząca. Musiałem użyć innych technik/metod optymalizacji zapytań, aby uczynić to dramatyczną zmianą.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-08-27 18:22:02
Wszystko zależy od sytuacji. Widoki indeksowane MS SQL są szybsze niż normalny widok lub zapytanie, ale widoki indeksowane nie mogą być używane w bazie danych lustrzanych invironment (MS SQL).
Widok w dowolnej pętli spowoduje poważne spowolnienie, ponieważ widok jest ponownie wypełniany za każdym razem, gdy jest wywoływany w pętli. To samo, co zapytanie. W tej sytuacji tymczasowa tabela używająca # lub @ do przechowywania danych w pętli jest szybsza niż widok lub zapytanie.
Więc wszystko zależy od sytuacja.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-15 14:24:17
Select from a View or from a table will not have too much sense.
Oczywiście jeśli Widok Nie ma niepotrzebnych łączeń, pól itp. Możesz sprawdzić plan wykonania zapytań, złączeń i indeksów używanych do poprawy wydajności widoku.
Możesz nawet utworzyć indeks widoków w celu szybszego wyszukiwania. http://technet.microsoft.com/en-us/library/cc917715.aspx
Ale jeśli szukasz jak'%...%' niż silnik sql nie skorzysta z indeks w kolumnie tekstowej. Jeśli możesz zmusić swoich użytkowników do wyszukiwania jak '...% 'than that will be fast
[[0]] odpowiedź na forum asp : https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-18 06:58:14