एक व्यू टेबल की तरह काम करता है , लेकिन यह एक टेबल नहीं है। यह कभी मौजूद नहीं है; यह केवल एक तैयार SQL कथन है जिसे तब चलाया जाता है जब आप दृश्य नाम का संदर्भ देते हैं। आईई:
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
...चलने के बराबर है:
SELECT x.*
FROM (SELECT * FROM bar) x
एक MySQLDump में कभी भी दृश्य में सम्मिलित करने के लिए पंक्तियाँ नहीं होंगी...
वह, दुख की बात है, (यद्यपि संदिग्ध) डिजाइन द्वारा है। MySQL दृश्यों की कई सीमाएँ हैं, जो प्रलेखित हैं:http://dev.mysql.com/doc/refman/5.0/hi/create-view.html
तो यदि यह केवल एक काल्पनिक तालिका/तैयार कथन है, तो क्या इसका मतलब यह है कि सैद्धांतिक रूप से इसका प्रदर्शन सामान्य तालिका/क्वेरी के समान (या उससे भी कम) है?
नहीं.
एक तालिका में अनुक्रमणिकाएँ जुड़ी हो सकती हैं, जो डेटा पुनर्प्राप्ति को तेज़ कर सकती हैं (सम्मिलित/अपडेट करने के लिए कुछ लागत पर)। कुछ डेटाबेस "भौतिक" विचारों का समर्थन करते हैं, जो ऐसे विचार हैं जिन पर अनुक्रमणिका लागू हो सकती है - जो आश्चर्य की बात नहीं होनी चाहिए कि MySQL समर्थन नहीं करता सीमित दृश्य कार्यक्षमता को देखते हुए (जो केवल v5 IIRC में शुरू हुआ, खेल के लिए बहुत देर से)।
क्योंकि दृश्य एक व्युत्पन्न तालिका है, दृश्य का प्रदर्शन केवल उतना ही अच्छा होता है, जिस पर इसे बनाया गया है। यदि वह क्वेरी बेकार है, तो प्रदर्शन समस्या सिर्फ स्नोबॉल होगी ... उस ने कहा, जब एक दृश्य से पूछताछ की जाती है - यदि किसी फ़ंक्शन में WHERE क्लॉज में एक दृश्य कॉलम संदर्भ लपेटा नहीं जाता है (आईई:WHERE v.column LIKE ...
, नहीं WHERE LOWER(t.column) LIKE ...
), ऑप्टिमाइज़र मूल क्वेरी पर मापदंड (जिसे विधेय कहा जाता है) को धक्का दे सकता है - जिससे यह तेज़ हो जाता है।