क्वेरी प्लान से शुरू करें, फिर सबसे बड़ी लागत को ठीक करें। EXPLAIN/ का उपयोग करें यह देखने के लिए कि डेटाबेस वास्तव में क्या करता है, सही जोड़ें, क्वेरी को समाप्त करें, और केवल जिन डेटा की आवश्यकता है उसे चुनें।
क्वेरी प्लान से शुरू करें, फिर सबसे बड़ी लागत को ठीक करें। EXPLAIN/ का उपयोग करें यह देखने के लिए कि डेटाबेस वास्तव में क्या करता है, सही जोड़ें, क्वेरी को समाप्त करें, और केवल जिन डेटा की आवश्यकता है उसे चुनें।
EXPLAIN ANALYZEEXPLAIN ANALYZE execution plan और वास्तविक timings दिखाता है। एक बड़ी टेबल पर Seq Scan क्लासिक चेतावनी संकेत है:
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42;
-- Seq Scan on orders (cost=0.00..18500 rows=120)
-- Filter: (customer_id = 42)
-- rows removed by filter: 999880 ← scanned the whole table!
एक index पूर्ण स्कैन को तेजी से लुकअप में बदल देता है:
CREATE INDEX idx_orders_customer ON orders (customer_id);
-- Now: Index Scan using idx_orders_customer (cost=0.42..8.5 rows=120)
-- 1,000,000-row scan → ~120-row lookup
Indexes का लेखन पर लागत होता है: हर INSERT/UPDATE को index को भी अपडेट करना होता है, इसलिए उन columns को index करें जिन पर आप filter/join/sort करते हैं — हर column को नहीं। एक composite index (customer_id, created_at) एक संरचना में WHERE customer_id = ? ORDER BY created_at को serve करता है।
N+1 समस्या — एक सूची के लिए एक क्वेरी, फिर हर row के लिए एक — धीमापन का मुख्य कारण है। इसे eager loading, JOIN, या batched IN (...) से बदलें:
-- N+1: 1 + 100 queries
SELECT * FROM orders; -- then per order: SELECT * FROM users WHERE id = ?
-- Fixed: one JOIN, only needed columns
SELECT o.id, o.total, u.name
FROM orders o JOIN users u ON u.id = o.user_id;
अलावा केवल आवश्यक columns चुनें (avoid SELECT *) और paginate करें LIMIT/keyset pagination से ताकि आप कभी लाखों rows को लोड न करें।
डेटाबेस सबसे आम bottleneck है। प्लान को पढ़ना आपको बताता है कि क्वेरी धीमी क्यों है अनुमान लगाने के बजाय; सही index, N+1 को हटाना, और result set को trim करना नियमित रूप से second-long queries को millisecond वाली में बदल देता है — hardware को scale किए बिना।