ಪುಟದ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ OFFSET ಮತ್ತು LIMIT ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ

ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಬಗ್ಗೆ ನೀವು ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲದ ದಿನಗಳು ಹೋಗಿವೆ. ಸಮಯ ಇನ್ನೂ ನಿಲ್ಲುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಬ್ಬ ಹೊಸ ಟೆಕ್ ಉದ್ಯಮಿಗಳು ತಮ್ಮ ಕೈಗೆ ಸಿಗುವ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ, ಮುಂದಿನ Facebook ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತಾರೆ. ವ್ಯಾಪಾರಗಳಿಗೆ ಹಣ ಗಳಿಸಲು ಸಹಾಯ ಮಾಡುವ ಉತ್ತಮ ತರಬೇತಿ ಮಾದರಿಗಳಿಗೆ ಈ ಡೇಟಾದ ಅಗತ್ಯವಿದೆ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು 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 ಎಂಎಸ್).

ಮತ್ತು ಹೆಚ್ಚಿನ ಡೇಟಾ ಇದ್ದರೆ, ಎಲ್ಲವೂ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ ಕಾಣುತ್ತದೆ (ಇದನ್ನು ಮನವರಿಕೆ ಮಾಡಲು, ನನ್ನದನ್ನು ನೋಡೋಣ ಉದಾಹರಣೆ 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