PostgreSQL Query Profiler- အစီအစဉ်နှင့် စုံစမ်းမှု မည်ကဲ့သို့ ကိုက်ညီမည်နည်း။

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

... သက်ဆိုင်ရာ အစီအစဉ် ဆုံမှတ်များအတွက် ဆက်စပ်မှုရှိသော အရိပ်အမြွက်များဖြင့် လှပစွာ ဒီဇိုင်းဆွဲထားသော မေးခွန်းတစ်ခုသို့ ...

ဤစာစု၏ ဒုတိယပိုင်းကို သူ၏ မှတ်တမ်းတွင် ဖော်ပြထားသည်။ PGConf.Russia 2020 တွင် အစီရင်ခံစာ ဒါကိုဘယ်လိုလုပ်ရမလဲဆိုတာ ပြောပြမယ်။

ပုံမှန်မေးမြန်းမှု စွမ်းဆောင်ရည် ပြဿနာများနှင့် ၎င်းတို့၏ ဖြေရှင်းချက်များကို ဆောင်းပါးတွင် တွေ့ရှိနိုင်သည်၊ ပထမပိုင်း၏ စာသားမှတ်တမ်းကို "နာမကျန်းဖြစ်နေသော SQL မေးခွန်းများအတွက် ချက်ပြုတ်နည်းများ".

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

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


အထူးသဖြင့် developer များသည် ကုဒ်တွင် တောင်းဆိုချက်၏ကိုယ်ထည်ကို “ကော်” ထားသောအခါ (ဒါက၊ ဟုတ်ပါတယ်၊ ဆန့်ကျင်ဘက်ပုံစံ၊ ဒါပေမယ့် အဲဒါက) တစ်ကြောင်းတည်းနဲ့ ဖြစ်သွားတာ။ ကြောက်စရာကောင်းသော!

ဒါကို တစ်နည်းနည်းနဲ့ ပိုလှအောင် ဆွဲကြည့်ရအောင်။


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

Query syntax tree

ဒီလိုလုပ်ဖို့၊ တောင်းဆိုချက်ကို ဦးစွာခွဲခြမ်းစိတ်ဖြာရပါမယ်။


ဘာဖြစ်လို့လဲဆိုတော့ ငါတို့မှာရှိတယ်။ စနစ်၏ core သည် NodeJS တွင်အလုပ်လုပ်သည်။ပြီးတော့ အဲဒါအတွက် module တစ်ခုလုပ်တယ်၊ မင်းလုပ်နိုင်တယ်။ GitHub တွင်ရှာပါ။. အမှန်မှာ၊ ၎င်းတို့သည် PostgreSQL parser ကိုယ်တိုင်၏ အတွင်းပိုင်းသို့ “စည်းနှောင်မှုများ” ကို တိုးချဲ့ထားသည်။ ဆိုလိုသည်မှာ သဒ္ဒါသည် ရိုးရိုး binary compiled ဖြစ်ပြီး ၎င်းကို NodeJS မှ binding လုပ်ထားသည်။ အခြားသူများ၏ module များကိုအခြေခံအဖြစ်ကျွန်ုပ်တို့ယူခဲ့သည် - ဤနေရာတွင်ကြီးမားသောလျှို့ဝှက်ချက်မရှိပါ။

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


ယခု ကျွန်ုပ်တို့သည် ဤသစ်ပင်ကို ဆန့်ကျင်ဘက်လမ်းကြောင်းအတိုင်း ဖြတ်ပြေးနိုင်ပြီး ကျွန်ုပ်တို့လိုချင်သော အင်တင်းများ၊ အရောင်ခြယ်ခြင်းနှင့် ဖော်မတ်ချခြင်းတို့ဖြင့် တောင်းဆိုချက်တစ်ခုကို စုစည်းနိုင်ပါပြီ။ မဟုတ်ဘူး၊ ဒါက စိတ်ကြိုက်ပြင်ဆင်လို့ မရပေမယ့် ဒါက အဆင်ပြေမယ်လို့ ထင်ရတယ်။

မြေပုံထုတ်ခြင်း စုံစမ်းမေးမြန်းခြင်း နှင့် အစီအစဥ် ဆုံမှတ်များ

အခု ပထမအဆင့်မှာ ခွဲခြမ်းစိတ်ဖြာထားတဲ့ အစီအစဉ်နဲ့ ဒုတိယပိုင်းမှာ ခွဲခြမ်းစိတ်ဖြာထားတဲ့ မေးခွန်းကို ဘယ်လိုပေါင်းစပ်နိုင်မလဲဆိုတာ ကြည့်ကြရအောင်။

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

CTE

ဂရုတစိုက်ကြည့်လျှင် ဗားရှင်း 12 အထိ (သို့မဟုတ် ၎င်းကို သော့ချက်စာလုံးဖြင့် စတင်သည်။ MATERIALIZED) ဖွဲ့စည်းမှု CTE သည် အစီအစဉ်ရေးဆွဲသူအတွက် လုံးဝအတားအဆီးတစ်ခုဖြစ်သည်။.


ဆိုလိုတာက တောင်းဆိုချက်ထဲမှာ တစ်နေရာရာမှာ CTE မျိုးဆက်နဲ့ အစီအစဉ်ရဲ့ တစ်နေရာရာမှာ ဆုံချက်တစ်ခုကို တွေ့ရင်၊ CTEဒါဆို ဒီ node တွေက တစ်ခုနဲ့တစ်ခု "တိုက်" မှာ သေချာပါတယ်၊ ငါတို့က အဲဒါတွေကို ချက်ချင်းပေါင်းစပ်လို့ရတယ်။

ခရေပွင့်နှင့် ပြဿနာ: CTEs များကို nested လုပ်နိုင်ပါသည်။

အလွန်ညံ့ဖျင်းသော အသိုက်များရှိပြီး နာမည်တူများပင် ရှိပါသည်။ ဥပမာအားဖြင့်, သင်သည်အထဲမှာနိုင်ပါတယ်။ CTE A အောင် CTE Xအထဲမှာ နဲ့ အတူတူပါပဲ။ CTE B ထပ်လုပ်ပါ။ CTE X:

WITH A AS (
  WITH X AS (...)
  SELECT ...
)
, B AS (
  WITH X AS (...)
  SELECT ...
)
...

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

ပြည်ထောင်စု

အကယ်၍ ကျွန်ုပ်တို့တွင် သော့ချက်စာလုံးတစ်ခုရှိလျှင် UNION [ALL] (နမူနာနှစ်ခုပါဝင်သည့် အော်ပရေတာ)၊ ထို့နောက် အစီအစဉ်တွင် ၎င်းသည် node တစ်ခုနှင့်တစ်ခု သက်ဆိုင်သည်။ Appendသို့မဟုတ် အချို့ Recursive Union.


"အထက်" ဟူသည်ကား၊ UNION - ဤသည်မှာ ကျွန်ုပ်တို့၏ node ၏ ပထမမျိုးဆက်ဖြစ်ပြီး၊ "အောက်" - ဒုတိယဖြစ်သည်။ ဖြတ်သွားလျှင် UNION တစ်ချိန်တည်းတွင် "ကော်" လုပ်ကွက်များစွာရှိသည်။ Append- node တစ်ခုသာရှိပါလိမ့်မည်၊ သို့သော် ၎င်းတွင် နှစ်ခုမဟုတ်၊ ကလေးများများစွာရှိလိမ့်မည် - အသီးသီးအလိုက်၊

  (...) -- #1
UNION ALL
  (...) -- #2
UNION ALL
  (...) -- #3

Append
  -> ... #1
  -> ... #2
  -> ... #3

ခရေပွင့်နှင့် ပြဿနာ: recursive sampling မျိုးဆက်အတွင်း (WITH RECURSIVE) တစ်ခုထက်ပိုနိုင်သည်။ UNION. ဒါပေမယ့် နောက်ဆုံးတစ်ခုပြီးရင် နောက်ဆုံးတစ်တုံးကသာ အမြဲတမ်း ပြန်လှည့်ပတ်နေတယ်။ UNION. အထက်ဖော်ပြပါအရာအားလုံးသည် တစ်ခုတည်းဖြစ်သော်လည်း ကွဲပြားသည်။ UNION:

WITH RECURSIVE T AS(
  (...) -- #1
UNION ALL
  (...) -- #2, тут кончается генерация стартового состояния рекурсии
UNION ALL
  (...) -- #3, только этот блок рекурсивный и может содержать обращение к T
)
...

သင်သည်ထိုကဲ့သို့သောဥပမာများကို "ထွက်" နိုင်ရန်လိုအပ်သည်။ ဒီဥပမာမှာ ကျွန်တော်မြင်ပါတယ်။ UNION- ကျွန်ုပ်တို့၏ တောင်းဆိုချက်တွင် အပိုင်း ၃ ပိုင်းရှိသည်။ အရှက်ကြီး၊ UNION ကိုက်ညီ Append-node နှင့် အခြား - Recursive Union.

ဒေတာဖတ်-ရေး

အားလုံးပြင်ဆင်ပြီးပါပြီ၊ မည်သည့်တောင်းဆိုချက်၏အပိုင်းသည် မည်သည့်အစီအစဉ်၏အပိုင်းနှင့် ကိုက်ညီသည်ကို ကျွန်ုပ်တို့သိပါသည်။ ဤအပိုင်းများတွင် ကျွန်ုပ်တို့သည် “ဖတ်ရှုနိုင်သော” အရာဝတ္ထုများကို အလွယ်တကူနှင့် သဘာဝအတိုင်း ရှာဖွေနိုင်သည်။

စုံစမ်းမှု ရှုထောင့်မှ ကြည့်လျှင် ၎င်းသည် ဇယား သို့မဟုတ် CTE ဖြစ်သည်ကို ကျွန်ုပ်တို့ မသိသော်လည်း ၎င်းတို့ကို တူညီသော node မှ သတ်မှတ်ပေးထားသည်။ RangeVar. “ဖတ်ရှုနိုင်မှု” ၏ စည်းကမ်းချက်များအရ၊ ၎င်းသည် မျှမျှတတ ကန့်သတ်ထားသော node များဖြစ်သည်-

• Seq Scan on [tbl]
• Bitmap Heap Scan on [tbl]
• Index [Only] Scan [Backward] using [idx] on [tbl]
• CTE Scan on [cte]
• Insert/Update/Delete on [tbl]

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


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


အစီအစဥ်ကို ကြည့်လိုက်တော့ ပြဿနာက ဘာလဲ။ ကျွန်ုပ်တို့တွင် အဘယ်ကြောင့် အမည်နာမတစ်ခုရှိသနည်း။ ငါတို့က အမိန့်မပေးဘူး။ ဤကဲ့သို့သော "နံပါတ်နံပါတ်" ကိုဘယ်မှာရသနည်း။

PostgreSQL က ၎င်းကို သူ့ဘာသာသူ ထည့်သည်။ အဲဒါကို နားလည်ဖို့ပဲလိုတယ်။ အဲဒီလို နာမည်ပေးရုံပါပဲ။ ကျွန်ုပ်တို့အတွက်၊ အစီအစဉ်နှင့် နှိုင်းယှဉ်ရန် ရည်ရွယ်ချက်အတွက်၊ ၎င်းသည် အဓိပ္ပါယ်မရှိပါ၊ ၎င်းကို ဤနေရာတွင် ရိုးရှင်းစွာ ထည့်သွင်းထားသည်။ သူ့ကို ဂရုမစိုက်ရအောင်။

ဒုတိယ တာဝန် "ကြယ်ပွင့်": အကယ်၍ ကျွန်ုပ်တို့သည် အပိုင်းပိုင်းခွဲထားသောဇယားမှ ဖတ်နေပါက၊ ကျွန်ုပ်တို့သည် node တစ်ခုရလိမ့်မည်။ Append သို့မဟုတ် Merge Append"ကလေးများ" အများအပြားပါ ၀ င်မည့်၊ တစ်ခုချင်းစီသည်တစ်နည်းနည်းဖြင့်ဖြစ်လိမ့်မည်။ Scan'om't table-section မှ Seq Scan, Bitmap Heap Scan သို့မဟုတ် Index Scan. မည်သို့ပင်ဆိုစေကာမူ ဤ "ကလေးများ" သည် ရှုပ်ထွေးသောမေးခွန်းများမဟုတ်ပါ - ဤသည်မှာ ဤဆုံမှတ်များကို မည်သို့ခွဲခြားနိုင်မည်နည်း။ Append တွင် UNION.


ကျွန်ုပ်တို့လည်း ထိုထုံးများကို နားလည်ပြီး ၎င်းတို့ကို "တစ်ပုံတည်း" စုစည်းပြီး ပြောပါ- "သင် megatable မှဖတ်သမျှအရာအားလုံးသည်ဤတွင်နှင့်သစ်ပင်အောက်တွင်ရှိသည်။".

"ရိုးရှင်း" ဒေတာလက်ခံခြင်း nodes

Values Scan အစီအစဉ်တွင် ကိုက်ညီပါသည်။ VALUES တောင်းဆိုမှု၌။

Result မပါဘဲတောင်းဆိုမှုတစ်ခုဖြစ်သည်။ FROM ကဲ့သို့ SELECT 1. ဒါမှမဟုတ် တမင်တကာ လွဲမှားတဲ့ အသုံးအနှုန်းတွေ ရှိနေတဲ့အခါ WHERE-block (ထိုအခါ attribute ပေါ်လာသည်။ One-Time Filter):

EXPLAIN ANALYZE
SELECT * FROM pg_class WHERE FALSE; -- или 0 = 1

Result  (cost=0.00..0.00 rows=0 width=230) (actual time=0.000..0.000 rows=0 loops=1)
  One-Time Filter: false

Function Scan နာမည်တူ SRF များအတွက် "မြေပုံ"

သို့သော် အစုလိုက်အပြုံလိုက် စုံစမ်းမှုများဖြင့် အရာအားလုံးသည် ပိုမိုရှုပ်ထွေးသည် - ကံမကောင်းစွာဖြင့်၊ ၎င်းတို့သည် အမြဲတမ်းအဖြစ်သို့ ပြောင်းလဲသွားခြင်းမရှိပေ။ InitPlan/SubPlan. တခါတရံ အဖြစ်သို့ ပြောင်းသွားကြသည်။ ... Join သို့မဟုတ် ... Anti Joinအထူးသဖြင့် သင်ကြိုက်တဲ့အရာတစ်ခုကို ရေးပါ။ WHERE NOT EXISTS .... ဤနေရာတွင် ၎င်းတို့ကို ပေါင်းစည်းရန် အမြဲတမ်း မဖြစ်နိုင်ပါ - အစီအစဉ်၏ စာသားတွင် အစီအစဉ်၏ node များနှင့် သက်ဆိုင်သည့် အော်ပရေတာများ မရှိပါ။

တဖန် တာဝန် "ကြယ်ပွင့်": အချို့ VALUES တောင်းဆိုမှု၌။ ဤကိစ္စတွင်နှင့် အစီအစဉ်တွင် သင်သည် node အများအပြားကို ရရှိမည်ဖြစ်သည်။ Values Scan.


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

ဒေတာအပြောင်းအလဲနဲ့

ကျွန်ုပ်တို့၏တောင်းဆိုမှုတွင် အရာအားလုံးကို ခွဲထုတ်လိုက်ပုံပေါ်သည် - ကျန်တာအားလုံးပါပဲ။ Limit.


သို့သော် ဤနေရာတွင် အရာအားလုံးသည် ရိုးရှင်းသည် - ထိုကဲ့သို့သော nodes များဖြစ်သည်။ Limit, Sort, Aggregate, WindowAgg, Unique တောင်းဆိုချက်တွင် သက်ဆိုင်ရာ အော်ပရေတာများထံ “မြေပုံ” ကို တစ်ပုံမှတစ်ပုံ၊ ဤနေရာတွင် "ကြယ်များ" သို့မဟုတ် အခက်အခဲများ မရှိပါ။

JOIN

ပေါင်းစည်းလိုသောအခါတွင် အခက်အခဲများ ဖြစ်ပေါ်လာသည်။ JOIN သူတို့အချင်းချင်းကြား။ ဒါက အမြဲတမ်းမဖြစ်နိုင်ပေမယ့် ဖြစ်နိုင်တယ်။


query parser ၏အမြင်မှ၊ ကျွန်ုပ်တို့တွင် node တစ်ခုရှိသည်။ JoinExprဘယ်ညာ၊ ကလေး နှစ်ယောက်တိတိရှိသည်။ ဤသည်မှာ သင့် JOIN ၏ "အထက်" နှင့် တောင်းဆိုချက်တွင် ၎င်းကို "အောက်တွင်" ရေးထားသည့်အရာဖြစ်သည်။

အစီအစဥ်အမြင်အရ၊ ၎င်းတို့သည် အချို့သော သားစဉ်မြေးဆက် နှစ်ဦးဖြစ်သည်။ * Loop/* Join-node ။ Nested Loop, Hash Anti Joinဟီး... - တစ်ခုခုပေါ့။

ရိုးရှင်းသောယုတ္တိကိုသုံးကြပါစို့- အစီအစဉ်တွင် ကျွန်ုပ်တို့တွင် တစ်ခုနှင့်တစ်ခု "ပူးပေါင်း" သောဇယားများ A နှင့် B ရှိပါက၊ တောင်းဆိုချက်တွင် ၎င်းတို့ကို ရှာဖွေတွေ့ရှိနိုင်သည်။ A-JOIN-Bသို့မဟုတ် B-JOIN-A. ဒီနည်းနဲ့ ပေါင်းစပ်လိုက်ရအောင်၊ တခြားနည်းနဲ့ ပေါင်းစပ်လိုက်ရအောင်၊ အဲလိုအတွဲတွေ မကုန်မချင်း ပေါင်းလိုက်ကြရအောင်။

ငါတို့ရဲ့ syntax tree ကိုယူရအောင်၊ ငါတို့အစီအစဉ်ကိုယူ၊ အဲဒါတွေကိုကြည့်ရအောင်... အလားတူမဟုတ်ဘူး!


ဂရပ်ပုံစံနဲ့ ပြန်ဆွဲကြည့်ရအောင် - အိုး၊ အဲဒါက တစ်ခုခုနဲ့တူနေပြီ။


ကျွန်ုပ်တို့တွင် B နှင့် C ကလေးများ တစ်ပြိုင်နက်တည်းရှိသော node များရှိသည်ကို သတိပြုကြပါစို့ - ကျွန်ုပ်တို့သည် မည်သည့်နည်းနှင့်မျှ ဂရုမစိုက်ပါ။ ၎င်းတို့ကို ပေါင်းစပ်ပြီး node ၏ပုံကို လှန်ကြည့်ကြပါစို့။


ထပ်ကြည့်ရအောင်။ ယခု ကျွန်ုပ်တို့တွင် ကလေး A နှင့် အတွဲများ (B + C) ပါရှိသည် - ၎င်းတို့နှင့်လည်း လိုက်ဖက်ပါသည်။


မိုက်တယ်! ငါတို့က ဒီနှစ်ယောက်ပဲ ပေါ်လာတာ။ JOIN အစီအစဉ် node များနှင့် တောင်းဆိုမှုမှ အောင်မြင်စွာ ပေါင်းစပ်ခဲ့သည်။

ကံမကောင်းစွာပဲ၊ ဒီပြဿနာကိုအမြဲမဖြေရှင်းနိုင်ပါ။


ဥပမာအားဖြင့် တောင်းဆိုမှုတစ်ခု၌ A JOIN B JOIN Cအစီအစဉ်တွင် ဦးစွာပထမအနေဖြင့် “အပြင်ဘက်” ဆုံမှတ် A နှင့် C တို့ကို ချိတ်ဆက်ထားသည်။ သို့သော် တောင်းဆိုချက်တွင် ထိုသို့သောအော်ပရေတာမရှိပါ၊ ကျွန်ုပ်တို့တွင် မီးမောင်းထိုးပြစရာဘာမျှမရှိ၊ အရိပ်အမြွက်တင်ပြစရာမရှိပါ။ စာရေးတဲ့အခါ "ကော်မာ" နဲ့ အတူတူပါပဲ။ A, B.

သို့သော်၊ ကိစ္စအများစုတွင်၊ node များအားလုံးနီးပါးကို "ချိတ်" နိုင်ပြီး JavaScript ကုဒ်ကိုခွဲခြမ်းစိတ်ဖြာသောအခါတွင် Google Chrome ကဲ့သို့စာသားအရ၊ ဤပရိုဖိုင်ကိုဘယ်ဘက်တွင်အချိန်မီရနိုင်သည်။ စာကြောင်းတစ်ခုစီနှင့် ထုတ်ပြန်ချက်တစ်ခုစီသည် "execute" လုပ်ရန် အချိန်မည်မျှကြာသည်ကို သင်မြင်နိုင်သည်။


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

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

source: www.habr.com