ਪੰਨਾਬੱਧ ਕੀਤੇ ਸਵਾਲਾਂ ਵਿੱਚ OFFSET ਅਤੇ LIMIT ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਚੋ

ਉਹ ਦਿਨ ਚਲੇ ਗਏ ਜਦੋਂ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਸਮਾਂ ਸਥਿਰ ਨਹੀਂ ਰਹਿੰਦਾ। ਹਰ ਨਵਾਂ ਤਕਨੀਕੀ ਉੱਦਮੀ ਅਗਲਾ ਫੇਸਬੁੱਕ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਹ ਸਾਰਾ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਉਹ ਆਪਣੇ ਹੱਥਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ। ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਬਿਹਤਰ ਸਿਖਲਾਈ ਮਾਡਲਾਂ ਲਈ ਇਸ ਡੇਟਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਪੈਸਾ ਕਮਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ API ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਡਾਟਾਬੇਸ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਪੰਨਾ-ਸ਼ੁਦਾ ਸਵਾਲਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕੋਡ ਲਿਖਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ:

SELECT * FROM table_name LIMIT 10 OFFSET 40

ਜਿਸ ਤਰ੍ਹਾਂ ਇਹ ਹੈ?

ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਆਪਣਾ ਪੰਨਾ ਅੰਕ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਮੈਨੂੰ ਇਹ ਕਹਿਣ ਵਿੱਚ ਅਫ਼ਸੋਸ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵੀ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਕੀਤਾ।

ਕੀ ਤੁਸੀਂ ਮੇਰੇ 'ਤੇ ਇਤਰਾਜ਼ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਤੁਸੀਂ ਕਰ ਸੱਕਦੇ ਹੋ ਨਾ ਖਰਚ время. ਢਿੱਲ, Shopify и ਮਿਕਸਮੈਕਸ ਉਹ ਪਹਿਲਾਂ ਹੀ ਉਹ ਤਕਨੀਕਾਂ ਵਰਤ ਰਹੇ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਅੱਜ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ.

ਘੱਟੋ-ਘੱਟ ਇੱਕ ਬੈਕਐਂਡ ਡਿਵੈਲਪਰ ਦਾ ਨਾਮ ਦਿਓ ਜਿਸ ਨੇ ਕਦੇ ਨਹੀਂ ਵਰਤਿਆ ਹੈ OFFSET и LIMIT ਪੰਨਾਬੱਧ ਸਵਾਲ ਕਰਨ ਲਈ. MVP (ਘੱਟੋ-ਘੱਟ ਵਿਹਾਰਕ ਉਤਪਾਦ) ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਜਿੱਥੇ ਘੱਟ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਪਹੁੰਚ ਕਾਫ਼ੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਇਹ "ਸਿਰਫ਼ ਕੰਮ ਕਰਦਾ ਹੈ", ਇਸ ਲਈ ਬੋਲਣ ਲਈ.

ਪਰ ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਕਰੈਚ ਤੋਂ ਭਰੋਸੇਯੋਗ ਅਤੇ ਕੁਸ਼ਲ ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਡੇਟਾਬੇਸ ਦੀ ਪੁੱਛਗਿੱਛ ਦੀ ਕੁਸ਼ਲਤਾ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅੱਜ ਅਸੀਂ ਪੰਨਾਬੱਧ ਪੁੱਛਗਿੱਛ ਇੰਜਣਾਂ ਦੇ ਆਮ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ (ਬਹੁਤ ਮਾੜੇ) ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਅਤੇ ਅਜਿਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਲਾਉਣ ਵੇਲੇ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ।

OFFSET ਅਤੇ LIMIT ਵਿੱਚ ਕੀ ਗਲਤ ਹੈ?

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਗਿਆ ਹੈ, OFFSET и LIMIT ਉਹ ਉਹਨਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

ਸਮੱਸਿਆ ਉਦੋਂ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਅਜਿਹੇ ਆਕਾਰ ਵਿੱਚ ਵਧਦਾ ਹੈ ਕਿ ਇਹ ਸਰਵਰ ਦੀ ਮੈਮੋਰੀ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਹਾਲਾਂਕਿ, ਇਸ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਪੰਨਾਬੱਧ ਸਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ.

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਗਟ ਕਰਨ ਲਈ, ਅਜਿਹੀ ਸਥਿਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਵਿੱਚ DBMS ਹਰੇਕ ਪੰਨੇ ਵਾਲੀ ਪੁੱਛਗਿੱਛ 'ਤੇ ਇੱਕ ਅਕੁਸ਼ਲ ਫੁੱਲ ਟੇਬਲ ਸਕੈਨ ਓਪਰੇਸ਼ਨ ਦਾ ਸਹਾਰਾ ਲੈਂਦੀ ਹੈ (ਜਦੋਂ ਕਿ ਸੰਮਿਲਨ ਅਤੇ ਮਿਟਾਉਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਸਾਨੂੰ ਪੁਰਾਣੇ ਡੇਟਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ!)

"ਫੁੱਲ ਟੇਬਲ ਸਕੈਨ" (ਜਾਂ "ਕ੍ਰਮਵਾਰ ਟੇਬਲ ਸਕੈਨ", ਕ੍ਰਮਵਾਰ ਸਕੈਨ) ਕੀ ਹੈ? ਇਹ ਇੱਕ ਓਪਰੇਸ਼ਨ ਹੈ ਜਿਸ ਦੌਰਾਨ DBMS ਕ੍ਰਮਵਾਰ ਸਾਰਣੀ ਦੀ ਹਰੇਕ ਕਤਾਰ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਯਾਨੀ ਇਸ ਵਿੱਚ ਮੌਜੂਦ ਡੇਟਾ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦਿੱਤੀ ਗਈ ਸ਼ਰਤ ਦੀ ਪਾਲਣਾ ਲਈ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਇਸ ਕਿਸਮ ਦਾ ਟੇਬਲ ਸਕੈਨ ਸਭ ਤੋਂ ਹੌਲੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਇਸਨੂੰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਇੰਪੁੱਟ/ਆਊਟਪੁੱਟ ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਸਰਵਰ ਦੇ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ। ਡਿਸਕਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਨਾਲ ਜੁੜੀ ਲੇਟੈਂਸੀ ਦੁਆਰਾ ਸਥਿਤੀ ਨੂੰ ਹੋਰ ਬਦਤਰ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਅਤੇ ਇਹ ਤੱਥ ਕਿ ਡਿਸਕ ਤੋਂ ਮੈਮੋਰੀ ਵਿੱਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਇੱਕ ਸਰੋਤ-ਸੰਬੰਧਿਤ ਕਾਰਜ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ 100000000 ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਰਿਕਾਰਡ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਸਾਰੀ ਦੇ ਨਾਲ ਇੱਕ ਪੁੱਛਗਿੱਛ ਚਲਾਉਂਦੇ ਹੋ OFFSET 50000000. ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ DBMS ਨੂੰ ਇਹ ਸਾਰੇ ਰਿਕਾਰਡ ਲੋਡ ਕਰਨੇ ਪੈਣਗੇ (ਅਤੇ ਸਾਨੂੰ ਇਹਨਾਂ ਦੀ ਲੋੜ ਵੀ ਨਹੀਂ ਹੈ!), ਉਹਨਾਂ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਣਾ ਹੋਵੇਗਾ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਲਓ, ਕਹੋ, 20 ਨਤੀਜੇ ਰਿਪੋਰਟ ਕੀਤੇ ਗਏ ਹਨ। LIMIT.

ਮੰਨ ਲਓ ਕਿ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ: "50000 ਤੋਂ 50020 ਤੋਂ 100000 ਤੱਕ ਕਤਾਰਾਂ ਦੀ ਚੋਣ ਕਰੋ"। ਭਾਵ, ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਗਿੱਛ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਪਹਿਲਾਂ 50000 ਕਤਾਰਾਂ ਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਕੀ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਉਸ ਨੂੰ ਕਿੰਨਾ ਬੇਲੋੜਾ ਕੰਮ ਕਰਨਾ ਪਏਗਾ?

ਜੇਕਰ ਤੁਸੀਂ ਮੇਰੇ 'ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਉਸ ਉਦਾਹਰਣ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੋ ਜੋ ਮੈਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਈ ਹੈ db-fiddle.com. 

db-fiddle.com 'ਤੇ ਉਦਾਹਰਨ

ਉਥੇ, ਖੱਬੇ ਪਾਸੇ, ਖੇਤ ਵਿਚ Schema SQL, ਇੱਕ ਕੋਡ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਵਿੱਚ 100000 ਕਤਾਰਾਂ ਨੂੰ ਸੰਮਿਲਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੱਜੇ ਪਾਸੇ, ਖੇਤਰ ਵਿੱਚ Query SQL, ਦੋ ਸਵਾਲ ਦਿਖਾਏ ਗਏ ਹਨ। ਪਹਿਲਾ, ਹੌਲੀ, ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;

ਅਤੇ ਦੂਜਾ, ਜੋ ਕਿ ਉਸੇ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੱਲ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;

ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਬੱਸ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰੋ Run ਪੰਨੇ ਦੇ ਸਿਖਰ 'ਤੇ। ਅਜਿਹਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਪੁੱਛਗਿੱਛ ਦੇ ਚੱਲਣ ਦੇ ਸਮੇਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇੱਕ ਬੇਅਸਰ ਪੁੱਛਗਿੱਛ ਨੂੰ ਚਲਾਉਣ ਵਿੱਚ ਦੂਜੀ ਨੂੰ ਚਲਾਉਣ ਨਾਲੋਂ ਘੱਟ ਤੋਂ ਘੱਟ 30 ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ (ਇਹ ਸਮਾਂ ਰਨ ਤੋਂ ਰਨ ਤੱਕ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ; ਉਦਾਹਰਨ ਲਈ, ਸਿਸਟਮ ਇਹ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਪਹਿਲੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ 37 ms ਦਾ ਸਮਾਂ ਲੱਗਾ, ਪਰ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਦੂਜਾ - 1 ms).

ਅਤੇ ਜੇ ਵਧੇਰੇ ਡੇਟਾ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਹੋਰ ਵੀ ਮਾੜਾ ਦਿਖਾਈ ਦੇਵੇਗਾ (ਇਸ ਬਾਰੇ ਯਕੀਨ ਦਿਵਾਉਣ ਲਈ, ਮੇਰੇ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੋ ਉਦਾਹਰਨ 10 ਮਿਲੀਅਨ ਕਤਾਰਾਂ ਦੇ ਨਾਲ)।

ਜੋ ਅਸੀਂ ਹੁਣੇ ਚਰਚਾ ਕੀਤੀ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਸਮਝ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਮੁੱਲ ਜਿੰਨਾ ਉੱਚਾ ਹੋਵੇਗਾ OFFSET - ਬੇਨਤੀ ਨੂੰ ਪੂਰਾ ਹੋਣ ਵਿੱਚ ਜਿੰਨਾ ਸਮਾਂ ਲੱਗੇਗਾ।

OFFSET ਅਤੇ LIMIT ਦੇ ਸੁਮੇਲ ਦੀ ਬਜਾਏ ਮੈਨੂੰ ਕੀ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?

ਇੱਕ ਸੁਮੇਲ ਦੀ ਬਜਾਏ OFFSET и LIMIT ਇਹ ਹੇਠ ਲਿਖੀ ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਬਣਾਏ ਗਏ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਹੈ:

SELECT * FROM table_name WHERE id > 10 LIMIT 20

ਇਹ ਕਰਸਰ ਅਧਾਰਤ ਪੰਨਾ ਨੰਬਰ ਦੇ ਨਾਲ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਹੈ।

ਮੌਜੂਦਾ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਨ ਦੀ ਬਜਾਏ OFFSET и LIMIT ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਪ੍ਰਸਾਰਿਤ ਕਰੋ, ਤੁਹਾਨੂੰ ਆਖਰੀ ਪ੍ਰਾਪਤ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੈ ID) ਅਤੇ LIMIT, ਨਤੀਜੇ ਵਜੋਂ, ਉਪਰੋਕਤ ਸਮਾਨ ਸਵਾਲਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਕਿਉਂ? ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਪੜ੍ਹੀ ਗਈ ਆਖਰੀ ਕਤਾਰ ਦੇ ਪਛਾਣਕਰਤਾ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਸ਼ਚਿਤ ਕਰਕੇ, ਤੁਸੀਂ ਆਪਣੇ DBMS ਨੂੰ ਦੱਸਦੇ ਹੋ ਕਿ ਇਸ ਨੂੰ ਲੋੜੀਂਦੇ ਡੇਟਾ ਦੀ ਖੋਜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਖੋਜ, ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਲਈ ਧੰਨਵਾਦ, ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੀਤੀ ਜਾਏਗੀ; ਸਿਸਟਮ ਨੂੰ ਨਿਰਧਾਰਤ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਦੀਆਂ ਲਾਈਨਾਂ ਦੁਆਰਾ ਵਿਚਲਿਤ ਨਹੀਂ ਹੋਣਾ ਪਏਗਾ.

ਆਉ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦੀ ਹੇਠ ਦਿੱਤੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਤੁਲਨਾ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ। ਇੱਥੇ ਇੱਕ ਬੇਅਸਰ ਪੁੱਛਗਿੱਛ ਹੈ।

ਹੌਲੀ ਬੇਨਤੀ

ਅਤੇ ਇੱਥੇ ਇਸ ਬੇਨਤੀ ਦਾ ਇੱਕ ਅਨੁਕੂਲਿਤ ਸੰਸਕਰਣ ਹੈ।

ਤੁਰੰਤ ਬੇਨਤੀ

ਦੋਵੇਂ ਪੁੱਛਗਿੱਛਾਂ ਬਿਲਕੁਲ ਉਸੇ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ। ਪਰ ਪਹਿਲੇ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ 12,80 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਦੂਜੇ ਨੂੰ 0,01 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। ਕੀ ਤੁਸੀਂ ਫਰਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ?

ਸੰਭਵ ਸਮੱਸਿਆਵਾਂ

ਪ੍ਰਸਤਾਵਿਤ ਪੁੱਛਗਿੱਛ ਵਿਧੀ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਸਾਰਣੀ ਵਿੱਚ ਇੱਕ ਕਾਲਮ (ਜਾਂ ਕਾਲਮ) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਿਲੱਖਣ, ਕ੍ਰਮਵਾਰ ਸੂਚਕਾਂਕ ਸ਼ਾਮਲ ਹੋਣ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਪੂਰਨ ਅੰਕ ਪਛਾਣਕਰਤਾ। ਕੁਝ ਖਾਸ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਡਾਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਗਤੀ ਨੂੰ ਵਧਾਉਣ ਲਈ ਅਜਿਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਫਲਤਾ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ।

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਵਾਲਾਂ ਦਾ ਨਿਰਮਾਣ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਟੇਬਲਾਂ ਦੇ ਖਾਸ ਢਾਂਚੇ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਵਿਧੀਆਂ ਦੀ ਚੋਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਮੌਜੂਦਾ ਟੇਬਲਾਂ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਨਗੇ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਨੂੰ ਸੰਬੰਧਿਤ ਡੇਟਾ ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਦੇ ਨਾਲ ਸਵਾਲਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਦਿਲਚਸਪ ਲੱਗ ਸਕਦਾ ਹੈ ਇਹ ਲੇਖ।

ਜੇ ਸਾਨੂੰ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦੇ ਗੁੰਮ ਹੋਣ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਜੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਸਾਰੇ-ਤੋਂ-ਬਹੁਤ ਸਬੰਧਾਂ ਵਾਲਾ ਇੱਕ ਸਾਰਣੀ ਹੈ, ਤਾਂ ਵਰਤਣ ਦੀ ਰਵਾਇਤੀ ਪਹੁੰਚ OFFSET и LIMIT, ਸਾਡੇ ਅਨੁਕੂਲ ਹੋਣ ਦੀ ਗਰੰਟੀ ਹੈ। ਪਰ ਇਸਦੀ ਵਰਤੋਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਹੌਲੀ ਪੁੱਛਗਿੱਛ ਹੋ ਸਕਦੀ ਹੈ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਸਵੈ-ਵਧਾਉਣ ਵਾਲੀ ਪ੍ਰਾਇਮਰੀ ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਾਂਗਾ, ਭਾਵੇਂ ਇਹ ਸਿਰਫ਼ ਪੰਨਾਬੱਧ ਸਵਾਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਲੋੜੀਂਦਾ ਹੋਵੇ।

ਜੇ ਤੁਸੀਂ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ - ਦੇਖ!, ਦੇਖ! и ਦੇਖ! - ਕਈ ਲਾਭਦਾਇਕ ਸਮੱਗਰੀ.

ਨਤੀਜੇ

ਮੁੱਖ ਸਿੱਟਾ ਜੋ ਅਸੀਂ ਕੱਢ ਸਕਦੇ ਹਾਂ ਉਹ ਇਹ ਹੈ ਕਿ, ਭਾਵੇਂ ਅਸੀਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਡੇਟਾਬੇਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਪੁੱਛਗਿੱਛ ਦੇ ਅਮਲ ਦੀ ਗਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਹਮੇਸ਼ਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ। ਅੱਜਕੱਲ੍ਹ, ਹੱਲਾਂ ਦੀ ਮਾਪਯੋਗਤਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਜੇਕਰ ਕਿਸੇ ਖਾਸ ਸਿਸਟਮ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਹੀ ਸਭ ਕੁਝ ਸਹੀ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ, ਭਵਿੱਖ ਵਿੱਚ, ਡਿਵੈਲਪਰ ਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾ ਸਕਦਾ ਹੈ.

ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਸਵਾਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਅਨੁਕੂਲਿਤ ਕਿਵੇਂ ਕਰਦੇ ਹੋ?

ਸਰੋਤ: www.habr.com