ProHoster > ဘလော့ > အုပ်ချုပ်ရေး > SQL စုံစမ်းစစ်ဆေးမှုတစ်ခု၏ဇာတ်လမ်း

SQL စုံစမ်းစစ်ဆေးမှုတစ်ခု၏ဇာတ်လမ်း

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

စောပိုငျးကာလ

ငါပြောနေတာတွေကို ရှင်းရှင်းလင်းလင်းသိရအောင် VWO အကြောင်း နည်းနည်းပြောပြမယ်။ ၎င်းသည် သင့်ဝဘ်ဆိုက်များပေါ်တွင် ပစ်မှတ်ထားသော ကမ်ပိန်းများကို အမျိုးမျိုးဖွင့်နိုင်သည့် ပလပ်ဖောင်းတစ်ခုဖြစ်သည်- A/B စမ်းသပ်မှုများ ပြုလုပ်ခြင်း၊ လာရောက်သူများနှင့် ဘာသာပြန်ဆိုမှုများကို ခြေရာခံခြင်း၊ အရောင်းလမ်းကြောင်းကို ပိုင်းခြားစိတ်ဖြာခြင်း၊ အပူမြေပုံများကို ပြသခြင်းနှင့် လည်ပတ်မှုမှတ်တမ်းများကို ဖွင့်ခြင်းတို့ ပြုလုပ်နိုင်ပါသည်။

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

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

Chrome OR (ဥရောပတွင်တည်ရှိပြီး iPhone သုံးသောသူများ) အတွက် <date d1> မှ <date d2> စာမျက်နှာ "abc.com" တွင် နှိပ်ခြင်းအားလုံးကို ပြပါ

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

တောင်းဆိုမှုနှေးကွေး

မေးခွန်းထုတ်သည့်ဖောက်သည်သည် အလိုလိုလျင်မြန်စွာ လုပ်ဆောင်သင့်သည့်အရာတစ်ခုကို လုပ်ဆောင်ရန် ကြိုးစားနေသည်-

"/jobs" ပါရှိသော URL ဖြင့် မည်သည့်စာမျက်နှာကိုမဆို ဝင်ကြည့်ခဲ့သော အသုံးပြုသူများအတွက် စက်ရှင်မှတ်တမ်းအားလုံးကို ပြပါ

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

ပဏာမစုံစမ်းစစ်ဆေးခြင်း။

Database ထဲမှာ ဘာတွေဖြစ်နေလဲ ကြည့်ရအောင်။ အောက်တွင်မူရင်းနှေးကွေးသော SQL မေးမြန်းမှုဖြစ်သည်-

SELECT 
    count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions 
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND sessions.referrer_id = recordings_urls.id 
    AND  (  urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]   ) 
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545177599) 
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0 ;

ဤသည်မှာ အချိန်ဇယားများဖြစ်သည်-

စီစဉ်ထားသောအချိန်- 1.480 ms အကောင်အထည်ဖော်ချိန်- 1431924.650 ms

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

တောင်းဆိုချက်ကို ဆက်လက်လေ့လာကြပါစို့။ မင်းမြင်တဲ့အတိုင်းပဲ။ JOIN စားပွဲသုံးလုံး

  1. အစည်းအဝေးများ: စက်ရှင်အချက်အလက်ကို ပြသရန်- ဘရောက်ဆာ၊ အသုံးပြုသူ အေးဂျင့်၊ နိုင်ငံ၊ စသည်ဖြင့်။
  2. recording_data: မှတ်တမ်းတင်ထားသော URL များ၊ စာမျက်နှာများ၊ လည်ပတ်မှုကြာချိန်
  3. url များ: အလွန်ကြီးမားသော URL များကို ပွားခြင်းမှ ရှောင်ကြဉ်ရန်၊ ၎င်းတို့ကို သီးခြားဇယားတွင် သိမ်းဆည်းပါသည်။

ကျွန်ုပ်တို့၏ဇယားအားလုံးကို ပိုင်းခြားထားပြီးဖြစ်ကြောင်းကိုလည်း သတိပြုပါ။ account_id. ဤနည်းအားဖြင့်၊ အထူးသဖြင့် ကြီးမားသောအကောင့်တစ်ခုသည် အခြားသူများအတွက် ပြဿနာဖြစ်စေသည့် အခြေအနေတစ်ခုကို ဖယ်ထုတ်ထားသည်။

သဲလွန်စရှာနေ

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

urls && array(
	select id from acc_{account_id}.urls 
	where url  ILIKE  '%enterprise_customer.com/jobs%'
)::text[]

ပထမ အတွေးက အဲဒါ ဖြစ်ကောင်းဖြစ်နိုင်လို့ ILIKE ဤရှည်လျားသော URL များအားလုံးတွင် (ကျွန်ုပ်တို့တွင် ၁.၄ သန်းကျော်ရှိသည်။ ထူးခြား ဤအကောင့်အတွက် စုဆောင်းထားသော URL များ) စွမ်းဆောင်ရည် ထိခိုက်နိုင်သည်။

ဒါပေမယ့် မဟုတ်ဘူး၊ အဲဒါက အဓိကမဟုတ်ဘူး!

SELECT id FROM urls WHERE url ILIKE '%enterprise_customer.com/jobs%';
  id
--------
 ...
(198661 rows)

Time: 5231.765 ms

နမူနာပုံစံရှာဖွေမှုတောင်းဆိုချက်ကိုယ်တိုင်က 5 စက္ကန့်သာကြာသည်။ ထူးခြားသော URL သန်းပေါင်းများစွာတွင် ပုံစံတစ်ခုကို ရှာဖွေခြင်းသည် ပြဿနာမဟုတ်သည်မှာ ရှင်းပါသည်။

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

analytics_db=# SELECT
    count(*)
FROM
    acc_{account_id}.urls as recordings_urls,
    acc_{account_id}.recording_data_0 as recording_data,
    acc_{account_id}.sessions_0 as sessions
WHERE
    recording_data.usp_id = sessions.usp_id
    AND sessions.referrer_id = recordings_urls.id
    AND r_time > to_timestamp(1542585600)
    AND r_time < to_timestamp(1545177599)
    AND recording_data.duration >=5
    AND recording_data.num_of_pages > 0 ;
 count
-------
  8086
(1 row)

Time: 147.851 ms

ပြီးတော့ ဒါက ငါတို့ကိစ္စမဟုတ်ဘူး။ JOINအတော်လေး မြန်လာခဲ့တယ်။

သံသယရှိသူအဝိုင်းကို ကျဉ်းမြောင်းစေပါသည်။

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

  • subquery URL အတွက် EXISTS ကိုသုံးပါ။: URLs များအတွက် subquery တွင် ပြဿနာတစ်စုံတစ်ရာ ရှိမရှိ ထပ်မံစစ်ဆေးလိုပါသည်။ ဒါကို အောင်မြင်ဖို့ နည်းလမ်းတစ်ခုကတော့ ရိုးရိုးရှင်းရှင်းပဲ သုံးတာပါပဲ။ EXISTS. EXISTS နိုင် အခြေအနေနှင့် ကိုက်ညီသော တစ်ခုတည်းသော စာကြောင်းကို တွေ့ရှိသည်နှင့် ၎င်းသည် ချက်ချင်းအဆုံးသတ်သွားသည့်အတွက် စွမ်းဆောင်ရည်ကို အလွန်တိုးတက်ကောင်းမွန်စေသည်။

SELECT
	count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls,
    acc_{account_id}.recording_data as recording_data,
    acc_{account_id}.sessions as sessions
WHERE
    recording_data.usp_id = sessions.usp_id
    AND  (  1 = 1  )
    AND sessions.referrer_id = recordings_urls.id
    AND  (exists(select id from acc_{account_id}.urls where url  ILIKE '%enterprise_customer.com/jobs%'))
    AND r_time > to_timestamp(1547585600)
    AND r_time < to_timestamp(1549177599)
    AND recording_data.duration >=5
    AND recording_data.num_of_pages > 0 ;
 count
 32519
(1 row)
Time: 1636.637 ms

အင်း ဟုတ်တယ်။ ထုပ်ပိုးပြီးသောအခါတွင် Subquery EXISTS၊ အရာအားလုံးကို အလွန်မြန်ဆန်စေသည်။ နောက်ယုတ္တိရှိသောမေးခွန်းမှာ အဘယ်ကြောင့်တောင်းဆိုမှုနှင့်အတူ JOIN-ami နှင့် subquery ကိုယ်တိုင်က တစ်ဦးချင်း လျင်မြန်သော်လည်း အတူတူ နှေးကွေးနေပါသလား။

  • subquery ကို CTE သို့ ရွှေ့ပါ။ : query သည် သူ့ဘာသာသူ မြန်ဆန်နေပါက၊ ကျွန်ုပ်တို့သည် အမြန်ရလဒ်ကို ဦးစွာတွက်ချက်ပြီး ပင်မမေးမြန်းမှုသို့ ပေးဆောင်နိုင်ပါသည်။

WITH matching_urls AS (
    select id::text from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%'
)

SELECT 
    count(*) FROM acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions,
    matching_urls
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND  (  1 = 1  )  
    AND sessions.referrer_id = recordings_urls.id
    AND (urls && array(SELECT id from matching_urls)::text[])
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545107599)
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0;

ဒါပေမယ့် အရမ်းနှေးနေသေးတယ်။

တရားခံကို ရှာဖွေခြင်း။

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

ကြည့်နေသည် စာရွက်စာတမ်းအဲဒါကို မြင်တယ်။ && array နှစ်ခုကြားတွင် ဘုံဒြပ်စင်များကို ရှာဖွေရန် လိုအပ်သောအခါတွင် အသုံးပြုသည်။

မူလတောင်းဆိုချက်တွင်၊

AND  (  urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]   )

ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ URL များပေါ်တွင် ပုံစံရှာဖွေမှုတစ်ခုပြုလုပ်ပြီးနောက် အများအားဖြင့် ပို့စ်များပါသည့် URL များအားလုံးနှင့် လမ်းဆုံကိုရှာပါ။ ဤနေရာတွင် "urls" သည် URLs များအားလုံးကို ပါဝင်သောဇယားကို ရည်ညွှန်းခြင်းမရှိသော်လည်း ဇယားရှိ "urls" ကော်လံကို ရည်ညွှန်းသောကြောင့် ၎င်းသည် အနည်းငယ်ရှုပ်ထွေးပါသည်။ recording_data.

သံသယတွေ တိုးလာနေတယ်။ &&ထုတ်ပေးထားသော စုံစမ်းမေးမြန်းမှု အစီအစဉ်တွင် ၎င်းတို့အတွက် အတည်ပြုချက်ကို ရှာဖွေရန် ကြိုးစားခဲ့သည်။ EXPLAIN ANALYZE (ကျွန်ုပ်တွင် သိမ်းဆည်းထားသော အစီအစဉ်တစ်ခု ရှိထားပြီးဖြစ်သော်လည်း၊ မေးမြန်းမှု အစီအစဉ်ရေးဆွဲသူများ၏ ပွင့်လင်းမြင်သာမှုကို နားလည်ရန် ကြိုးစားခြင်းထက် SQL တွင် စမ်းသပ်ခြင်းမှာ ပိုအဆင်ပြေပါသည်။)

Filter: ((urls && ($0)::text[]) AND (r_time > '2018-12-17 12:17:23+00'::timestamp with time zone) AND (r_time < '2018-12-18 23:59:59+00'::timestamp with time zone) AND (duration >= '5'::double precision) AND (num_of_pages > 0))
                           Rows Removed by Filter: 52710

စစ်ထုတ်မှုများမှ လိုင်းများစွာ ရှိခဲ့သည်။ &&. ဆိုလိုချင်တာက ဒီခွဲစိတ်မှုဟာ စျေးကြီးရုံသာမက အကြိမ်ပေါင်းများစွာလည်း လုပ်ဆောင်ခဲ့ပါတယ်။

အခြေအနေကို ခွဲထုတ်ပြီး ဒါကို စမ်းသပ်ခဲ့တယ်။

SELECT 1
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data_30 as recording_data_30, 
    acc_{account_id}.sessions_30 as sessions_30 
WHERE 
	urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]

ဤမေးခွန်းသည် နှေးကွေးသည်။ အကြောင်းမှာ၊ JOIN-s က မြန်ပြီး subqueries တွေက မြန်တယ်၊ ကျန်တာက တစ်ခုတည်းပဲ။ && အော်ပရေတာ။

ဤသည်မှာ အဓိကကျသော လုပ်ဆောင်ချက်တစ်ခုသာဖြစ်သည်။ ပုံစံတစ်ခုကို ရှာဖွေရန် ကျွန်ုပ်တို့သည် အမြဲတမ်း နောက်ခံ URL ဇယားတစ်ခုလုံးကို ရှာဖွေရန် လိုအပ်ပြီး လမ်းဆုံများကို အမြဲရှာဖွေရန် လိုအပ်ပါသည်။ ၎င်းတို့သည် ရည်ညွှန်းသော ID များသာဖြစ်သောကြောင့် URL မှတ်တမ်းများကို တိုက်ရိုက်ရှာဖွေ၍မရပါ။ urls.

အဖြေတစ်ခုဆီသို့

&& နှစ်ခုလုံးက ကြီးမားတာကြောင့် နှေးပါတယ်။ အစားထိုးလိုက်ရင် လုပ်ဆောင်ချက်က အတော်လေးမြန်ပါလိမ့်မယ်။ urls အပေါ် { "http://google.com/", "http://wingify.com/" }.

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

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

SELECT urls.url
FROM 
	acc_{account_id}.urls as urls,
	(SELECT unnest(recording_data.urls) AS id) AS unrolled_urls
WHERE
	urls.id = unrolled_urls.id AND
	urls.url  ILIKE  '%jobs%'

အစား JOIN syntax သည် ကျွန်ုပ်သည် subquery ကိုအသုံးပြုပြီး ချဲ့ထွင်ခဲ့သည်။ recording_data.urls array တွင် အခြေအနေအား တိုက်ရိုက်အသုံးချနိုင်စေရန် WHERE.

ဒီနေရာမှာ အရေးကြီးဆုံးက အဲဒါပါပဲ။ && ပေးထားသော ထည့်သွင်းမှုတွင် ကိုက်ညီသော URL ပါရှိမရှိ စစ်ဆေးရန် အသုံးပြုသည်။ အနည်းငယ်စွေပါက၊ ဤလုပ်ဆောင်ချက်သည် array (သို့မဟုတ် ဇယားတစ်ခု၏အတန်း) ၏ဒြပ်စင်များမှတစ်ဆင့် ရွေ့လျားနေသည်ကိုတွေ့နိုင်ပြီး အခြေအနေ (ကိုက်ညီမှု) ကိုတွေ့သောအခါ ရပ်သွားမည်ဖြစ်သည်။ မင်းကို ဘာမှမမှတ်မိဘူးလား? ကမ္မ၊ EXISTS.

ကတည်းက recording_data.urls subquery context ရဲ့ ပြင်ပကနေ ကိုးကားလို့ရတယ်။ EXISTS subquery ကို ၎င်းနှင့် ထုပ်ပိုးပါ။

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

SELECT 
    count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions 
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND  (  1 = 1  )  
    AND sessions.referrer_id = recordings_urls.id 
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545177599) 
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0
    AND EXISTS(
        SELECT urls.url
        FROM 
            acc_{account_id}.urls as urls,
            (SELECT unnest(urls) AS rec_url_id FROM acc_{account_id}.recording_data) 
            AS unrolled_urls
        WHERE
            urls.id = unrolled_urls.rec_url_id AND
            urls.url  ILIKE  '%enterprise_customer.com/jobs%'
    );

ပြီးခဲတဲ့ အချိန် Time: 1898.717 ms ဆင်နွှဲရမယ့်အချိန်?!

သိပ်မမြန်! ပထမဦးစွာ မှန်ကန်မှုကို စစ်ဆေးရန် လိုအပ်ပါသည်။ ငါအလွန်အမင်းသံသယဖြစ်ခဲ့သည်။ EXISTS အစောပိုင်းက ရပ်စဲရန် ယုတ္တိဗေဒကို ပြောင်းလဲခြင်းဖြင့် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ခြင်း တောင်းဆိုချက်တွင် ထင်ထင်ရှားရှားမဟုတ်သော အမှားတစ်ခုကို မထည့်ထားကြောင်း သေချာရန်လိုသည်။

ရိုးရှင်းသောစမ်းသပ်မှုတစ်ခုလုပ်ဆောင်ရန်ဖြစ်သည်။ count(*) မတူညီသောဒေတာအတွဲများစွာအတွက် အနှေးနှင့်အမြန်မေးခွန်းနှစ်ခုစလုံးတွင်။ ထို့နောက်၊ ဒေတာ၏ အသေးအမွှားအတွက်၊ ရလဒ်များအားလုံး မှန်ကြောင်း ကျွန်ုပ်ကိုယ်တိုင် အတည်ပြုပါသည်။

စမ်းသပ်မှုအားလုံးသည် အပြုသဘောဆောင်သော ရလဒ်များကို အမြဲပေးသည်။ အားလုံးပြင်ဆင်ပြီးပါပြီ။

သင်ခန်းစာများ

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

  1. Query အစီအစဉ်များသည် ဇာတ်လမ်းတစ်ခုလုံးကို မပြောပြသော်လည်း သဲလွန်စများကို ပေးစွမ်းနိုင်သည်။
  2. အဓိက သံသယရှိသူတွေဟာ အမြဲတမ်း တရားခံအစစ်တွေ မဟုတ်ပါဘူး။
  3. နှေးကွေးသောမေးခွန်းများကို ပိတ်ဆို့မှုများကို သီးခြားခွဲထုတ်နိုင်သည်။
  4. ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းအားလုံးသည် သဘာဝတွင် လျော့ချခြင်းမဟုတ်ပါ။
  5. ၏အသုံးပြုမှု EXISTဖြစ်နိုင်လျှင် ကုန်ထုတ်စွမ်းအား သိသိသာသာ တိုးလာနိုင်သည်။

ကောက်ချက်

ကျွန်ုပ်တို့သည် မေးမြန်းမှုအချိန်မှ ~24 မိနစ်မှ 2 စက္ကန့်သို့သွားသည် - သိသိသာသာ စွမ်းဆောင်ရည် တိုးလာပါသည်။ ဤဆောင်းပါးသည် ကြီးကြီးမားမား ထွက်ပေါ်လာသော်လည်း၊ ကျွန်ုပ်တို့ ပြုလုပ်ခဲ့သည့် စမ်းသပ်မှုအားလုံးသည် တစ်နေ့တည်းတွင် ဖြစ်ပျက်ခဲ့ပြီး အကောင်းဆုံးဖြစ်အောင် နှင့် စမ်းသပ်ရန် ၁.၅ နာရီမှ ၂ နာရီကြား အချိန်ယူခဲ့သည်ဟု ခန့်မှန်းရသည်။

SQL သည် ၎င်းကိုမကြောက်ပါက အံ့သြဖွယ်ကောင်းသောဘာသာစကားတစ်ခုဖြစ်သော်လည်း ၎င်းကိုလေ့လာပြီးအသုံးပြုရန်ကြိုးစားပါ။ SQL queries တွေကို ဘယ်လို execute လုပ်သလဲ၊ database က query plan တွေကို ဘယ်လိုထုတ်ပေးသလဲ၊ indexes အလုပ်လုပ်ပုံနဲ့ သင်ကိုင်တွယ်နေတဲ့ data အရွယ်အစားကို ကောင်းကောင်းနားလည်ခြင်းဖြင့်၊ queries ကို optimize လုပ်ရာမှာ သင် အလွန်အောင်မြင်နိုင်ပါတယ်။ သို့သော် မတူညီသောချဉ်းကပ်မှုများကို ဆက်လက်ကြိုးစားပြီး ပြဿနာများကို ဖြည်းညှင်းစွာခွဲခြမ်းကာ ပိတ်ဆို့မှုများကိုရှာဖွေရန် အညီအမျှအရေးကြီးပါသည်။

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

အထူးပင်ကျေးဇူးတင်ရှိပါသည်။ ငါ့ရဲဘော်များ Aditya Mishra ၏အမိန့်တော်၌, Aditya Gauru и Varun Malhotra ဖောက်ထွက်ခြင်းနှင့် Dinkar Pandir ကျွန်ုပ်တို့၏ နောက်ဆုံးတောင်းဆိုမှုတွင် အရေးကြီးသော အမှားတစ်ခုကို ကျွန်ုပ်တို့ နောက်ဆုံးတွင် နှုတ်မဆက်မီတွင် တွေ့ရှိရန်။

source: www.habr.com

မှတ်ချက် Add