EXPLAIN എന്തിനെക്കുറിച്ചാണ് നിശബ്ദത പാലിക്കുന്നത്, അത് എങ്ങനെ സംസാരിക്കാം

ഒരു ഡവലപ്പർ തന്റെ DBA യിലേക്ക് കൊണ്ടുവരുന്ന അല്ലെങ്കിൽ ഒരു ബിസിനസ്സ് ഉടമ ഒരു PostgreSQL കൺസൾട്ടന്റിലേക്ക് കൊണ്ടുവരുന്ന ക്ലാസിക് ചോദ്യം മിക്കവാറും എല്ലായ്‌പ്പോഴും ഒരുപോലെയാണ്: "എന്തുകൊണ്ടാണ് ഡാറ്റാബേസിൽ അഭ്യർത്ഥനകൾ പൂർത്തിയാക്കാൻ ഇത്രയും സമയം എടുക്കുന്നത്?"

പരമ്പരാഗത കാരണങ്ങളുടെ കൂട്ടം:

• കാര്യക്ഷമമല്ലാത്ത അൽഗോരിതം
  പതിനായിരക്കണക്കിന് റെക്കോഡുകളിൽ നിരവധി CTE-കളിൽ ചേരാൻ നിങ്ങൾ തീരുമാനിക്കുമ്പോൾ
• അപ്രസക്തമായ സ്ഥിതിവിവരക്കണക്കുകൾ
  പട്ടികയിലെ ഡാറ്റയുടെ യഥാർത്ഥ വിതരണം ഇതിനകം തന്നെ കഴിഞ്ഞ തവണ വിശകലനം ചെയ്തതിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണെങ്കിൽ
• ഉറവിടങ്ങളിൽ "പ്ലഗ്"
  കൂടാതെ സിപിയുവിന് വേണ്ടത്ര സമർപ്പിത കമ്പ്യൂട്ടിംഗ് പവർ ഇല്ല, ജിഗാബൈറ്റ് മെമ്മറി നിരന്തരം പമ്പ് ചെയ്യപ്പെടുന്നു, അല്ലെങ്കിൽ ഡാറ്റാബേസിന്റെ എല്ലാ "ആഗ്രഹങ്ങളും" ഡിസ്കിന് നിലനിർത്താൻ കഴിയില്ല.
• തടയുന്നു മത്സര പ്രക്രിയകളിൽ നിന്ന്

തടയലുകൾ പിടിക്കാനും വിശകലനം ചെയ്യാനും വളരെ ബുദ്ധിമുട്ടാണെങ്കിൽ, മറ്റെല്ലാത്തിനും നമുക്ക് ആവശ്യമാണ് അന്വേഷണ പദ്ധതി, ഉപയോഗിച്ച് ലഭിക്കും ഓപ്പറേറ്ററെ വിശദീകരിക്കുക (തീർച്ചയായും, ഉടനടി വിശദീകരിക്കുന്നതാണ് നല്ലത് (വിശകലനം ചെയ്യുക, ബഫറുകൾ) ...) അല്ലെങ്കിൽ 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"

എന്നാൽ "ഷീറ്റിൽ നിന്ന്" എന്ന വാചകത്തിൽ പ്ലാൻ വായിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടുള്ളതും അവ്യക്തവുമാണ്:

• നോഡിൽ പ്രദർശിപ്പിച്ചിരിക്കുന്നു സബ്ട്രീ ഉറവിടങ്ങളാൽ തുക
  അതായത്, ഒരു പ്രത്യേക നോഡ് എക്സിക്യൂട്ട് ചെയ്യാൻ എത്ര സമയമെടുത്തു, അല്ലെങ്കിൽ പട്ടികയിൽ നിന്നുള്ള ഈ വായന എത്ര കൃത്യമായി ഡിസ്കിൽ നിന്ന് ഡാറ്റ കൊണ്ടുവന്നുവെന്ന് മനസിലാക്കാൻ, നിങ്ങൾ എങ്ങനെയെങ്കിലും ഒന്ന് മറ്റൊന്നിൽ നിന്ന് കുറയ്ക്കേണ്ടതുണ്ട്.
• നോഡ് സമയം ആവശ്യമാണ് ലൂപ്പുകളാൽ ഗുണിക്കുക
  അതെ, "തലയിൽ" ചെയ്യേണ്ട ഏറ്റവും സങ്കീർണ്ണമായ പ്രവർത്തനമല്ല കുറയ്ക്കൽ - എല്ലാത്തിനുമുപരി, ഒരു നോഡിന്റെ ഒരു എക്സിക്യൂഷന്റെ എക്സിക്യൂഷൻ സമയം ശരാശരിയായി സൂചിപ്പിച്ചിരിക്കുന്നു, അവയിൽ നൂറുകണക്കിന് ഉണ്ടാകാം
• ശരി, ഇതെല്ലാം ഒരുമിച്ച് പ്രധാന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നതിൽ നിന്ന് ഞങ്ങളെ തടയുന്നു - അതിനാൽ ആരാണ് "ഏറ്റവും ദുർബലമായ ലിങ്ക്"?

ഞങ്ങളുടെ നൂറുകണക്കിന് ഡെവലപ്പർമാരോട് ഇതെല്ലാം വിശദീകരിക്കാൻ ശ്രമിച്ചപ്പോൾ, പുറത്ത് നിന്ന് ഇത് ഇതുപോലെയാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി:

അതിനർത്ഥം നമുക്ക് വേണം ...

ഉപകരണം

അതിൽ പ്ലാനും അഭ്യർത്ഥനയും അനുസരിച്ച് "ആരെയാണ് കുറ്റപ്പെടുത്തേണ്ടത്, എന്തുചെയ്യണം" എന്ന് മനസിലാക്കാൻ സഹായിക്കുന്ന എല്ലാ പ്രധാന മെക്കാനിക്സുകളും ശേഖരിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു. ശരി, നിങ്ങളുടെ അനുഭവത്തിന്റെ ഒരു ഭാഗം കമ്മ്യൂണിറ്റിയുമായി പങ്കിടുക.
കണ്ടുമുട്ടുകയും ഉപയോഗിക്കുക - വിശദീകരിക്കുക.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

അല്ല.

എന്നാൽ ഇതുപോലെ, സംക്ഷിപ്ത രൂപത്തിൽപ്രധാന സൂചകങ്ങൾ വേർതിരിക്കുമ്പോൾ, ഇത് കൂടുതൽ വ്യക്തമാകും:

എന്നാൽ പദ്ധതി കൂടുതൽ സങ്കീർണ്ണമാണെങ്കിൽ, അവൻ രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരും പീച്ചാർട്ട് സമയ വിതരണം നോഡുകൾ വഴി:

ശരി, ഏറ്റവും ബുദ്ധിമുട്ടുള്ള ഓപ്ഷനുകൾക്കായി അവൻ സഹായിക്കാൻ തിരക്കിലാണ് പുരോഗതി ചാർട്ട്:

ഉദാഹരണത്തിന്, ഒരു പ്ലാനിന് ഒന്നിലധികം യഥാർത്ഥ റൂട്ടുകൾ ഉണ്ടാകുമ്പോൾ നിസ്സാരമല്ലാത്ത സാഹചര്യങ്ങളുണ്ട്:

ഘടനാപരമായ സൂചനകൾ

ശരി, പ്ലാനിന്റെ മുഴുവൻ ഘടനയും അതിന്റെ വേദനാജനകമായ പാടുകളും ഇതിനകം തന്നെ നിരത്തുകയും ദൃശ്യമാകുകയും ചെയ്താൽ, എന്തുകൊണ്ട് അവ ഡവലപ്പർക്ക് ഹൈലൈറ്റ് ചെയ്ത് "റഷ്യൻ ഭാഷയിൽ" വിശദീകരിക്കരുത്?

അത്തരം രണ്ട് ഡസൻ ശുപാർശ ടെംപ്ലേറ്റുകൾ ഞങ്ങൾ ഇതിനകം ശേഖരിച്ചിട്ടുണ്ട്.

ലൈൻ-ബൈ-ലൈൻ അന്വേഷണ പ്രൊഫൈലർ

ഇപ്പോൾ, നിങ്ങൾ യഥാർത്ഥ ചോദ്യം വിശകലനം ചെയ്ത പ്ലാനിലേക്ക് സൂപ്പർഇമ്പോസ് ചെയ്യുകയാണെങ്കിൽ, ഓരോ വ്യക്തിഗത പ്രസ്താവനയിലും എത്ര സമയം ചെലവഴിച്ചുവെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും - ഇതുപോലുള്ള ഒന്ന്:

... അല്ലെങ്കിൽ ഇതുപോലെ:

ഒരു അഭ്യർത്ഥനയിൽ പരാമീറ്ററുകൾ മാറ്റിസ്ഥാപിക്കുന്നു

നിങ്ങൾ പ്ലാനിലേക്ക് ഒരു അഭ്യർത്ഥന മാത്രമല്ല, ലോഗിന്റെ DETAIL ലൈനിൽ നിന്ന് അതിന്റെ പാരാമീറ്ററുകളും "അറ്റാച്ച് ചെയ്തിട്ടുണ്ടെങ്കിൽ", നിങ്ങൾക്ക് ഇത് ഓപ്ഷനുകളിലൊന്നിൽ പകർത്താനാകും:

• ചോദ്യത്തിൽ മൂല്യത്തിന് പകരം വയ്ക്കുന്നത്
  നിങ്ങളുടെ അടിത്തറയിൽ നേരിട്ടുള്ള നിർവ്വഹണത്തിനും കൂടുതൽ പ്രൊഫൈലിങ്ങിനും

  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