EXPLAIN ਉਹ plan ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ optimizer ਨੇ ਚੁਣਿਆ — ਇਹ ਹਰ table ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚੇਗਾ — query ਚਲਾਏ ਬਿਨਾਂ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਪੜ੍ਹਦੇ ਹੋ ਕਿ indexes ਵਰਤੇ ਜਾ ਰਹੇ ਹਨ ਅਤੇ ਥੋੜ੍ਹੀਆਂ rows ਦੀ ਜਾਂਚ ਹੋ ਰਹੀ ਹੈ।
EXPLAIN ਉਹ plan ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ optimizer ਨੇ ਚੁਣਿਆ — ਇਹ ਹਰ table ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚੇਗਾ — query ਚਲਾਏ ਬਿਨਾਂ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਪੜ੍ਹਦੇ ਹੋ ਕਿ indexes ਵਰਤੇ ਜਾ ਰਹੇ ਹਨ ਅਤੇ ਥੋੜ੍ਹੀਆਂ rows ਦੀ ਜਾਂਚ ਹੋ ਰਹੀ ਹੈ।
const / eq_ref / ref (index lookups, ਚੰਗਾ) → range → index (full index scan) → ALL (full table scan, ਖ਼ਤਰੇ ਦਾ ਝੰਡਾ)।NULL = ਕੋਈ ਨਹੀਂ)।Using index (covering, ਬਹੁਤ ਵਧੀਆ), Using filesort / Using temporary (memory ਵਿੱਚ ਜਾਂ disk ਉੱਤੇ sorting/grouping — ਅਕਸਰ optimize ਹੋ ਸਕਦਾ ਹੈ)।EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- scans everything, sorts
-- +------+------+------+---------+--------+----------------+
-- Add an index that covers the filter AND the sort order:
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- seeks 30 rows, no filesort
index ਨੇ 900k rows ਦੇ ਇੱਕ ALL scan ਨੂੰ 30 ਦੇ ਇੱਕ ref seek ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਅਤੇ ਕਿਉਂਕਿ created_at ਦੂਜਾ column ਹੈ, rows ਪਹਿਲਾਂ ਤੋਂ ਹੀ sorted ਬਾਹਰ ਆਉਂਦੀਆਂ ਹਨ — filesort ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਸਲ timing ਅਤੇ row counts ਵੀ ਦੇਖਣ ਲਈ EXPLAIN ANALYZE (MySQL 8) ਵਰਤੋ, ਜੋ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਫੜਦਾ ਹੈ ਜਿੱਥੇ ਅਨੁਮਾਨ ਗ਼ਲਤ ਹੁੰਦਾ ਹੈ।
EXPLAIN ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਸਬੂਤ ਲੈ ਆਉਂਦੇ ਹੋ। type: ALL, ਇੱਕ ਵਿਸ਼ਾਲ rows, ਜਾਂ Using filesort ਨੂੰ ਪਛਾਣਨਾ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦੱਸ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ index ਕਿੱਥੇ ਗ਼ਾਇਬ ਹੈ — "page ਹੌਲੀ ਹੈ" ਤੋਂ ਇੱਕ ਟੀਚੇ ਵਾਲੇ ਹੱਲ ਤੱਕ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ