SQL LIMIT बनाम JDBC स्टेटमेंट सेटMaxRows। इनमें से कोनसा बेहतर है?

एसक्यूएल-स्तर की सीमा

SQL क्वेरी परिणाम सेट आकार को प्रतिबंधित करने के लिए, आप SQL:008 सिंटैक्स का उपयोग कर सकते हैं:

SELECT title
FROM post
ORDER BY created_on DESC
OFFSET 50 ROWS
FETCH NEXT 50 ROWS ONLY

जो Oracle 12, SQL Server 2012, या PostgreSQL 8.4 या नए संस्करणों पर काम करता है।

MySQL के लिए, आप LIMIT और OFFSET क्लॉज का उपयोग कर सकते हैं:

SELECT title
FROM post
ORDER BY created_on DESC
LIMIT 50
OFFSET 50

SQL-स्तर पृष्ठांकन का उपयोग करने का लाभ यह है कि डेटाबेस निष्पादन योजना इस जानकारी का उपयोग कर सकती है।

इसलिए, यदि हमारे पास created_on . पर एक अनुक्रमणिका है कॉलम:

CREATE INDEX idx_post_created_on ON post (created_on DESC)

और हम निम्नलिखित क्वेरी को निष्पादित करते हैं जो LIMIT . का उपयोग करती है खंड:

EXPLAIN ANALYZE
SELECT title
FROM post
ORDER BY created_on DESC
LIMIT 50

हम देख सकते हैं कि डेटाबेस इंजन इंडेक्स का उपयोग करता है क्योंकि ऑप्टिमाइज़र जानता है कि केवल 50 रिकॉर्ड प्राप्त किए जाने हैं:

Execution plan:
Limit  (cost=0.28..25.35 rows=50 width=564)
       (actual time=0.038..0.051 rows=50 loops=1)
  ->  Index Scan using idx_post_created_on on post p  
      (cost=0.28..260.04 rows=518 width=564) 
      (actual time=0.037..0.049 rows=50 loops=1)
Planning time: 1.511 ms
Execution time: 0.148 ms

JDBC स्टेटमेंट अधिकतम पंक्तियाँ

setMaxRows जावाडोक :

यह बहुत आश्वस्त करने वाली बात नहीं है!

इसलिए, यदि हम PostgreSQL पर निम्न क्वेरी निष्पादित करते हैं:

try (PreparedStatement statement = connection
    .prepareStatement("""
        SELECT title
        FROM post
        ORDER BY created_on DESC
    """)
) {
    statement.setMaxRows(50);
    ResultSet resultSet = statement.executeQuery();
    int count = 0;
    while (resultSet.next()) {
        String title = resultSet.getString(1);
        count++;
    }
}

हमें PostgreSQL लॉग में निम्नलिखित निष्पादन योजना मिलती है:

Execution plan:
  Sort  (cost=65.53..66.83 rows=518 width=564) 
        (actual time=4.339..5.473 rows=5000 loops=1)
  Sort Key: created_on DESC
  Sort Method: quicksort  Memory: 896kB
  ->  Seq Scan on post p  (cost=0.00..42.18 rows=518 width=564) 
                          (actual time=0.041..1.833 rows=5000 loops=1)
Planning time: 1.840 ms
Execution time: 6.611 ms 

क्योंकि डेटाबेस ऑप्टिमाइज़र को पता नहीं है कि हमें केवल 50 रिकॉर्ड लाने की आवश्यकता है, यह मानता है कि सभी 5000 पंक्तियों को स्कैन करने की आवश्यकता है। यदि किसी क्वेरी को बड़ी संख्या में रिकॉर्ड प्राप्त करने की आवश्यकता है, तो एक पूर्ण-तालिका स्कैन की लागत वास्तव में एक इंडेक्स का उपयोग करने की तुलना में कम है, इसलिए निष्पादन योजना इंडेक्स का बिल्कुल भी उपयोग नहीं करेगी।

निष्कर्ष

हालांकि यह setMaxRows जैसा दिखता है ResultSet . के आकार को सीमित करने के लिए पोर्टेबल समाधान है , यदि डेटाबेस सर्वर अनुकूलक JDBC maxRows का उपयोग नहीं करता है, तो SQL-स्तरीय पृष्ठांकन अधिक कुशल है संपत्ति।