អ្វី​ដែល​ការ​ពន្យល់​គឺ​ស្ងាត់​អំពី​និង​របៀប​ឱ្យ​វា​និយាយ​

សំណួរបុរាណដែលអ្នកអភិវឌ្ឍន៍នាំយកទៅ DBA របស់គាត់ឬម្ចាស់អាជីវកម្មនាំយកទៅឱ្យអ្នកប្រឹក្សា PostgreSQL ស្ទើរតែតែងតែស្តាប់ទៅដូចគ្នា: "ហេតុអ្វីបានជាសំណើចំណាយពេលយូរដើម្បីបំពេញលើមូលដ្ឋានទិន្នន័យ?"

សំណុំប្រពៃណីនៃហេតុផល:

• ក្បួនដោះស្រាយមិនមានប្រសិទ្ធភាព
  នៅពេលអ្នកសម្រេចចិត្តចូលរួម CTEs ជាច្រើនលើកំណត់ត្រាពីរបីម៉ឺន
• ស្ថិតិមិនពាក់ព័ន្ធ
  ប្រសិនបើការចែកចាយទិន្នន័យពិតប្រាកដនៅក្នុងតារាងគឺខុសគ្នាខ្លាំងរួចទៅហើយពីការប្រមូលដោយ ANALYZE កាលពីលើកមុន។
• "ដោត" លើធនធាន
  ហើយមិនមានថាមពលកុំព្យូទ័រជាក់លាក់គ្រប់គ្រាន់នៃស៊ីភីយូទៀតទេ អង្គចងចាំជីហ្គាបៃត្រូវបានបូមឥតឈប់ឈរ ឬថាសមិនអាចរក្សា "ការចង់បាន" ទាំងអស់នៃមូលដ្ឋានទិន្នន័យបានទេ។
• ការទប់ស្កាត់ ពីដំណើរការប្រកួតប្រជែង

ហើយប្រសិនបើការទប់ស្កាត់ពិបាកចាប់ និងវិភាគ នោះអ្វីៗផ្សេងទៀតដែលយើងត្រូវការ ផែនការសំណួរដែលអាចទទួលបានដោយប្រើ ពន្យល់ប្រតិបត្តិករ (វាជាការប្រសើរក្នុងការពន្យល់ភ្លាមៗ (វិភាគ, បណ្តុំ) ...) ឬ ម៉ូឌុល auto_explain.

ប៉ុន្តែ​ដូច​មាន​ចែង​ក្នុង​ឯកសារ​ដដែល។

"ការយល់ដឹងអំពីផែនការគឺជាសិល្បៈមួយ ហើយដើម្បីធ្វើជាម្ចាស់វាទាមទារនូវបទពិសោធន៍ជាក់លាក់មួយ ... "

ប៉ុន្តែអ្នកអាចធ្វើបានដោយគ្មានវាប្រសិនបើអ្នកប្រើឧបករណ៍ត្រឹមត្រូវ!

តើផែនការសំណួរជាធម្មតាមើលទៅដូចអ្វី? អ្វីមួយ​ដូច​នោះ:

Index Scan using pg_class_relname_nsp_index on pg_class (actual time=0.049..0.050 rows=1 loops=1)
  Index Cond: (relname = $1)
  Filter: (oid = $0)
  Buffers: shared hit=4
  InitPlan 1 (returns $0,$1)
    ->  Limit (actual time=0.019..0.020 rows=1 loops=1)
          Buffers: shared hit=1
          ->  Seq Scan on pg_class pg_class_1 (actual time=0.015..0.015 rows=1 loops=1)
                Filter: (relkind = 'r'::"char")
                Rows Removed by Filter: 5
                Buffers: shared hit=1

ឬដូចនេះ៖

"Append  (cost=868.60..878.95 rows=2 width=233) (actual time=0.024..0.144 rows=2 loops=1)"
"  Buffers: shared hit=3"
"  CTE cl"
"    ->  Seq Scan on pg_class  (cost=0.00..868.60 rows=9972 width=537) (actual time=0.016..0.042 rows=101 loops=1)"
"          Buffers: shared hit=3"
"  ->  Limit  (cost=0.00..0.10 rows=1 width=233) (actual time=0.023..0.024 rows=1 loops=1)"
"        Buffers: shared hit=1"
"        ->  CTE Scan on cl  (cost=0.00..997.20 rows=9972 width=233) (actual time=0.021..0.021 rows=1 loops=1)"
"              Buffers: shared hit=1"
"  ->  Limit  (cost=10.00..10.10 rows=1 width=233) (actual time=0.117..0.118 rows=1 loops=1)"
"        Buffers: shared hit=2"
"        ->  CTE Scan on cl cl_1  (cost=0.00..997.20 rows=9972 width=233) (actual time=0.001..0.104 rows=101 loops=1)"
"              Buffers: shared hit=2"
"Planning Time: 0.634 ms"
"Execution Time: 0.248 ms"

ប៉ុន្តែការអានផែនការនៅក្នុងអត្ថបទ "ពីសន្លឹក" គឺពិបាកនិងមិនច្បាស់លាស់៖

• ត្រូវបានបង្ហាញនៅក្នុង node ផលបូកដោយធនធានមែកធាងរង
  នោះគឺដើម្បីស្វែងយល់ថាតើវាត្រូវចំណាយពេលប៉ុន្មានដើម្បីប្រតិបត្តិថ្នាំងជាក់លាក់មួយ ឬថាតើការអាននេះពីតារាងបានយកទិន្នន័យពីឌីសប៉ុន្មានយ៉ាងពិតប្រាកដ អ្នកត្រូវដកមួយចេញពីមួយទៀត។
• ត្រូវការពេលវេលារបស់ node គុណនឹងរង្វិលជុំ
  បាទ ការដកមិនមែនជាប្រតិបត្តិការស្មុគស្មាញបំផុតដែលត្រូវធ្វើ "នៅក្នុងក្បាល" - បន្ទាប់ពីទាំងអស់ ពេលវេលាប្រតិបត្តិត្រូវបានចង្អុលបង្ហាញថាជាមធ្យមសម្រាប់ការប្រតិបត្តិនៃថ្នាំងមួយ ហើយវាអាចមានរាប់រយ
• ជាការប្រសើរណាស់ ហើយទាំងអស់នេះរួមគ្នារារាំងយើងពីការឆ្លើយសំណួរចម្បង - ដូច្នេះអ្នកណា "តំណភ្ជាប់ខ្សោយបំផុត"?

នៅពេលដែលយើងព្យាយាមពន្យល់ទាំងអស់នេះទៅកាន់អ្នកអភិវឌ្ឍន៍ជាច្រើនរយនាក់របស់យើង យើងបានដឹងថាពីខាងក្រៅវាមើលទៅដូចនេះ៖

ហើយនោះមានន័យថាយើងត្រូវការ ...

ឧបករណ៍

នៅក្នុងនោះ យើងបានព្យាយាមប្រមូលមេកានិកសំខាន់ៗទាំងអស់ ដែលជួយឱ្យយល់ "អ្នកណាត្រូវស្តីបន្ទោស និងអ្វីដែលត្រូវធ្វើ" ស្របតាមផែនការ និងសំណើ។ ជាការប្រសើរណាស់ ហើយចែករំលែកផ្នែកមួយនៃបទពិសោធន៍របស់អ្នកជាមួយសហគមន៍។
ជួបនិងប្រើ - ពន្យល់.tensor.ru

ភាពមើលឃើញនៃផែនការ

តើ​វា​ងាយ​ស្រួល​ក្នុង​ការ​យល់​ពី​ផែន​ការ​នៅ​ពេល​ដែល​វា​មើល​ទៅ​ដូច​នេះ​ទេ?

Seq Scan on pg_class (actual time=0.009..1.304 rows=6609 loops=1)
  Buffers: shared hit=263
Planning Time: 0.108 ms
Execution Time: 1.800 ms

មិនមែនទេ។

ប៉ុន្តែដូចនេះ, ក្នុងទម្រង់អក្សរកាត់នៅពេលដែលសូចនាករសំខាន់ៗត្រូវបានបំបែកវាកាន់តែច្បាស់៖

ប៉ុន្តែប្រសិនបើផែនការកាន់តែស្មុគស្មាញ គាត់នឹងមកជួយសង្គ្រោះ ការចែកចាយពេលវេលា piechart ដោយថ្នាំង៖

ជាការប្រសើរណាស់ សម្រាប់ជម្រើសដ៏លំបាកបំផុត គាត់ប្រញាប់ជួយ គំនូសតាងវឌ្ឍនភាព:

ជាឧទាហរណ៍ មានស្ថានភាពមិនសំខាន់នៅពេលដែលផែនការមួយអាចមានឫសគល់ពិតប្រាកដច្រើនជាងមួយ៖

តម្រុយរចនាសម្ព័ន្ធ

ជាការប្រសើរណាស់ ប្រសិនបើរចនាសម្ព័ន្ធទាំងមូលនៃផែនការ និងចំណុចឈឺចាប់របស់វាត្រូវបានដាក់ចេញ និងអាចមើលឃើញរួចហើយ ហេតុអ្វីមិនគូសបញ្ជាក់ពួកវាទៅអ្នកអភិវឌ្ឍន៍ ហើយពន្យល់ពួកវាជា "ភាសារុស្សី"?

យើង​បាន​ប្រមូល​គំរូ​អនុសាសន៍​មួយ​ចំនួន​រួច​ហើយ​។

កម្រងព័ត៌មានសំណួរតាមបន្ទាត់

ឥឡូវនេះ ប្រសិនបើអ្នកដាក់បញ្ចូលសំណួរដើមទៅក្នុងផែនការដែលបានវិភាគ អ្នកអាចឃើញថាតើត្រូវចំណាយពេលវេលាប៉ុន្មានសម្រាប់សេចក្តីថ្លែងការណ៍នីមួយៗ - អ្វីមួយដូចនេះ៖

... ឬសូម្បីតែដូចនេះ៖

ការជំនួសប៉ារ៉ាម៉ែត្រទៅក្នុងសំណើ

ប្រសិនបើអ្នក "ភ្ជាប់" មិនត្រឹមតែសំណើទៅគម្រោងប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានប៉ារ៉ាម៉ែត្ររបស់វាពីបន្ទាត់លម្អិតនៃកំណត់ហេតុផងដែរ អ្នកអាចចម្លងវានៅក្នុងជម្រើសមួយក្នុងចំណោមជម្រើស៖

• ជាមួយនឹងការជំនួសតម្លៃនៅក្នុងសំណួរ
  សម្រាប់ការប្រតិបត្តិដោយផ្ទាល់នៅលើមូលដ្ឋានរបស់អ្នក និងទម្រង់បន្ថែម

  SELECT 'const', 'param'::text;

• ជាមួយនឹងការជំនួសតម្លៃតាមរយៈ PREPARE/EXECUTE
  ដើម្បីត្រាប់តាមការងាររបស់អ្នកកំណត់ពេលនៅពេលដែលផ្នែកប៉ារ៉ាម៉ែត្រអាចត្រូវបានមិនអើពើ - ឧទាហរណ៍នៅពេលធ្វើការលើតារាងបែងចែក

  DEALLOCATE ALL;
  PREPARE q(text) AS SELECT 'const', $1::text;
  EXECUTE q('param'::text);
  

ប័ណ្ណសារនៃផែនការ

បិទភ្ជាប់, វិភាគ, ចែករំលែកជាមួយសហការី! គម្រោង​នឹង​នៅ​តែ​រក្សា​ទុក​ក្នុង​ប័ណ្ណសារ ហើយ​អ្នក​អាច​ត្រឡប់​ទៅ​វា​វិញ​នៅ​ពេល​ក្រោយ៖ ពន្យល់.tensor.ru/archive

ប៉ុន្តែប្រសិនបើអ្នកមិនចង់ឱ្យអ្នកដទៃឃើញគម្រោងរបស់អ្នកទេ កុំភ្លេចពិនិត្យមើលប្រអប់ "កុំផ្សព្វផ្សាយក្នុងប័ណ្ណសារ"។

នៅក្នុងអត្ថបទខាងក្រោមខ្ញុំនឹងនិយាយអំពីការលំបាក និងការសម្រេចចិត្តដែលកើតឡើងនៅពេលវិភាគផែនការ។

ប្រភព: www.habr.com