နာမကျန်းဖြစ်နေသော SQL မေးခွန်းများအတွက် ချက်ပြုတ်နည်းများ

လအနည်းငယ်အကြာ ငါတို့ကြေငြာတယ်။ ရှင်းပြ.tensor.ru - အများသူငှာ မေးမြန်းမှုအစီအစဉ်များကို ခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် ပုံဖော်ခြင်းအတွက် ဝန်ဆောင်မှု PostgreSQL သို့

သင် အကြိမ်ပေါင်း 6000 ကျော် အသုံးပြုပြီးသော်လည်း သတိမပြုမိဘဲ အသုံးဝင်သော အင်္ဂါရပ်တစ်ခုမှာ၊ ဖွဲ့စည်းပုံဆိုင်ရာ သဲလွန်စများ၊ ဤကဲ့သို့သောပုံရသည်-

၎င်းတို့ကို နားထောင်ပါ၊ သင်၏တောင်းဆိုချက်များသည် “ချောမွေ့၍ ချောမွေ့လာလိမ့်မည်” 🙂

သို့သော် လေးလေးနက်နက်၊ တောင်းဆိုမှုနှေးကွေးပြီး အရင်းအမြစ်ဆာလောင်မှုဖြစ်စေသည့် အခြေအနေများစွာရှိသည်။ ပုံမှန်ဖြစ်ကြပြီး အစီအစဉ်၏ဖွဲ့စည်းပုံနှင့် အချက်အလက်များဖြင့် အသိအမှတ်ပြုနိုင်ပါသည်။.

ဤကိစ္စတွင်၊ ဆော့ဖ်ဝဲရေးသားသူ တစ်ဦးစီတိုင်းသည် ၎င်း၏ အတွေ့အကြုံအပေါ်သာ အားကိုး၍ ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန် ရွေးချယ်စရာကို ရှာဖွေရန် မလိုအပ်ပါ - ဤနေရာတွင် ဖြစ်ပျက်နေသည်များ၊ အဘယ်အရာ ဖြစ်နိုင်သည်ကို ကျွန်ုပ်တို့ ပြောပြနိုင်သည်၊ အဖြေရှာနည်း. အဲဒါ ငါတို့လုပ်ခဲ့တာ။

ဤကိစ္စများကို အနီးကပ်လေ့လာကြည့်ကြပါစို့ - ၎င်းတို့ကို မည်သို့သတ်မှတ်ထားသနည်း နှင့် မည်သို့သော အကြံပြုချက်များကို ဦးတည်စေမည်နည်း။

ခေါင်းစဉ်တွင် သင့်ကိုယ်သင် ပိုမိုကောင်းမွန်စွာ နှစ်မြှုပ်နိုင်ရန်၊ သက်ဆိုင်ရာ ဘလောက်ကို ဦးစွာ နားထောင်နိုင်သည်။ PGConf.Russia 2020 တွင် ကျွန်ုပ်၏အစီရင်ခံစာပြီးမှသာလျှင် ဥပမာတစ်ခုစီ၏ အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာမှုသို့ ဆက်သွားပါ-

နံပါတ် 1- အညွှန်း "အောက်ခွဲခြင်း"

ဘယ်အချိန်မှာ လာသလဲ။

client "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- အညွှန်းလမ်းဆုံ (BitmapAnd)

ဘယ်အချိန်မှာ လာသလဲ။

"NAO Buttercup" ကိုယ်စား နိဂုံးချုပ်ထားသော client "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 တွင်ကြည့်ရှုရန်]

Bitmap Heap Scan သည် သူ့ဘာသာသူ အတော်လေး ထိရောက်သောကြောင့် ဤနေရာတွင် ပေးချေမှုမှာ သေးငယ်ပါသည်။ ဒါပေမယ့် ဘာပဲဖြစ်ဖြစ် 7 ဆ ပိုမြန်ပြီး 2.5 ဆ ပိုနည်းပါတယ်။.

#3- အညွှန်းကိန်းများ ပေါင်းစည်းခြင်း (BitmapOr)

ဘယ်အချိန်မှာ လာသလဲ။

ပထမဆုံး အသက်အကြီးဆုံး “ကျွန်ုပ်တို့” သို့မဟုတ် လုပ်ဆောင်ရန် တာဝန်မပေးသေးသော တောင်းဆိုချက် 20 ကို သင့်ဦးစားပေးဖြင့် ပြပါ။

ခွဲခြားနည်း

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

အကြံပြုချက်များ

အသုံးပြုပါ သမဂ္ဂ [အားလုံး] အခြေအနေများ၏ OR-တုံးတစ်ခုစီအတွက် subqueries များပေါင်းစပ်ရန်။

ဥပမာ:

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 ခုစလုံးကို ချက်ချင်းလက်ခံရရှိသောကြောင့် ကျွန်ုပ်တို့သည် အခွင့်ကောင်းယူ၍ ဒုတိယ၊ ပိုစျေးကြီးသော Bitmap Heap Scan ဖြင့် အဆုံးတွင်ပင် မလုပ်ဆောင်နိုင်ခဲ့ပါ။ ၂၂ ဆ ပိုမြန်သည်၊ ဖတ်ရှုမှု ၄၄ ဆ ပိုနည်းသည်။!

ဤ optimization နည်းလမ်းအကြောင်း နောက်ထပ်အသေးစိတ်အကြောင်းအရာ သီးခြားဥပမာများကို အသုံးပြု ဆောင်းပါးများတွင် ဖတ်ရှုနိုင်ပါသည်။ PostgreSQL Antipatterns- အန္တရာယ်ရှိသော Joins များနှင့် OR များ и PostgreSQL Antipatterns- အမည်ဖြင့် ရှာဖွေမှု၏ ထပ်တလဲလဲ သန့်စင်မှု ပုံပြင် သို့မဟုတ် "အကောင်းဆုံးဖြစ်အောင် အပြန်ပြန်အလှန်လှန်".

အထွေထွေဗားရှင်း သော့များစွာကို အခြေခံ၍ ရွေးချယ်မှုကို အမိန့်ပေးသည်။ (နှင့် const/NULL အတွဲများသာမက) ဆောင်းပါးတွင် ဆွေးနွေးထားသည်။ SQL HowTo- query တွင် ခဏတစ်ဖြုတ် လှည့်ပတ်ရေးသားခြင်း သို့မဟုတ် "မူလတန်း အဆင့်သုံးဆင့်".

#4: မလိုအပ်တဲ့အရာတွေ အများကြီးဖတ်တယ်။

ဘယ်အချိန်မှာ လာသလဲ။

စည်းကမ်းအတိုင်း၊ သင်သည် ရှိပြီးသားတောင်းဆိုချက်တစ်ခုတွင် "အခြား filter များကို ပူးတွဲပါ" လိုသောအခါတွင် ဖြစ်ပေါ်လာပါသည်။

"ဒါပေမယ့် မင်းမှာ အတူတူ မရှိဘူး။ အမိ-ပုလဲခလုတ်များဖြင့်? » "The Diamond Arm" ရုပ်ရှင်၊

ဥပမာအားဖြင့်၊ အထက်ဖော်ပြပါလုပ်ငန်းကို မွမ်းမံပြင်ဆင်ခြင်း၊ ၎င်းတို့၏ရည်ရွယ်ချက် မည်သို့ပင်ရှိစေကာမူ လုပ်ဆောင်ခြင်းအတွက် ရှေးအကျဆုံး "အရေးပါသော" တောင်းဆိုချက် 20 ခုကို ပြသပါ။

ခွဲခြားနည်း

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

အကြံပြုချက်များ

[more] အထူးပြု ဖန်တီးပါ။ WHERE အခြေအနေဖြင့် အညွှန်း သို့မဟုတ် အညွှန်းတွင် အပိုအကွက်များ ထည့်သွင်းပါ။

သင့်ရည်ရွယ်ချက်အတွက် filter condition သည် "static" ဖြစ်ပါက၊ ဆိုလိုသည်မှာ ချဲ့ထွင်ခြင်းကို မဆိုလိုပါ။ အနာဂတ်တွင်တန်ဖိုးများစာရင်း - WHERE အညွှန်းကိုသုံးခြင်းသည်ပိုကောင်းသည်။ အမျိုးမျိုးသော boolean/enum အခြေအနေများသည် ဤအမျိုးအစားတွင် သင့်လျော်ပါသည်။

စီစစ်ရင် အခြေအနေ အဓိပ္ပါယ်အမျိုးမျိုးကို ယူဆောင်နိုင်ပါတယ်။ထို့နောက် 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

အကြံပြုချက်များ

ကိုယ်တိုင်ပုံမှန်လုပ်ဆောင်ပါ။ ဖုန်စုပ်စက် [FULL] သို့မဟုတ် လုံလောက်သော မကြာခဏ လေ့ကျင့်မှု အောင်မြင်ပါစေ။ autovacuum အပါအဝင် ၎င်း၏ parameters များကို fine-tuning လုပ်ပါ။ သီးခြားစားပွဲတစ်ခုအတွက်.

ကိစ္စအများစုတွင်၊ ဆွေးနွေးထားသည့်အရာကဲ့သို့ လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒမှ ခေါ်ဆိုသောအခါတွင် ထိုသို့သောပြဿနာများသည် မေးမြန်းမှုဖွဲ့စည်းမှု ညံ့ဖျင်းခြင်းကြောင့် ဖြစ်ပေါ်လာခြင်းဖြစ်သည်။ PostgreSQL Antipatterns- "သေ" ၏အလုံးအရင်းကိုတိုက်ခိုက်သည်။.

ဒါပေမယ့် VACUUM FULL ကတောင် အမြဲတမ်း မကူညီနိုင်ဘူးဆိုတာ နားလည်ထားဖို့ လိုပါတယ်။ ထိုသို့သောကိစ္စများအတွက်၊ ဆောင်းပါးမှ algorithm ကိုသင်ကိုယ်တိုင်ရင်းနှီးကျွမ်းဝင်ရကျိုးနပ်သည်။ DBA- VACUUM ပျက်သွားသောအခါ၊ ကျွန်ုပ်တို့သည် စားပွဲကို ကိုယ်တိုင် သန့်ရှင်းရေးလုပ်ပါသည်။.

#6- အညွှန်း၏ "အလယ်" မှဖတ်ခြင်း။

ဘယ်အချိန်မှာ လာသလဲ။

ကျွန်ုပ်တို့ အနည်းငယ်ဖတ်ပြီး အရာအားလုံးကို အညွှန်းပြုထားပုံရပြီး မည်သူ့ကိုမျှ ပိုလျှံနေအောင် မစစ်ထုတ်ခဲ့ပါ - သို့သော် ကျွန်ုပ်တို့ နှစ်သက်သည်ထက် စာမျက်နှာများကို သိသိသာသာ ပိုဖတ်နေပါသည်။

ခွဲခြားနည်း

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

အကြံပြုချက်များ

အသုံးပြုထားသော အညွှန်း၏ဖွဲ့စည်းပုံနှင့် query တွင်ဖော်ပြထားသော အဓိကအကွက်များကို အနီးကပ်ကြည့်ရှုကြည့်ပါ - ဖြစ်နိုင်ချေအများဆုံး index ၏ အစိတ်အပိုင်းကို မသတ်မှတ်ထားပေ။. ဖြစ်နိုင်ချေ အများစုမှာ သင်သည် အလားတူ အညွှန်းတစ်ခုကို ဖန်တီးရန် လိုအပ်သော်လည်း ရှေ့ဆက်အကွက်များ သို့မဟုတ် မပါရှိပါ။ သူတို့ရဲ့တန်ဖိုးတွေကို ထပ်လောင်းလေ့လာပါ။.

ဥပမာ:

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 စာမျက်နှာ၊ မှတ်တမ်းတစ်ခုလျှင် 32KB ကို နုတ်ခဲ့ရသည် - ထိုမျှ ရဲတင်းသည်မဟုတ်လော။ အညွှန်းအမည် tbl_fk_org_fk_cli_idx တွေးစရာ။

ပြုပြင်ခြင်း-

CREATE INDEX ON tbl(fk_cli);

[explain.tensor.ru တွင်ကြည့်ရှုရန်]

ရုတ်တရက်- ၁၀ ဆ ပိုမြန်ပြီး ဖတ်ရန် ၄ ဆ ပိုနည်းသည်။!

အညွှန်းကိန်းများကို ထိရောက်စွာအသုံးပြုခြင်း၏ အခြားဥပမာများကို ဆောင်းပါးတွင် တွေ့မြင်နိုင်ပါသည်။ DBA- အသုံးမဝင်သော အညွှန်းများကို ရှာဖွေခြင်း။.

#7- CTE × CTE

ဘယ်အချိန်မှာ လာသလဲ။

တောင်းဆိုမှုတွင် "အဆီ" CTE ရမှတ် မတူညီသော စားပွဲများမှ၊ ထို့နောက် ၎င်းတို့ကြားတွင် ပြုလုပ်ရန် ဆုံးဖြတ်ခဲ့သည်။ JOIN.

အမှုသည် v12 အောက်ဗားရှင်းများ သို့မဟုတ် တောင်းဆိုမှုများနှင့် သက်ဆိုင်သည်။ WITH MATERIALIZED.

ခွဲခြားနည်း

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

အကြံပြုချက်များ

ဂရုတစိုက်တောင်းဆိုမှု - နှင့်ခွဲခြမ်းစိတ်ဖြာ ဤနေရာတွင် CTE များ လုံးဝလိုအပ်ပါသလား။? ဟုတ်တယ်ဆိုရင်ပေါ့။ hstore/json တွင် "dictionary" ကိုသုံးပါ။ တွင်ဖော်ပြထားသောပုံစံအတိုင်း PostgreSQL Antipatterns- လေးလံသော JOIN ကို အဘိဓာန်တစ်ခုဖြင့် ရိုက်လိုက်ကြပါစို့.

နံပါတ် ၈- ဒစ်ခ်သို့ လဲလှယ်ပါ (ရေးထားသော အပူချိန်)

ဘယ်အချိန်မှာ လာသလဲ။

မှတ်တမ်းအများအပြား၏ တစ်ကြိမ်တည်းလုပ်ဆောင်ခြင်း (စီခွဲခြင်း သို့မဟုတ် သီးသန့်ပြုလုပ်ခြင်း) သည် ၎င်းအတွက် ခွဲဝေပေးထားသည့် မမ်မိုရီတွင် အဆင်မပြေပါ။

ခွဲခြားနည်း

-> *
   && temp written > 0

အကြံပြုချက်များ

လုပ်ဆောင်ချက်က အသုံးပြုသည့် မမ်မိုရီပမာဏသည် သတ်မှတ်ထားသော ကန့်သတ်တန်ဖိုးထက် များစွာမကျော်လွန်ပါက၊ work_memပြင်ရကျိုးနပ်ပါတယ်။ လူတိုင်းအတွက် config တွင် သင်ချက်ချင်းလုပ်နိုင်သည်၊ သို့မဟုတ် သင်ဖြတ်သန်းနိုင်သည်။ 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 တွင်ကြည့်ရှုရန်]

ထင်ရှားသောအကြောင်းပြချက်များအတွက်၊ memory ကိုသာအသုံးပြုပြီး disk မဟုတ်ပါက၊ query ကိုပိုမိုမြန်ဆန်စွာလုပ်ဆောင်လိမ့်မည်။ တစ်ချိန်တည်းမှာပင်၊ HDD မှ load ၏တစ်စိတ်တစ်ပိုင်းကိုလည်းဖယ်ရှားသည်။

ဒါပေမယ့် သင်အမြဲမှတ်ဥာဏ်အများကြီးနဲ့ အများကြီးခွဲဝေပေးနိုင်မှာမဟုတ်ဘူးဆိုတာ နားလည်ထားဖို့လိုပါတယ် - လူတိုင်းအတွက် လုံလောက်မှာမဟုတ်ပါဘူး။

နံပါတ် ၉- မသက်ဆိုင်သော စာရင်းအင်းများ

ဘယ်အချိန်မှာ လာသလဲ။

၎င်းတို့သည် ဒေတာဘေ့စ်ထဲသို့ တစ်ကြိမ်တည်း အများအပြားထည့်ထားသော်လည်း ၎င်းကို မောင်းထုတ်ရန် အချိန်မရှိပေ။ ANALYZE.

ခွဲခြားနည်း

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

အကြံပြုချက်များ

ဆောင်သွားပါ။ ANALYZE.

ဒီအခြေအနေတွေကို အကျယ်တဝင့် ဖော်ပြပေးထားပါတယ်။ PostgreSQL Antipatterns- စာရင်းဇယားများသည် အရာအားလုံးဖြစ်သည်။.

#10: "တစ်ခုခုမှားနေပြီ"

ဘယ်အချိန်မှာ လာသလဲ။

ပြိုင်ဆိုင်မှုတောင်းဆိုမှုဖြင့် သော့ခတ်ရန် စောင့်ဆိုင်းရခြင်း သို့မဟုတ် CPU/hypervisor ဟာ့ဒ်ဝဲအရင်းအမြစ်များ မလုံလောက်ပါ။

ခွဲခြားနည်း

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

အကြံပြုချက်များ

ပြင်ပကိုသုံးပါ။ စောင့်ကြည့်ရေးစနစ် ပိတ်ဆို့ခြင်း သို့မဟုတ် ပုံမှန်မဟုတ်သော အရင်းအမြစ်သုံးစွဲမှုအတွက် ဆာဗာ။ ဆာဗာရာပေါင်းများစွာအတွက် ဤလုပ်ငန်းစဉ်ကို စီစဉ်ခြင်း၏ ကျွန်ုပ်တို့၏ဗားရှင်းအကြောင်း ကျွန်ုပ်တို့ ပြောဆိုထားပြီးဖြစ်သည်။ ဒီမှာ и ဒီမှာ.

source: www.habr.com