അസുഖമുള്ള SQL അന്വേഷണങ്ങൾക്കുള്ള പാചകക്കുറിപ്പുകൾ

മാസം മുമ്പ് ഞങ്ങൾ പ്രഖ്യാപിച്ചു വിശദീകരിക്കുക.tensor.ru - പൊതു അന്വേഷണ പ്ലാനുകൾ പാഴ്‌സ് ചെയ്യുന്നതിനും ദൃശ്യവൽക്കരിക്കുന്നതിനുമുള്ള സേവനം PostgreSQL-ലേക്ക്.

നിങ്ങൾ ഇത് ഇതിനകം 6000-ലധികം തവണ ഉപയോഗിച്ചു, എന്നാൽ ശ്രദ്ധിക്കപ്പെടാതെ പോയേക്കാവുന്ന ഒരു ഹാൻഡി ഫീച്ചർ ഘടനാപരമായ സൂചനകൾ, ഇത് ഇതുപോലെ കാണപ്പെടുന്നു:

അവ ശ്രദ്ധിക്കുക, നിങ്ങളുടെ അഭ്യർത്ഥനകൾ "മിനുസമാർന്നതും സിൽക്കി ആയി മാറും." 🙂

എന്നാൽ ഗൗരവമായി, ഒരു അഭ്യർത്ഥന മന്ദഗതിയിലാക്കുന്നതും വിഭവ-ദാഹം ഉണ്ടാക്കുന്നതുമായ പല സാഹചര്യങ്ങളും സാധാരണവും പ്ലാനിന്റെ ഘടനയും ഡാറ്റയും ഉപയോഗിച്ച് തിരിച്ചറിയാൻ കഴിയും.

ഈ സാഹചര്യത്തിൽ, ഓരോ വ്യക്തിഗത ഡെവലപ്പർക്കും സ്വന്തം അനുഭവത്തെ മാത്രം ആശ്രയിച്ച് ഒരു ഒപ്റ്റിമൈസേഷൻ ഓപ്ഷൻ നോക്കേണ്ടതില്ല - ഇവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് നമുക്ക് അവനോട് പറയാൻ കഴിയും, കാരണം എന്തായിരിക്കാം, കൂടാതെ ഒരു പരിഹാരത്തെ എങ്ങനെ സമീപിക്കാം. അതാണ് ഞങ്ങൾ ചെയ്തത്.

ഈ കേസുകൾ നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം - അവ എങ്ങനെ നിർവചിക്കപ്പെടുന്നു, അവ എന്ത് ശുപാർശകളിലേക്ക് നയിക്കുന്നു.

വിഷയത്തിൽ നന്നായി മുഴുകുന്നതിന്, നിങ്ങൾക്ക് ആദ്യം ബന്ധപ്പെട്ട ബ്ലോക്ക് കേൾക്കാം PGConf.Russia 2020-ലെ എന്റെ റിപ്പോർട്ട്, അതിനുശേഷം മാത്രമേ ഓരോ ഉദാഹരണത്തിന്റെയും വിശദമായ വിശകലനത്തിലേക്ക് നീങ്ങുക:

#1: സൂചിക "അണ്ടർസോർട്ടിംഗ്"

എപ്പോൾ ചെയ്യുന്നു

"LLC Kolokolchik" എന്ന ക്ലയന്റിനായുള്ള ഏറ്റവും പുതിയ ഇൻവോയ്സ് കാണിക്കുക.

എങ്ങനെ തിരിച്ചറിയാം

-> Limit
   -> Sort
      -> Index [Only] Scan [Backward] | Bitmap Heap Scan

ശുപാർശകൾ

ഉപയോഗിച്ച സൂചിക അടുക്കിയ ഫീൽഡുകൾ ഉപയോഗിച്ച് വികസിപ്പിക്കുക.

ഉദാഹരണം:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 1 -- отбор по конкретной связи
ORDER BY
  pk DESC -- хотим всего одну "последнюю" запись
LIMIT 1;

[explain.tensor.ru-ൽ കാണുക]

സൂചികയിൽ നിന്ന് 100-ലധികം റെക്കോർഡുകൾ കുറച്ചതായി നിങ്ങൾക്ക് ഉടനടി ശ്രദ്ധിക്കാനാകും, അവയെല്ലാം ക്രമീകരിച്ചു, തുടർന്ന് അവശേഷിച്ചത്.

തിരുത്തുന്നു:

DROP INDEX tbl_fk_cli_idx;
CREATE INDEX ON tbl(fk_cli, pk DESC); -- добавили ключ сортировки

[explain.tensor.ru-ൽ കാണുക]

അത്തരമൊരു പ്രാകൃത മാതൃകയിൽ പോലും - 8.5 മടങ്ങ് വേഗതയും 33 മടങ്ങ് കുറവ് വായനയും. ഓരോ മൂല്യത്തിനും നിങ്ങൾക്ക് കൂടുതൽ "വസ്തുതകൾ" ഉണ്ട്, കൂടുതൽ വ്യക്തമായ പ്രഭാവം fk.

അത്തരം ഒരു സൂചിക മറ്റ് ചോദ്യങ്ങൾക്ക് മുമ്പത്തേക്കാൾ മോശമല്ലാത്ത ഒരു "പ്രിഫിക്സ്" സൂചികയായി പ്രവർത്തിക്കുമെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു. fk, എവിടെ അടുക്കുക pk ഉണ്ടായിരുന്നില്ല, ഇല്ല (ഇതിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഫലപ്രദമല്ലാത്ത സൂചികകൾ കണ്ടെത്തുന്നതിനെക്കുറിച്ചുള്ള എന്റെ ലേഖനത്തിൽ). ഉൾപ്പെടെ, ഇത് സാധാരണ നൽകും വ്യക്തമായ വിദേശ കീ പിന്തുണ ഈ വയലിൽ.

#2: സൂചിക കവല (ബിറ്റ്മാപ്പ് ആൻഡ്)

എപ്പോൾ ചെയ്യുന്നു

"NAO ബട്ടർകപ്പിന്" വേണ്ടി സമാപിച്ച "LLC Kolokolchik" എന്ന ക്ലയന്റിനായുള്ള എല്ലാ കരാറുകളും കാണിക്കുക.

എങ്ങനെ തിരിച്ചറിയാം

-> BitmapAnd
   -> Bitmap Index Scan
   -> Bitmap Index Scan

ശുപാർശകൾ

സൃഷ്ടിക്കുക സംയോജിത സൂചിക രണ്ട് ഒറിജിനൽ ഫീൽഡുകളിൽ നിന്നും അല്ലെങ്കിൽ നിലവിലുള്ളവയിൽ ഒന്ന് രണ്ടാമത്തേതിൽ നിന്ന് ഫീൽഡുകൾ ഉപയോഗിച്ച് വികസിപ്പിക്കുക.

ഉദാഹരണം:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org); -- индекс для foreign key
CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  (fk_org, fk_cli) = (1, 999); -- отбор по конкретной паре

[explain.tensor.ru-ൽ കാണുക]

തിരുത്തുന്നു:

DROP INDEX tbl_fk_org_idx;
CREATE INDEX ON tbl(fk_org, fk_cli);

[explain.tensor.ru-ൽ കാണുക]

ബിറ്റ്‌മാപ്പ് ഹീപ്പ് സ്കാൻ സ്വന്തമായി ഫലപ്രദമാകുമെന്നതിനാൽ ഇവിടെ പ്രതിഫലം ചെറുതാണ്. എന്നാൽ എന്തായാലും 7 മടങ്ങ് വേഗതയും 2.5 മടങ്ങ് കുറവ് വായനയും.

#3: സൂചികകൾ ലയിപ്പിക്കുക (BitmapOr)

എപ്പോൾ ചെയ്യുന്നു

നിങ്ങളുടേത് മുൻഗണനയിൽ, പ്രോസസ്സിംഗിനായി ഏറ്റവും പഴയ 20 "ഞങ്ങൾ" അല്ലെങ്കിൽ അസൈൻ ചെയ്യാത്ത അഭ്യർത്ഥനകൾ കാണിക്കുക.

എങ്ങനെ തിരിച്ചറിയാം

-> BitmapOr
   -> Bitmap Index Scan
   -> Bitmap Index Scan

ശുപാർശകൾ

ഉപയോഗിക്കുക യൂണിയൻ [എല്ലാം] വ്യവസ്ഥകളുടെ ഓരോ OR-ബ്ലോക്കുകൾക്കും സബ്ക്വറികൾ സംയോജിപ്പിക്കാൻ.

ഉദാഹരണം:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL -- с вероятностью 1:16 запись "ничья"
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own;

CREATE INDEX ON tbl(fk_own, pk); -- индекс с "вроде как подходящей" сортировкой

SELECT
  *
FROM
  tbl
WHERE
  fk_own = 1 OR -- свои
  fk_own IS NULL -- ... или "ничьи"
ORDER BY
  pk
, (fk_own = 1) DESC -- сначала "свои"
LIMIT 20;

[explain.tensor.ru-ൽ കാണുക]

തിരുത്തുന്നു:

(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own = 1 -- сначала "свои" 20
  ORDER BY
    pk
  LIMIT 20
)
UNION ALL
(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own IS NULL -- потом "ничьи" 20
  ORDER BY
    pk
  LIMIT 20
)
LIMIT 20; -- но всего - 20, больше и не надо

[explain.tensor.ru-ൽ കാണുക]

ആവശ്യമായ എല്ലാ 20 റെക്കോർഡുകളും ആദ്യ ബ്ലോക്കിൽ ഉടനടി ലഭിച്ചു എന്ന വസ്തുത ഞങ്ങൾ പ്രയോജനപ്പെടുത്തി, അതിനാൽ രണ്ടാമത്തേത്, കൂടുതൽ “വിലയേറിയ” ബിറ്റ്മാപ്പ് ഹീപ്പ് സ്കാൻ ഉപയോഗിച്ച്, എക്സിക്യൂട്ട് ചെയ്തില്ല - അവസാനം 22 മടങ്ങ് വേഗത്തിൽ, 44 മടങ്ങ് കുറവ് വായനകൾ!

ഈ ഒപ്റ്റിമൈസേഷൻ രീതിയെക്കുറിച്ചുള്ള കൂടുതൽ വിശദമായ കഥ നിർദ്ദിഷ്ട ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് ലേഖനങ്ങളിൽ വായിക്കാം PostgreSQL ആന്റിപാറ്റേണുകൾ: ഹാനികരമായ ജോയിനുകളും OR-കളും и PostgreSQL ആന്റിപാറ്റേണുകൾ: പേരിനാൽ തിരയലിന്റെ ആവർത്തന പരിഷ്കരണത്തിന്റെ ഒരു കഥ, അല്ലെങ്കിൽ "അങ്ങോട്ടും ഇങ്ങോട്ടും ഒപ്റ്റിമൈസേഷൻ".

പൊതുവായ പതിപ്പ് നിരവധി കീകൾ അടിസ്ഥാനമാക്കിയുള്ള തിരഞ്ഞെടുപ്പ് ഓർഡർ ചെയ്തു (ഒപ്പം const/NULL ജോഡി മാത്രമല്ല) ലേഖനത്തിൽ ചർച്ചചെയ്യുന്നു SQL എങ്ങനെ: ചോദ്യത്തിൽ നേരിട്ട് ഒരു ലൂപ്പ് എഴുതുക, അല്ലെങ്കിൽ "എലിമെന്ററി ത്രീ-സ്റ്റെപ്പ്".

#4: നമ്മൾ അനാവശ്യമായ ഒരുപാട് കാര്യങ്ങൾ വായിക്കുന്നു

എപ്പോൾ ചെയ്യുന്നു

ഒരു ചട്ടം പോലെ, ഇതിനകം നിലവിലുള്ള ഒരു അഭ്യർത്ഥനയിലേക്ക് "മറ്റൊരു ഫിൽട്ടർ അറ്റാച്ചുചെയ്യാൻ" നിങ്ങൾ ആഗ്രഹിക്കുമ്പോൾ അത് ഉയർന്നുവരുന്നു.

“നിങ്ങൾക്കില്ല, പക്ഷേ മദർ ഓഫ് പേൾ ബട്ടണുകൾക്കൊപ്പം? സിനിമ "ദി ഡയമണ്ട് ആം"

ഉദാഹരണത്തിന്, മുകളിലുള്ള ടാസ്‌ക് പരിഷ്‌ക്കരിക്കുന്നതിലൂടെ, അവയുടെ ഉദ്ദേശ്യം പരിഗണിക്കാതെ തന്നെ പ്രോസസ്സിംഗിനുള്ള ഏറ്റവും പഴയ 20 "നിർണ്ണായക" അഭ്യർത്ഥനകൾ കാണിക്കുക.

എങ്ങനെ തിരിച്ചറിയാം

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && 5 × rows < RRbF -- отфильтровано >80% прочитанного
   && loops × RRbF > 100 -- и при этом больше 100 записей суммарно

ശുപാർശകൾ

പ്രത്യേകം [കൂടുതൽ] സൃഷ്ടിക്കുക WHERE അവസ്ഥയുള്ള സൂചിക അല്ലെങ്കിൽ സൂചികയിൽ അധിക ഫീൽഡുകൾ ഉൾപ്പെടുത്തുക.

നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് ഫിൽട്ടർ അവസ്ഥ "സ്റ്റാറ്റിക്" ആണെങ്കിൽ - അതായത് വിപുലീകരണത്തെ സൂചിപ്പിക്കുന്നില്ല ഭാവിയിലെ മൂല്യങ്ങളുടെ പട്ടിക - WHERE സൂചിക ഉപയോഗിക്കുന്നതാണ് നല്ലത്. വിവിധ ബൂളിയൻ/എനം സ്റ്റാറ്റസുകൾ ഈ വിഭാഗത്തിലേക്ക് നന്നായി യോജിക്കുന്നു.

ഫിൽട്ടറിംഗ് അവസ്ഥയാണെങ്കിൽ വ്യത്യസ്ത അർത്ഥങ്ങൾ എടുക്കാം, അപ്പോൾ ഈ ഫീൽഡുകൾ ഉപയോഗിച്ച് സൂചിക വികസിപ്പിക്കുന്നതാണ് നല്ലത് - BitmapAnd ഉം മുകളിലുള്ള സാഹചര്യത്തിലെന്നപോലെ.

ഉദാഹരണം:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own
, (random() < 1::real/50) critical; -- 1:50, что заявка "критичная"

CREATE INDEX ON tbl(pk);
CREATE INDEX ON tbl(fk_own, pk);

SELECT
  *
FROM
  tbl
WHERE
  critical
ORDER BY
  pk
LIMIT 20;

[explain.tensor.ru-ൽ കാണുക]

തിരുത്തുന്നു:

CREATE INDEX ON tbl(pk)
  WHERE critical; -- добавили "статичное" условие фильтрации

[explain.tensor.ru-ൽ കാണുക]

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, പ്ലാനിൽ നിന്ന് ഫിൽട്ടറിംഗ് പൂർണ്ണമായും അപ്രത്യക്ഷമായി, അഭ്യർത്ഥനയായി 5 മടങ്ങ് വേഗത്തിൽ.

#5: വിരളമായ പട്ടിക

എപ്പോൾ ചെയ്യുന്നു

നിങ്ങളുടെ സ്വന്തം ടാസ്‌ക് പ്രോസസ്സിംഗ് ക്യൂ സൃഷ്‌ടിക്കാനുള്ള വിവിധ ശ്രമങ്ങൾ, ടേബിളിലെ റെക്കോർഡുകളുടെ ഒരു വലിയ സംഖ്യ അപ്‌ഡേറ്റുകൾ / ഇല്ലാതാക്കലുകൾ ഒരു വലിയ സംഖ്യ "ഡെഡ്" റെക്കോർഡുകളുടെ അവസ്ഥയിലേക്ക് നയിക്കുമ്പോൾ.

എങ്ങനെ തിരിച്ചറിയാം

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

ശുപാർശകൾ

പതിവായി സ്വമേധയാ നടപ്പിലാക്കുക വാക്വം [പൂർണ്ണം] അല്ലെങ്കിൽ മതിയായ ഇടയ്ക്കിടെയുള്ള പരിശീലനം നേടുക ഓട്ടോവാക്വം ഉൾപ്പെടെ, അതിന്റെ പാരാമീറ്ററുകൾ നന്നായി ട്യൂൺ ചെയ്തുകൊണ്ട് ഒരു പ്രത്യേക പട്ടികയ്ക്കായി.

മിക്ക കേസുകളിലും, ചർച്ച ചെയ്തതുപോലുള്ള ബിസിനസ്സ് ലോജിക്കിൽ നിന്ന് വിളിക്കുമ്പോൾ മോശം ചോദ്യ കോമ്പോസിഷൻ മൂലമാണ് ഇത്തരം പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നത് PostgreSQL ആന്റിപാറ്റേണുകൾ: "മരിച്ചവരുടെ" കൂട്ടത്തിനെതിരായ പോരാട്ടം.

എന്നാൽ VACUUM FULL പോലും എല്ലായ്പ്പോഴും സഹായിച്ചേക്കില്ല എന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. അത്തരം സന്ദർഭങ്ങളിൽ, ലേഖനത്തിൽ നിന്നുള്ള അൽഗോരിതം സ്വയം പരിചയപ്പെടുത്തുന്നത് മൂല്യവത്താണ് DBA: വാക്വം പരാജയപ്പെടുമ്പോൾ, ഞങ്ങൾ മേശ സ്വമേധയാ വൃത്തിയാക്കുന്നു.

#6: സൂചികയുടെ "മധ്യത്തിൽ" നിന്ന് വായന

എപ്പോൾ ചെയ്യുന്നു

ഞങ്ങൾ കുറച്ച് വായിച്ചതായി തോന്നുന്നു, എല്ലാം സൂചികയിലാക്കി, ഞങ്ങൾ ആരെയും അധികമായി ഫിൽട്ടർ ചെയ്തിട്ടില്ല - എന്നിട്ടും ഞങ്ങൾ ആഗ്രഹിക്കുന്നതിലും കൂടുതൽ പേജുകൾ ഞങ്ങൾ വായിക്കുന്നു.

എങ്ങനെ തിരിച്ചറിയാം

-> Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

ശുപാർശകൾ

ഉപയോഗിച്ച സൂചികയുടെ ഘടനയും അന്വേഷണത്തിൽ വ്യക്തമാക്കിയ പ്രധാന ഫീൽഡുകളും സൂക്ഷ്മമായി പരിശോധിക്കുക - മിക്കവാറും സൂചികയുടെ ഭാഗം വ്യക്തമാക്കിയിട്ടില്ല. മിക്കവാറും നിങ്ങൾ സമാനമായ ഒരു സൂചിക സൃഷ്ടിക്കേണ്ടതുണ്ട്, പക്ഷേ പ്രിഫിക്സ് ഫീൽഡുകൾ ഇല്ലാതെ അല്ലെങ്കിൽ അവരുടെ മൂല്യങ്ങൾ ആവർത്തിക്കാൻ പഠിക്കുക.

ഉദാഹരണം:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org, fk_cli); -- все почти как в #2
-- только вот отдельный индекс по fk_cli мы уже посчитали лишним и удалили

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 999 -- а fk_org не задано, хотя стоит в индексе раньше
LIMIT 20;

[explain.tensor.ru-ൽ കാണുക]

സൂചിക അനുസരിച്ച് പോലും എല്ലാം ശരിയാണെന്ന് തോന്നുന്നു, പക്ഷേ ഇത് എങ്ങനെയെങ്കിലും സംശയാസ്പദമാണ് - വായിക്കുന്ന 20 റെക്കോർഡുകളിൽ ഓരോന്നിനും ഞങ്ങൾക്ക് 4 പേജ് ഡാറ്റ കുറയ്ക്കേണ്ടി വന്നു, ഒരു റെക്കോർഡിന് 32 കെബി - അത് ധൈര്യമല്ലേ? ഒപ്പം സൂചിക നാമവും tbl_fk_org_fk_cli_idx ചിന്തോദ്ദീപകമായ.

തിരുത്തുന്നു:

CREATE INDEX ON tbl(fk_cli);

[explain.tensor.ru-ൽ കാണുക]

പെട്ടെന്ന് - 10 മടങ്ങ് വേഗത്തിൽ, വായിക്കാൻ 4 മടങ്ങ് കുറവ്!

സൂചികകളുടെ ഫലപ്രദമല്ലാത്ത ഉപയോഗത്തിന്റെ സാഹചര്യങ്ങളുടെ മറ്റ് ഉദാഹരണങ്ങൾ ലേഖനത്തിൽ കാണാം DBA: ഉപയോഗശൂന്യമായ സൂചികകൾ കണ്ടെത്തുന്നു.

#7: CTE × CTE

എപ്പോൾ ചെയ്യുന്നു

അഭ്യർത്ഥനയിൽ "കൊഴുപ്പ്" CTE സ്കോർ ചെയ്തു വ്യത്യസ്ത പട്ടികകളിൽ നിന്ന്, തുടർന്ന് അവയ്ക്കിടയിൽ അത് ചെയ്യാൻ തീരുമാനിച്ചു JOIN.

കേസ് v12-ന് താഴെയുള്ള പതിപ്പുകൾക്കോ ​​അഭ്യർത്ഥനകൾക്കോ ​​പ്രസക്തമാണ് WITH MATERIALIZED.

എങ്ങനെ തിരിച്ചറിയാം

-> CTE Scan
   && loops > 10
   && loops × (rows + RRbF) > 10000
      -- слишком большое декартово произведение CTE

ശുപാർശകൾ

അഭ്യർത്ഥന ശ്രദ്ധാപൂർവ്വം വിശകലനം ചെയ്യുക - ഒപ്പം CTE കൾ ഇവിടെ ആവശ്യമുണ്ടോ?? അതെ എങ്കിൽ hstore/json-ൽ "നിഘണ്ടു" പ്രയോഗിക്കുക വിവരിച്ച മോഡൽ അനുസരിച്ച് PostgreSQL ആന്റിപാറ്റേണുകൾ: നമുക്ക് ഒരു നിഘണ്ടു ഉപയോഗിച്ച് കനത്ത JOIN അടിക്കുക.

#8: ഡിസ്കിലേക്ക് സ്വാപ്പ് ചെയ്യുക (ടെംപ് എഴുതിയത്)

എപ്പോൾ ചെയ്യുന്നു

ധാരാളം റെക്കോർഡുകളുടെ ഒറ്റത്തവണ പ്രോസസ്സിംഗ് (സോർട്ടിംഗ് അല്ലെങ്കിൽ അദ്വിതീയമാക്കൽ) ഇതിനായി നീക്കിവച്ചിരിക്കുന്ന മെമ്മറിയുമായി പൊരുത്തപ്പെടുന്നില്ല.

എങ്ങനെ തിരിച്ചറിയാം

-> *
   && temp written > 0

ശുപാർശകൾ

ഓപ്പറേഷൻ ഉപയോഗിക്കുന്ന മെമ്മറിയുടെ അളവ് പരാമീറ്ററിന്റെ നിർദ്ദിഷ്ട മൂല്യത്തെ കവിയുന്നില്ലെങ്കിൽ ജോലി_മെം, അത് തിരുത്തുന്നത് മൂല്യവത്താണ്. നിങ്ങൾക്ക് ഉടനടി എല്ലാവർക്കുമായി കോൺഫിഗറിലേക്ക് പോകാം, അല്ലെങ്കിൽ നിങ്ങൾക്ക് കഴിയും SET [LOCAL] ഒരു നിർദ്ദിഷ്ട അഭ്യർത്ഥന/ഇടപാടിന്.

ഉദാഹരണം:

SHOW work_mem;
-- "16MB"

SELECT
  random()
FROM
  generate_series(1, 1000000)
ORDER BY
  1;

[explain.tensor.ru-ൽ കാണുക]

തിരുത്തുന്നു:

SET work_mem = '128MB'; -- перед выполнением запроса

[explain.tensor.ru-ൽ കാണുക]

വ്യക്തമായ കാരണങ്ങളാൽ, ഡിസ്കല്ല മെമ്മറി മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ എങ്കിൽ, ചോദ്യം വളരെ വേഗത്തിൽ നടപ്പിലാക്കും. അതേ സമയം, എച്ച്ഡിഡിയിൽ നിന്നുള്ള ലോഡിന്റെ ഒരു ഭാഗവും നീക്കംചെയ്യുന്നു.

എന്നാൽ നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും ധാരാളം മെമ്മറി അനുവദിക്കാൻ കഴിയില്ലെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട് - എല്ലാവർക്കും മതിയാകില്ല.

#9: അപ്രസക്തമായ സ്ഥിതിവിവരക്കണക്കുകൾ

എപ്പോൾ ചെയ്യുന്നു

അവർ ഒരേസമയം ഡാറ്റാബേസിലേക്ക് ധാരാളം പകർന്നു, പക്ഷേ അത് ഓടിക്കാൻ സമയമില്ല ANALYZE.

എങ്ങനെ തിരിച്ചറിയാം

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && ratio >> 10

ശുപാർശകൾ

അത് നടപ്പിലാക്കുക ANALYZE.

ഈ സാഹചര്യം കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു PostgreSQL ആന്റിപാറ്റേണുകൾ: സ്ഥിതിവിവരക്കണക്കുകളാണ് എല്ലാം.

#10: "എന്തോ കുഴപ്പം സംഭവിച്ചു"

എപ്പോൾ ചെയ്യുന്നു

ഒരു മത്സരാധിഷ്ഠിത അഭ്യർത്ഥന ചുമത്തിയ ലോക്കിനായി ഒരു കാത്തിരിപ്പുണ്ടായിരുന്നു, അല്ലെങ്കിൽ മതിയായ CPU/ഹൈപ്പർവൈസർ ഹാർഡ്‌വെയർ ഉറവിടങ്ങൾ ഇല്ലായിരുന്നു.

എങ്ങനെ തിരിച്ചറിയാം

-> *
   && (shared hit / 8K) + (shared read / 1K) < time / 1000
      -- RAM hit = 64MB/s, HDD read = 8MB/s
   && time > 100ms -- читали мало, но слишком долго

ശുപാർശകൾ

ബാഹ്യമായി ഉപയോഗിക്കുക നിരീക്ഷണ സംവിധാനം തടയുന്നതിനോ അസാധാരണമായ വിഭവ ഉപഭോഗത്തിനോ ഉള്ള സെർവർ. നൂറുകണക്കിന് സെർവറുകൾക്കായി ഈ പ്രക്രിയ സംഘടിപ്പിക്കുന്നതിനുള്ള ഞങ്ങളുടെ പതിപ്പിനെക്കുറിച്ച് ഞങ്ങൾ ഇതിനകം സംസാരിച്ചു ഇവിടെ и ഇവിടെ.

അവലംബം: www.habr.com