चूंकि आप चयनित एल्गोरिथम को नियंत्रित नहीं करते हैं, इसलिए सीधे जानने का कोई तरीका नहीं है। हालांकि, इंडेक्स के बिना एक चयन ओ (एन) होना चाहिए (एक टेबल स्कैन को प्रत्येक रिकॉर्ड का निरीक्षण करना होता है जिसका अर्थ है कि यह तालिका के आकार के साथ स्केल करेगा)।
एक इंडेक्स के साथ एक चयन शायद ओ (लॉग (एन)) है (हालांकि यह इंडेक्सिंग के लिए उपयोग किए जाने वाले एल्गोरिदम और डेटा के गुणों पर निर्भर करेगा यदि यह किसी वास्तविक तालिका के लिए सही है)। किसी भी तालिका या क्वेरी के लिए अपने परिणाम निर्धारित करने के लिए आपको सुनिश्चित करने के लिए वास्तविक विश्व डेटा की रूपरेखा का सहारा लेना होगा।
अनुक्रमणिका के बिना INSERT बहुत तेज़ होना चाहिए (O(1) के करीब) जबकि UPDATE को पहले रिकॉर्ड खोजने की आवश्यकता है और इसलिए आपको वहां पहुंचने वाले SELECT की तुलना में धीमा (थोड़ा) होगा।
इंडेक्स के साथ INSERT शायद फिर से ओ (लॉग (एन ^ 2)) के बॉलपार्क में होगा जब इंडेक्स पेड़ को फिर से संतुलित करने की आवश्यकता होती है, ओ (लॉग (एन)) के करीब अन्यथा। एक ही मंदी एक अद्यतन के साथ होगी यदि यह अनुक्रमित पंक्तियों को SELECT लागतों के शीर्ष पर प्रभावित करती है।
एक बार जब आप मिश्रण में शामिल होने के बारे में बात कर रहे हों तो सभी दांव बंद हो जाते हैं:आपको इसे पढ़ने के लिए प्रोफाइल करना होगा और अपने डेटाबेस क्वेरी अनुमान उपकरण का उपयोग करना होगा। यह भी ध्यान दें कि यदि यह क्वेरी प्रदर्शन महत्वपूर्ण है तो आपको पुन: . करना चाहिए जैसे-जैसे डेटा लोड बदलता है, वैसे-वैसे आपके क्वेरी ऑप्टिमाइज़र द्वारा उपयोग किए जाने वाले एल्गोरिदम बदलेंगे।
ध्यान में रखने वाली एक और बात... बिग-ओ आपको प्रत्येक लेनदेन के लिए निश्चित लागत के बारे में नहीं बताता है। छोटी तालिकाओं के लिए ये संभवतः वास्तविक कार्य लागत से अधिक हैं। एक उदाहरण के रूप में:एक पंक्ति के लिए क्रॉस नेटवर्क क्वेरी का सेटअप, फाड़ना और संचार लागत निश्चित रूप से एक छोटी तालिका में अनुक्रमित रिकॉर्ड की तलाश से अधिक होगी।
इस वजह से मैंने पाया कि एक बैच में संबंधित प्रश्नों के समूह को बंडल करने में सक्षम होने से मेरे द्वारा डेटाबेस के लिए किए गए किसी भी अनुकूलन की तुलना में प्रदर्शन पर बहुत अधिक प्रभाव पड़ सकता है।
