Sqlserver
 sql >> डेटाबेस >  >> RDS >> Sqlserver

प्राथमिक कुंजी के रूप में GUID का उपयोग करने के लिए, विशेष रूप से प्रदर्शन के संबंध में सर्वोत्तम अभ्यास क्या हैं?

GUID आपकी प्राथमिक कुंजी के लिए एक स्वाभाविक विकल्प प्रतीत हो सकते हैं - और यदि आपको वास्तव में चाहिए, तो आप संभवतः तालिका की प्राथमिक कुंजी के लिए इसका उपयोग करने के लिए तर्क दे सकते हैं। मैं पुरज़ोर अनुशंसा करता हूँ नहीं करने के लिए GUID कॉलम का उपयोग क्लस्टरिंग कुंजी . के रूप में करता है , जो SQL सर्वर डिफ़ॉल्ट रूप से करता है, जब तक कि आप इसे विशेष रूप से नहीं बताते।

आपको वास्तव में दो मुद्दों को अलग रखना होगा:

  1. प्राथमिक कुंजी एक तार्किक निर्माण है - उम्मीदवार कुंजी में से एक जो आपकी तालिका में प्रत्येक पंक्ति को विशिष्ट और विश्वसनीय रूप से पहचानती है। यह वास्तव में कुछ भी हो सकता है - एक INT , एक GUID , एक स्ट्रिंग - वह चुनें जो आपके परिदृश्य के लिए सबसे उपयुक्त हो।

  2. क्लस्टरिंग कुंजी (स्तंभ या कॉलम जो टेबल पर "क्लस्टर इंडेक्स" को परिभाषित करते हैं) - यह एक भौतिक है भंडारण से संबंधित चीज, और यहां, एक छोटा, स्थिर, लगातार बढ़ता हुआ डेटा प्रकार आपकी सबसे अच्छी पसंद है - INT या BIGINT आपके डिफ़ॉल्ट विकल्प के रूप में।

डिफ़ॉल्ट रूप से, SQL सर्वर तालिका पर प्राथमिक कुंजी का उपयोग क्लस्टरिंग कुंजी के रूप में भी किया जाता है - लेकिन ऐसा होने की आवश्यकता नहीं है! पिछले GUID-आधारित प्राथमिक/क्लस्टर कुंजी को दो अलग-अलग कुंजी में विभाजित करते समय मैंने व्यक्तिगत रूप से बड़े पैमाने पर प्रदर्शन लाभ देखा है - GUID पर प्राथमिक (तार्किक) कुंजी, और एक अलग INT IDENTITY(1,1) कॉलम।

जैसा कि किम्बर्ली ट्रिप - अनुक्रमण की रानी - और अन्य ने कई बार एक महान कहा है - एक GUID चूंकि क्लस्टरिंग कुंजी इष्टतम नहीं है, क्योंकि इसकी यादृच्छिकता के कारण, यह बड़े पैमाने पर पृष्ठ और अनुक्रमणिका विखंडन और आम तौर पर खराब प्रदर्शन की ओर ले जाएगी।

हाँ, मुझे पता है - वहाँ newsequentialid() है SQL सर्वर 2005 और बाद के संस्करणों में - लेकिन यह भी सही मायने में और पूरी तरह से अनुक्रमिक नहीं है और इस प्रकार GUID जैसी ही समस्याओं से ग्रस्त है - बस थोड़ा कम प्रमुखता से।

फिर विचार करने के लिए एक और मुद्दा है:एक टेबल पर क्लस्टरिंग कुंजी आपकी टेबल पर प्रत्येक गैर-क्लस्टर इंडेक्स पर प्रत्येक प्रविष्टि में भी जोड़ दी जाएगी - इस प्रकार आप वास्तव में यह सुनिश्चित करना चाहते हैं कि यह जितना संभव हो उतना छोटा हो। आमतौर पर, एक INT 2+ अरब पंक्तियों के साथ अधिकांश तालिकाओं के लिए पर्याप्त होना चाहिए - और GUID . की तुलना में क्लस्टरिंग कुंजी के रूप में, आप स्वयं को डिस्क और सर्वर मेमोरी में सैकड़ों मेगाबाइट संग्रहण सहेज सकते हैं।

त्वरित गणना - INT . का उपयोग करके बनाम GUID प्राथमिक और क्लस्टरिंग कुंजी के रूप में:

  • 1'000'000 पंक्तियों वाली आधार तालिका (3.8 एमबी बनाम 15.26 एमबी)
  • 6 गैर-संकुल अनुक्रमणिका (22.89 एमबी बनाम 91.55 एमबी)

कुल:25 एमबी बनाम 106 एमबी - और वह सिर्फ एक टेबल पर है!

विचार के लिए कुछ और भोजन - किम्बर्ली ट्रिप द्वारा उत्कृष्ट सामग्री - इसे पढ़ें, इसे फिर से पढ़ें, इसे पचाएं! यह वास्तव में SQL सर्वर अनुक्रमण सुसमाचार है।

  • प्राथमिक कुंजी और/या क्लस्टर कुंजी के रूप में GUID
  • संकुल अनुक्रमणिका बहस जारी है
  • निरंतर बढ़ती क्लस्टरिंग कुंजी - क्लस्टर्ड इंडेक्स डिबेट ..... फिर से!
  • डिस्क स्थान सस्ता है - यह नहीं . है बात!

पीएस:बेशक, अगर आप केवल कुछ सौ या कुछ हज़ार पंक्तियों से निपट रहे हैं - इनमें से अधिकतर तर्कों का वास्तव में आप पर अधिक प्रभाव नहीं पड़ेगा। हालांकि:यदि आप दसियों या सैकड़ों हजारों पंक्तियों में आते हैं, या आप लाखों में गिनना शुरू करते हैं - फिर वे बिंदु बहुत महत्वपूर्ण और समझने में बहुत महत्वपूर्ण हो जाते हैं।

अपडेट करें: अगर आप अपना PKGUID रखना चाहते हैं कॉलम आपकी प्राथमिक कुंजी के रूप में (लेकिन आपकी क्लस्टरिंग कुंजी नहीं), और दूसरा कॉलम MYINT (INT IDENTITY ) अपनी क्लस्टरिंग कुंजी के रूप में - इसका उपयोग करें:

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )

ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)

CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

मूल रूप से:आपको बस स्पष्ट रूप से . करना होगा PRIMARY KEY बताएं बाधा है कि यह NONCLUSTERED है (अन्यथा यह डिफ़ॉल्ट रूप से आपकी संकुल अनुक्रमणिका के रूप में बनाया जाता है) - और फिर आप एक दूसरी अनुक्रमणिका बनाते हैं जिसे CLUSTERED के रूप में परिभाषित किया जाता है

यह काम करेगा - और यह एक वैध विकल्प है यदि आपके पास एक मौजूदा सिस्टम है जिसे प्रदर्शन के लिए "पुन:इंजीनियर" करने की आवश्यकता है। एक नई प्रणाली के लिए, यदि आप बिल्कुल नए सिरे से शुरू करते हैं, और आप एक प्रतिकृति परिदृश्य में नहीं हैं, तो मैं हमेशा ID INT IDENTITY(1,1) चुनूंगा। मेरी संकुल प्राथमिक कुंजी के रूप में - किसी भी चीज़ से कहीं अधिक कुशल!



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL सर्वर:DELETE बनाम TRUNCATE

  2. SQL सर्वर में DB_NAME () कैसे काम करता है

  3. एमएस एसक्यूएल सर्वर 2005 में ओवर के लिए कोई समर्थन नहीं?

  4. SQL सर्वर 2017 में एक डेटाबेस बनाएँ

  5. SQL सर्वर डेटाबेस (T-SQL) से डेटा फ़ाइल कैसे निकालें