ਕਿਊਰੀ ਯੋਜਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੀ ਕੀਮਤ ਨੂੰ ਠੀਕ ਕਰੋ। EXPLAIN/ ਦੀ ਵਰਤੋਂ ਕਰੋ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਡੇਟਾਬੇਸ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ, ਸਹੀ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਊਰੀਜ਼ ਨੂੰ ਖਤਮ ਕਰੋ, ਅਤੇ ਸਿਰਫ ਉਹ ਡੇਟਾ ਚੁਣੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ।
ਕਿਊਰੀ ਯੋਜਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੀ ਕੀਮਤ ਨੂੰ ਠੀਕ ਕਰੋ। EXPLAIN/ ਦੀ ਵਰਤੋਂ ਕਰੋ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਡੇਟਾਬੇਸ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ, ਸਹੀ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਊਰੀਜ਼ ਨੂੰ ਖਤਮ ਕਰੋ, ਅਤੇ ਸਿਰਫ ਉਹ ਡੇਟਾ ਚੁਣੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ।
EXPLAIN ANALYZEEXPLAIN ANALYZE ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਅਤੇ ਅਸਲ ਸਮੇਂ ਦੀ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਇੱਕ ਵੱਡੀ ਟੇਬਲ ਉੱਪਰ 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 ਦਾ writes ਉੱਪਰ ਖਰਚ ਹੁੰਦਾ ਹੈ: ਹਰੇਕ INSERT/UPDATE ਨੂੰ index ਨੂੰ ਵੀ ਅੱਪਡੇਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਕਾਲਮਾਂ ਉੱਪਰ index ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ filter/join/sort ਕਰਦੇ ਹੋ — ਹਰੇਕ ਕਾਲਮ ਨਹੀਂ। ਇੱਕ composite index (customer_id, created_at) WHERE customer_id = ? ORDER BY created_at ਨੂੰ ਇੱਕ ਢਾਂਚੇ ਵਿੱਚ ਪੂਰਾ ਕਰਦਾ ਹੈ।
N+1 ਮਸਲਾ — ਇੱਕ ਸੂਚੀ ਲਈ ਇੱਕ ਕਿਊਰੀ, ਫਿਰ ਹਰੇਕ ਤਾਲਮੇਲ ਦੇ ਲਈ ਇੱਕ — ਮਹੌ ਦਾ ਇੱਕ ਸਿਖਰ ਕਾਰਨ ਹੈ। ਇਸ ਨੂੰ 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;
ਸਾਥ ਹੀ ਸਿਰਫ ਲੋੜੀਂਦੇ ਕਾਲਮ ਚੁਣੋ (avoid SELECT *) ਅਤੇ paginate LIMIT/keyset pagination ਨਾਲ ਕਰੋ ਇਸ ਲਈ ਤੁਸੀਂ ਕਦੇ ਲੱਖਾਂ ਰੋ ਲੋਡ ਨਹੀਂ ਕਰਦੇ।
ਡੇਟਾਬੇਸ ਸਭ ਤੋਂ ਆਮ ਰੁਕਾਵਟ ਹੈ। ਪਲਾਨ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿਉਂ ਇੱਕ ਕਿਊਰੀ ਸਮ ਹੈ ਬਜਾਏ ਅਨੁਮਾਨ ਦੇ; ਸਹੀ index, N+1 ਨੂੰ ਹਟਾਉਣਾ, ਅਤੇ ਨਤੀਜਾ ਸੈਟ ਨੂੰ ਕੱਟਣਾ ਨਿਯਮਿਤ ਤੌਰ ਤੇ ਸਕਿੰਟਾਂ ਵਾਲੀਆਂ ਕਿਊਰੀਜ਼ ਨੂੰ ਮਿਲੀਸਕਿੰਟਾਂ ਵਾਲੀਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ — ਹਾਰਡਵੇਅਰ ਨੂੰ ਸਕੇਲ ਕੀਤੇ ਬਿਨਾ।