ជៀសវាងការប្រើ OFFSET និង LIMIT នៅក្នុងសំណួរដែលបានបិទភ្ជាប់

កន្លងផុតទៅគឺជាថ្ងៃដែលអ្នកមិនចាំបាច់ព្រួយបារម្ភអំពីការបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការមូលដ្ឋានទិន្នន័យ។ ពេលវេលាមិននៅស្ងៀមទេ។ សហគ្រិនបច្ចេកវិទ្យាថ្មីគ្រប់រូបចង់បង្កើត Facebook បន្ទាប់ ខណៈពេលដែលព្យាយាមប្រមូលទិន្នន័យទាំងអស់ដែលពួកគេអាចទទួលបាន។ អាជីវកម្មត្រូវការទិន្នន័យនេះ ដើម្បីបណ្តុះបណ្តាលគំរូកាន់តែប្រសើរ ដែលជួយពួកគេរកប្រាក់។ ក្នុងលក្ខខណ្ឌបែបនេះ អ្នកសរសេរកម្មវិធីត្រូវបង្កើត APIs ដែលអនុញ្ញាតឱ្យពួកគេធ្វើការយ៉ាងឆាប់រហ័ស និងអាចទុកចិត្តបានជាមួយនឹងព័ត៌មានដ៏ធំ។

ប្រសិនបើអ្នកបានរចនាកម្មវិធី ឬផ្នែកខាងក្រោយនៃមូលដ្ឋានទិន្នន័យសម្រាប់រយៈពេលណាមួយ អ្នកប្រហែលជាបានសរសេរកូដដើម្បីដំណើរការសំណួរដែលបានបិទភ្ជាប់។ ឧទាហរណ៍ដូចនេះ៖

SELECT * FROM table_name LIMIT 10 OFFSET 40

របៀបដែលវា?

ប៉ុន្តែប្រសិនបើនេះជារបៀបដែលអ្នកបានធ្វើ pagination របស់អ្នក ខ្ញុំសុំទោសដែលនិយាយថាអ្នកមិនបានធ្វើវាតាមរបៀបដែលមានប្រសិទ្ធភាពបំផុត។

តើអ្នកចង់ជំទាស់នឹងខ្ញុំទេ? អ្នក​អាច មិនមាន ចំណាយ время. slack, Shopify и Mixmax ពួកគេកំពុងប្រើបច្ចេកទេសដែលខ្ញុំចង់និយាយនៅថ្ងៃនេះរួចហើយ។

ដាក់ឈ្មោះអ្នកអភិវឌ្ឍន៍ផ្នែកខាងក្រោយយ៉ាងហោចណាស់ម្នាក់ដែលមិនធ្លាប់ប្រើ OFFSET и LIMIT ដើម្បីអនុវត្តសំណួរ paginated ។ នៅក្នុង MVP (ផលិតផលដែលអាចដំណើរការបានអប្បបរមា) និងនៅក្នុងគម្រោងដែលទិន្នន័យចំនួនតូចត្រូវបានប្រើប្រាស់ វិធីសាស្រ្តនេះគឺអាចអនុវត្តបាន។ វា "គ្រាន់តែដំណើរការ" ដូច្នេះដើម្បីនិយាយ។

ប៉ុន្តែប្រសិនបើអ្នកត្រូវការបង្កើតប្រព័ន្ធដែលអាចទុកចិត្តបាន និងមានប្រសិទ្ធភាពតាំងពីដំបូង អ្នកគួរតែយកចិត្តទុកដាក់ជាមុនអំពីប្រសិទ្ធភាពនៃការសាកសួរមូលដ្ឋានទិន្នន័យដែលប្រើក្នុងប្រព័ន្ធបែបនេះ។

ថ្ងៃនេះយើងនឹងនិយាយអំពីបញ្ហាជាមួយនឹងការអនុវត្តដែលប្រើជាទូទៅ (អាក្រក់ពេក) នៃម៉ាស៊ីនសំណួរដែលបានបិទភ្ជាប់ និងរបៀបដើម្បីសម្រេចបាននូវប្រសិទ្ធភាពខ្ពស់នៅពេលប្រតិបត្តិសំណួរបែបនេះ។

តើ OFFSET និង LIMIT មានបញ្ហាអ្វី?

ដូចដែលបាននិយាយរួចមកហើយ, OFFSET и LIMIT ពួកគេអនុវត្តបានល្អនៅក្នុងគម្រោងដែលមិនចាំបាច់ធ្វើការជាមួយទិន្នន័យធំ។

បញ្ហាកើតឡើងនៅពេលដែលមូលដ្ឋានទិន្នន័យកើនឡើងដល់ទំហំដែលវាលែងសមនឹងអង្គចងចាំរបស់ម៉ាស៊ីនមេទៀតហើយ។ ទោះយ៉ាងណាក៏ដោយ នៅពេលធ្វើការជាមួយមូលដ្ឋានទិន្នន័យនេះ អ្នកត្រូវប្រើសំណួរ paginated ។

ដើម្បីឱ្យបញ្ហានេះបង្ហាញឱ្យឃើញដោយខ្លួនឯង ត្រូវតែមានស្ថានភាពដែល 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