डेटाबेस में निहित आदेश की कमी कैसे साबित करें?


21

हाल ही में मैं सहयोगियों को एक कॉलम होने के महत्व के बारे में समझा रहा था जिसके द्वारा डेटाबेस तालिका में डेटा को सॉर्ट करना है यदि ऐसा करना आवश्यक है, उदाहरण के लिए कालानुक्रमिक रूप से आदेशित डेटा। यह कुछ हद तक मुश्किल साबित हुआ क्योंकि वे अपनी क्वेरी को बिना किसी कारण के फिर से चला सकते थे और यह हमेशा उसी क्रम में पंक्तियों के एक ही सेट को लौटाता था।

मैंने पहले भी इस पर ध्यान दिया है और मैं वास्तव में यह कर सकता हूं कि वे मुझ पर भरोसा करें और यह न मानें कि डेटाबेस टेबल एक पारंपरिक सीएसवी या एक्सेल फाइल की तरह व्यवहार करेगा।

उदाहरण के लिए, (PostgreSQL) क्वेरी को निष्पादित करना

create table mytable (
    id INTEGER PRIMARY KEY,
    data TEXT
);
INSERT INTO mytable VALUES
    (0, 'a'),
    (1, 'b'),
    (2, 'c'),
    (3, 'd'),
    (4, 'e'),
    (5, 'f'),
    (6, 'g'),
    (7, 'h'),
    (8, 'i'),
    (9, 'j');

एक स्पष्ट वैचारिक आदेश के साथ एक तालिका बनाएगा। उसी डेटा का चयन सबसे सरल तरीके से किया जाएगा:

SELECT * FROM mytable;

हमेशा मुझे निम्नलिखित परिणाम मिलते हैं:

 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  5 | f
  6 | g
  7 | h
  8 | i
  9 | j
(10 rows)

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

इसलिए, मेरे प्रश्न अनिवार्य रूप से ये हैं:

  1. मैं बिना किसी ORDER BYकथन के किसी प्रश्न से पंक्तियों के वापसी क्रम को कैसे विश्वसनीय और संक्षिप्त रूप से साबित कर सकता हूं कि अधिमानतः जब तक कि तालिका को अद्यतन या संपादित नहीं किया जाता है, तब तक अंतर्निहित आदेश के टूटने को दर्शाता है ?

  2. क्या इससे कोई फ़र्क पड़ता है अगर डेटा को केवल एक बार डाला जाता है और फिर कभी अपडेट नहीं किया जाता है?

मैं एक उत्तर-आधारित उत्तर को प्राथमिकता दूंगा क्योंकि वह वही है जिससे मैं सबसे अधिक परिचित हूं लेकिन मैं सिद्धांत में ही अधिक रुचि रखता हूं।


6
"कभी नहीं लिखा या फिर से अद्यतन" - यह एक मेज क्यों है? एक फाइल की तरह लगता है। या एक एनम। या ऐसा कुछ जो डेटाबेस में होना आवश्यक नहीं है। यदि यह कालानुक्रमिक है, तो क्या ऑर्डर करने के लिए कोई तारीख स्तंभ नहीं है? यदि कालक्रम मायने रखता है तो आपको लगता है कि जानकारी तालिका में होना काफी महत्वपूर्ण होगी। वैसे भी, किसी व्यक्ति को एक नया सूचकांक छोड़ने या बनाने, या स्मृति परिवर्तन, ट्रेस झंडे या अन्य प्रभावों जैसी घटनाओं के कारण योजना बदल सकती है। की तरह "। मैं अपने सीट बेल्ट कभी नहीं पहनते हैं और मैं अपने विंडशील्ड के माध्यम से कभी नहीं चले गए हैं, इसलिए मैं अपने सीट बेल्ट नहीं पहनी जारी रहेगा" :-( उनका तर्क लगता है
हारून बर्ट्रेंड

9
कुछ तर्क समस्याओं को सिर्फ तकनीकी रूप से या एचआर की भागीदारी के बिना हल नहीं किया जा सकता है। यदि आपकी कंपनी डेवलपर प्रथाओं को अनुमति देना चाहती है जो वूडू में विश्वास करने और दस्तावेज़ीकरण की अनदेखी करने पर निर्भर करती है, और आपका उपयोग मामला वास्तव में एक छोटी मेज तक सीमित है जिसे कभी भी अपडेट नहीं किया जाता है, तो बस उन्हें अपना रास्ता दें और अपना फिर से शुरू करें। यह बहस के लायक नहीं है।
हारून बर्ट्रेंड

1
आपके पास "हमेशा रहेगा" दावा करने का कोई आधार नहीं है। आप केवल दावा कर सकते हैं "हमेशा", "जब मैंने जाँच की"। भाषा की एक परिभाषा है - यह उपयोगकर्ता के साथ अनुबंध है।
दीक्षा

10
मुझे उत्सुकता है कि आप के ये साथी order byअपने प्रश्नों का खंड जोड़ने के खिलाफ क्यों हैं ? क्या वे स्रोत कोड संग्रहण पर सहेजने का प्रयास कर रहे हैं? कीबोर्ड पहनते हैं और आंसू? खूंखार क्लॉज टाइप करने में कितना समय लगता है?
mustaccio

2
मैंने हमेशा सोचा है कि डेटाबेस इंजन को बेतरतीब ढंग से प्रश्नों की पहली कुछ पंक्तियों की अनुमति देनी चाहिए, जिसके लिए शब्दार्थ परीक्षण की सुविधा प्रदान करने के लिए आदेश की गारंटी नहीं देते हैं।
डग मैकक्लेन

जवाबों:


30

मैं उन्हें समझाने की कोशिश करने के तीन तरीके देखता हूं:

  1. उन्हें एक ही क्वेरी की कोशिश करें लेकिन बड़ी तालिका (पंक्तियों की अधिक संख्या) के साथ या जब तालिका निष्पादन के बीच अद्यतन की जा रही है। या नई पंक्तियाँ डाली जाती हैं और कुछ पुरानी हटा दी जाती हैं। या निष्पादन के बीच एक इंडेक्स जोड़ा या हटाया जाता है। या तालिका निर्वात है (पोस्टग्रेज में)। या अनुक्रमणिका फिर से बनाई गई हैं (SQL सर्वर में)। या तालिका को क्लस्टर से ढेर में बदल दिया जाता है। या डेटाबेस सेवा को पुनरारंभ किया गया है।

  2. आप सुझाव दे सकते हैं कि वे साबित करते हैं कि विभिन्न निष्पादन एक ही क्रम में वापस आएंगे। क्या वे इसे साबित कर सकते हैं? क्या वे परीक्षणों की एक श्रृंखला प्रदान कर सकते हैं जो साबित करता है कि कोई भी क्वेरी उसी क्रम में परिणाम देगी, चाहे वह कितनी बार निष्पादित हो?

  3. उस मामले में विभिन्न DBMS के प्रलेखन प्रदान करें। उदाहरण के लिए:

PostgreSQL :

पंक्तियों को क्रमबद्ध करना

एक क्वेरी के बाद एक आउटपुट टेबल का उत्पादन किया है (चयन सूची संसाधित होने के बाद) यह वैकल्पिक रूप से सॉर्ट किया जा सकता है। यदि छंटाई को नहीं चुना जाता है, तो पंक्तियों को अनिर्दिष्ट क्रम में वापस कर दिया जाएगा। उस मामले में वास्तविक आदेश स्कैन पर निर्भर करेगा और डिस्क पर योजना प्रकार और आदेश में शामिल हो जाएगा , लेकिन यह निर्भर नहीं होना चाहिए। एक विशेष आउटपुट ऑर्डरिंग की गारंटी केवल तभी दी जा सकती है जब सॉर्ट स्टेप स्पष्ट रूप से चुना गया हो।

SQL सर्वर :

SELECT- ORDER BYखण्ड (लेनदेन-एसक्यूएल)

SQL सर्वर में क्वेरी द्वारा लौटाया गया डेटा सॉर्ट करता है। इस क्लॉज का उपयोग करें:

निर्दिष्ट कॉलम सूची द्वारा क्वेरी का परिणाम सेट करें और वैकल्पिक रूप से, निर्दिष्ट सीमा पर लौटी पंक्तियों को सीमित करें। जिस क्रम में परिणाम सेट में लौटे पंक्तियों की गारंटी नहीं दी जाती है जब तक कि एक ORDER BYखंड निर्दिष्ट नहीं किया जाता है।

ओरेकल :

order_by_clause

ORDER BYकथन द्वारा पंक्तियों को वापस करने के लिए क्लॉज का उपयोग करें । एक ऑर्डर_बाइक के बिना, इस बात की कोई गारंटी नहीं है कि एक ही क्वेरी को एक से अधिक बार निष्पादित किया गया है, उसी क्रम में पंक्तियों को पुनः प्राप्त करेगा।


बहुत छोटी तालिकाओं के साथ जो संशोधित नहीं हैं, आप इस व्यवहार को देख सकते हैं। यह अपेक्षित है। लेकिन इसकी गारंटी भी नहीं है। आदेश बदल सकता है क्योंकि आपने एक इंडेक्स जोड़ा है या आपने एक इंडेक्स को संशोधित किया है या आपने डेटाबेस और संभवतः कई अन्य मामलों को फिर से शुरू किया है।
ypercube y

6
यदि आदेश मायने रखता है, तो जो कभी भी अपने कोड की समीक्षा करने के लिए जिम्मेदार है, उन्हें तब तक अस्वीकार करना चाहिए जब तक वे ORDER BY का उपयोग न करें। DBMSs (Oracle, SQL Server, Postgres) के डेवलपर्स सभी एक ही बात कहते हैं कि उनके उत्पाद की गारंटी क्या है और क्या नहीं (और उन्हें मुझे जितना भुगतान किया जाएगा उससे कहीं अधिक का भुगतान किया जाता है, इसलिए वे जानते हैं कि वे क्या कह रहे हैं, इसके अलावा इन लानतें बनाई गई हैं चीजें)।
ypercube y

1
यहां तक ​​कि अगर आदेश अब भी समान दिखता है, तो क्या यह निश्चित है कि ये टेबल आपके द्वारा बनाए जा रहे सॉफ़्टवेयर के पूरे जीवनकाल में कभी अपडेट नहीं होंगे? कि अब और पंक्तियाँ नहीं डाली जाएंगी, कभी?
ypercube y

1
क्या कोई गारंटी है कि यह तालिका हमेशा यह छोटी होगी? क्या कोई गारंटी है कि कोई और कॉलम नहीं जोड़ा जाएगा? मैं दसियों अलग-अलग मामलों को देख सकता हूं जहां भविष्य में तालिका बदली जा सकती है (और इनमें से कुछ परिवर्तन क्वेरी परिणाम के क्रम को प्रभावित कर सकते हैं)। मेरा सुझाव है कि आप उन्हें इन सभी का जवाब देने के लिए कहें। क्या वे गारंटी दे सकते हैं कि ऐसा कुछ भी कभी नहीं होगा? और वे एक सरल क्यों नहीं जोड़ेंगे ORDER BY, जो आदेश की गारंटी देगा, कोई फर्क नहीं पड़ता कि तालिका कैसे बदलने जा रही है ? क्यों नहीं एक सुरक्षित जोड़ा है, जो कोई नुकसान नहीं करता है?
ypercube y

10
प्रलेखन पर्याप्त होना चाहिए। किसी भी चीज का दूसरा अनुमान है, और किसी भी दर पर, कभी भी निश्चित नहीं देखा जाएगा, चाहे आप जो भी साबित करें। यह हमेशा ऐसा कुछ होगा जो आपने किया और समझा जा सकता है, शायद आपके खर्च पर, बजाय इसके कि कुछ हो । प्रलेखन के साथ सशस्त्र, लिखित रूप में अपनी "वारंटी" जमा करें, और आवश्यक क्रम में पंक्तियों को वापस न करने के लिए लिखित अनुमति लें (आपको नहीं मिलेगा)।

19

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

Postgres प्रलेखन इस कहते हैं स्पष्ट रूप से:

यदि ORDER BY नहीं दिया जाता है, तो पंक्तियों को जिस भी क्रम में उत्पादन करने के लिए सबसे तेज़ पाया जाता है, वापस कर दिया जाता है।

इस मामले में "सिस्टम" में पोस्टग्रैस डेमॉन शामिल है (इसके डेटा एक्सेस के तरीकों और क्वेरी ऑप्टिमाइज़र के कार्यान्वयन सहित), अंतर्निहित ऑपरेटिंग सिस्टम, डेटाबेस स्टोरेज के तार्किक और भौतिक लेआउट, संभवतः सीपीयू कैश भी। चूंकि आप डेटाबेस उपयोगकर्ता का उस स्टैक पर कोई नियंत्रण नहीं है, इसलिए आपको इस पर भरोसा नहीं करना चाहिए कि जिस तरह से यह बहुत ही मिनट का व्यवहार करता है, उसे हमेशा के लिए जारी रखना चाहिए।

आपके सहकर्मी जल्दबाजी के सामान्यीकरण को कम कर रहे हैं । उनकी बात को खारिज करने के लिए यह दिखाना पर्याप्त है कि उनकी धारणा केवल एक बार गलत है, जैसे इस dbfiddle द्वारा ।


12

निम्नलिखित उदाहरण पर विचार करें, जहां हमारे पास तीन संबंधित टेबल हैं। आदेश, उपयोगकर्ता, और ऑर्डरडेल। ऑर्डरडेलेट्स विदेशी कुंजियों के साथ आदेश तालिका और उपयोगकर्ता तालिका से जुड़ा हुआ है। यह मूल रूप से संबंधपरक डेटाबेस के लिए एक बहुत ही विशिष्ट सेटअप है; यकीनन एक संबंधपरक डीबीएमएस का संपूर्ण उद्देश्य ।

USE tempdb;

IF OBJECT_ID(N'dbo.OrderDetails', N'U') IS NOT NULL
DROP TABLE dbo.OrderDetails;

IF OBJECT_ID(N'dbo.Orders', N'U') IS NOT NULL
DROP TABLE dbo.Orders;

IF OBJECT_ID(N'dbo.Users', N'U') IS NOT NULL
DROP TABLE dbo.Users;

CREATE TABLE dbo.Orders
(
    OrderID int NOT NULL
        CONSTRAINT OrderTestPK
        PRIMARY KEY
        CLUSTERED
    , SomeOrderData varchar(1000)
        CONSTRAINT Orders_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

CREATE TABLE dbo.Users
(
    UserID int NOT NULL
        CONSTRAINT UsersPK
        PRIMARY KEY
        CLUSTERED
    , SomeUserData varchar(1000)
        CONSTRAINT Users_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

CREATE TABLE dbo.OrderDetails
(
    OrderDetailsID int NOT NULL
        CONSTRAINT OrderDetailsTestPK
        PRIMARY KEY
        CLUSTERED
    , OrderID int NOT NULL
        CONSTRAINT OrderDetailsOrderID
        FOREIGN KEY
        REFERENCES dbo.Orders(OrderID)
    , UserID int NOT NULL
        CONSTRAINT OrderDetailsUserID
        FOREIGN KEY
        REFERENCES dbo.Users(UserID)
    , SomeOrderDetailsData varchar(1000)
        CONSTRAINT OrderDetails_somedata_df
        DEFAULT (CRYPT_GEN_RANDOM(1000))
);

INSERT INTO dbo.Orders (OrderID)
SELECT TOP(100) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc;

INSERT INTO dbo.Users (UserID)
SELECT TOP(100) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc;

INSERT INTO dbo.OrderDetails (OrderDetailsID, OrderID, UserID)
SELECT TOP(10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
    , o.OrderID
    , u.UserID
FROM sys.syscolumns sc
    CROSS JOIN dbo.Orders o
    CROSS JOIN dbo.Users u
ORDER BY NEWID();

CREATE INDEX OrderDetailsOrderID ON dbo.OrderDetails(OrderID);
CREATE INDEX OrderDetailsUserID ON dbo.OrderDetails(UserID);

यहां, हम ऑर्डरडेटा टेबल की क्वेरी कर रहे हैं, जहां UserID 15 है:

SELECT od.OrderDetailsID
    , o.OrderID
    , u.UserID
FROM dbo.OrderDetails od
    INNER JOIN dbo.Users u ON u.UserID = od.UserID
    INNER JOIN dbo.Orders o ON od.OrderID = o.OrderID
WHERE u.UserID = 15

क्वेरी से आउटपुट जैसा दिखता है:

╔════════════════╦═════════╦════════╗
║ आर्डरडाइट्स ails आर्डरिड ║ यूजरआईडी ails
╠════════════════╬═════════╬════════╣
║ 2200115 ║ 2 ║ 15 ║
║ 630215 ║ 3 ║ 15 ║
║ 1990215 ║ 3 ║ 15 ║
15 4960215 ║ 3 ║ 15 15
║ 100715 ║ 8 ║ 15 ║
15 3930815 ║ 9 ║ 15 15
║ 6310815 ║ 9 ║ 15 ║
║ 4441015 ║ 11 ║ 15 ║
║ 2171315 ║ 14 ║ 15 ║
15 3431415 ║ 15 ║ 15 15
15 4571415 15 15 ║ 15 15
15 6421515 ║ 16 ║ 15 15
15 2271715 15 18 ║ 15 15
15 2601715 15 18 ║ 15 15
15 3521715 15 18 ║ 15 15
║ 221815 ║ 19 ║ 15 ║
15 3381915 ║ 20 ║ 15 15
15 4471915 15 20 ║ 15 15
╚════════════════╩═════════╩════════╝

जैसा कि आप देख सकते हैं, आदेश आउटपुट तालिका में पंक्तियों के क्रम से मेल नहीं खाता है।

एक स्पष्ट ORDER BYसुनिश्चित करने वाली पंक्तियों को जोड़ना ग्राहक को वांछित क्रम में वापस कर दिया जाएगा:

SELECT od.OrderDetailsID
    , o.OrderID
    , u.UserID
FROM dbo.OrderDetails od
    INNER JOIN dbo.Users u ON u.UserID = od.UserID
    INNER JOIN dbo.Orders o ON od.OrderID = o.OrderID
WHERE u.UserID = 15
ORDER BY od.OrderDetailsID;
╔════════════════╦═════════╦════════╗
║ आर्डरडाइट्स ails आर्डरिड ║ यूजरआईडी ails
╠════════════════╬═════════╬════════╣
║ 3915 ║ 40 ║ 15 ║
║ 100715 ║ 8 ║ 15 ║
║ 221815 ║ 19 ║ 15 ║
║ 299915 ║ 100 ║ 15 ║
║ 368215 ║ 83 ║ 15 ║
║ 603815 ║ 39 ║ 15 ║
║ 630215 ║ 3 ║ 15 ║
║ 728515 ║ 86 ║ 15 ║
║ 972215 ║ 23 ║ 15 ║
║ 992015 ║ 21 ║ 15 ║
║ 1017115 ║ 72 ║ 15 ║
║ 1113815 15 39 ║ 15 15
╚════════════════╩═════════╩════════╝

यदि पंक्तियों का क्रम अत्यावश्यक है, और आपके इंजीनियर जानते हैं कि आदेश अत्यावश्यक है, तो उन्हें केवल एक कथन का उपयोग करना चाहिए ORDER BY, क्योंकि यह गलत क्रम से संबंधित विफलता होने पर उन्हें उनके पदनाम के लिए खर्च करना पड़ सकता है।

एक दूसरा, शायद अधिक शिक्षाप्रद उदाहरण, OrderDetailsऊपर से तालिका का उपयोग करते हुए , जहां हम किसी अन्य तालिका में शामिल नहीं हो रहे हैं , लेकिन ऑर्डर और उपयोगकर्ता दोनों से मेल खाते पंक्तियों को खोजने के लिए एक सरल आवश्यकता है, हम समस्या देखते हैं।

यदि आप किसी भी तरह से महत्वपूर्ण हैं (जब यह नहीं है) तो हम क्वेरी का समर्थन करने के लिए एक इंडेक्स बनाएंगे, जैसा कि आप वास्तविक जीवन में करेंगे।

CREATE INDEX OrderDetailsOrderIDUserID ON dbo.OrderDetails(OrderID, UserID);

यहाँ प्रश्न है:

SELECT od.OrderDetailsID
FROM dbo.OrderDetails od
WHERE od.OrderID = 15
    AND (od.UserID = 21 OR od.UserID = 22)

और परिणाम:

╔════════════════╗
Ails ऑर्डरडेलेट्सआईडी ails
╠════════════════╣
║ 21421 ║
21 5061421 21
21 7091421 21
║ 691422 ║
22 3471422 22
22 7241422 22
╚════════════════╝

एक ORDER BYक्लॉज जोड़ना निश्चित रूप से सुनिश्चित करेगा कि हमें यहां सही प्रकार मिले, भी।

ये मॉक-अप केवल सरल उदाहरण हैं जहां पंक्तियों को स्पष्ट ORDER BYविवरण के बिना "क्रम में" होने की गारंटी नहीं है । इस तरह के कई और उदाहरण हैं, और चूंकि डीबीएमएस इंजन कोड काफी बार बदलता है, इसलिए समय के साथ विशिष्ट व्यवहार बदल सकता है।


10

एक व्यावहारिक उदाहरण के रूप में, Postgres में, जब आप किसी पंक्ति को अद्यतन करते हैं तो वर्तमान में क्रम बदल जाता है:

% SELECT * FROM mytable;
 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  5 | f
  6 | g
  7 | h
  8 | i
  9 | j
(10 rows)

% UPDATE mytable SET data = 'ff' WHERE id = 5;
UPDATE 1
% SELECT * FROM mytable;
 id | data 
----+------
  0 | a
  1 | b
  2 | c
  3 | d
  4 | e
  6 | g
  7 | h
  8 | i
  9 | j
  5 | ff
(10 rows)

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


यह है प्रलेखित: ypercube के जवाब प्रलेखन हमें बता कि आदेश अनिर्दिष्ट है उद्धरण।
मोनिका

@LightnessRacesinOrbit मुझे लगता है कि प्रलेखन स्पष्ट रूप से हमें बता रहा है कि यह दस्तावेज नहीं है। मेरा मतलब है, यह भी सच है कि दस्तावेज में कुछ भी अनिर्दिष्ट नहीं है। यह एक तरह की तनातनी है। वैसे भी, मैंने उत्तर के उस हिस्से को अधिक विशिष्ट होने के लिए संपादित किया।
जोएल

3

वास्तव में डेमो नहीं है, लेकिन एक टिप्पणी के लिए बहुत लंबा है।

बड़े तालिकाओं पर कुछ डेटाबेस समानांतर स्कैन करेगा।

यदि दो प्रश्न एक ही तालिका को स्कैन करना चाहते हैं, और लगभग एक ही समय पर आते हैं, तो दूसरा शुरू होने पर तालिका के माध्यम से पहला भाग हो सकता है।

दूसरी क्वेरी तालिका के मध्य से शुरू होने वाले रिकॉर्ड प्राप्त कर सकती है (जैसा कि पहली क्वेरी पूरी हो रही है) और फिर तालिका की शुरुआत से रिकॉर्ड प्राप्त करें।


2

एक क्लस्टर इंडेक्स बनाएं जिसमें "गलत" ऑर्डर है। उदाहरण के लिए, क्लस्टर पर ID DESC। यह अक्सर रिवर्स ऑर्डर का उत्पादन करेगा (हालांकि इसकी गारंटी नहीं है)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.