ਕੀ ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਇਹ ਸਭ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ. ਸਭ ਕੁਝ ਪਹਿਲੀ ਵਾਰ ਅਤੇ ਦੁਬਾਰਾ ਸੀ

ਇਸ ਬਾਰੇ ਕਿ ਸਾਨੂੰ PostgreSQL ਪੁੱਛਗਿੱਛ ਨੂੰ ਕਿਵੇਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਪਿਆ ਅਤੇ ਇਸ ਤੋਂ ਕੀ ਨਿਕਲਿਆ।
ਤੁਹਾਨੂੰ ਕਿਉਂ ਕਰਨਾ ਪਿਆ? ਹਾਂ, ਕਿਉਂਕਿ ਪਿਛਲੇ 4 ਸਾਲਾਂ ਲਈ ਸਭ ਕੁਝ ਚੁੱਪ-ਚਾਪ, ਸ਼ਾਂਤੀ ਨਾਲ, ਘੜੀ ਦੀ ਟਿਕ ਟਿਕ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਸੀ।
ਇੱਕ ਐਪੀਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ.

ਅਸਲ ਘਟਨਾਵਾਂ 'ਤੇ ਆਧਾਰਿਤ।
ਸਾਰੇ ਨਾਮ ਬਦਲ ਦਿੱਤੇ ਗਏ ਹਨ, ਇਤਫ਼ਾਕ ਬੇਤਰਤੀਬੇ ਹਨ.

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਯਾਦ ਰੱਖਣਾ ਹਮੇਸ਼ਾ ਦਿਲਚਸਪ ਹੁੰਦਾ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤ ਲਈ ਕੀ ਪ੍ਰੇਰਣਾ ਸੀ, ਜਿੱਥੇ ਇਹ ਸਭ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ.

ਇਸ ਲਈ, ਨਤੀਜੇ ਵਜੋਂ ਕੀ ਹੋਇਆ, ਲੇਖ ਵਿੱਚ ਸੰਖੇਪ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ "PostgreSQL ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਦੇ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਜੋਂ ਸੰਸਲੇਸ਼ਣ".

ਪਿਛਲੀਆਂ ਘਟਨਾਵਾਂ ਦੀ ਲੜੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਸ਼ਾਇਦ ਦਿਲਚਸਪ ਹੋਵੇਗਾ.
ਇਤਿਹਾਸ ਨੇ ਸਹੀ ਸ਼ੁਰੂਆਤੀ ਮਿਤੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ - 2018-09-10 18:02:48।
ਨਾਲ ਹੀ, ਕਹਾਣੀ ਵਿੱਚ ਇੱਕ ਬੇਨਤੀ ਹੈ ਜਿਸ ਤੋਂ ਇਹ ਸਭ ਸ਼ੁਰੂ ਹੋਇਆ:
ਸਮੱਸਿਆ ਦੀ ਬੇਨਤੀਚੁਣੋ
p. “PARAMETER_ID” parameter_id ਵਜੋਂ,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "LOTID" as lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” as low_spec_limit,
w.“UPPER_SPEC_LIMIT” as upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS spent_name,
s. “SPENT_DATE” AS spent_date,
ਐਬਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਸਾਲ) AS ਸਾਲ,
ਐਕਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਮਹੀਨਾ) ਮਹੀਨੇ ਵਜੋਂ,
s."REPORT_NAME" AS report_name,
p."STPM_NAME" AS stpm_name,
p. “CUSTOMERPARAM_NAME” AS customerparam_name
wdata w ਤੋਂ,
ਖਰਚਿਆ s,
pmtr p,
spent_pd sp,
pd pd
WHERE s.“SPENT_ID” = w.“SPENT_ID”
ਅਤੇ p."PARAMETER_ID" = w."PARAMETER_ID"
AND s.“SPENT_ID” = sp.“SPENT_ID”
ਅਤੇ pd."PD_ID" = sp."PD_ID"
ਅਤੇ s. “SPENT_DATE” >= '2018-07-01' ਅਤੇ s. “SPENT_DATE” <= '2018-09-30'
ਅਤੇ s. “SPENT_DATE” = (ਚੁਣੋ MAX(s2. “SPENT_DATE”)
s2 ਖਰਚੇ ਤੋਂ,
wdata w2
WHERE s2.“SPENT_ID” = w2.“SPENT_ID”
ਅਤੇ w2. “LRM” = w. “LRM”);

ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ ਅਨੁਮਾਨਤ ਤੌਰ 'ਤੇ ਮਿਆਰੀ ਹੈ - "ਸਭ ਕੁਝ ਬੁਰਾ ਹੈ. ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਸਮੱਸਿਆ ਕੀ ਹੈ। ”
ਮੈਨੂੰ ਤੁਰੰਤ ਸਾਢੇ 3 ਇੰਚ ਡਰਾਈਵ ਦੇ ਸਮੇਂ ਦਾ ਇੱਕ ਕਿੱਸਾ ਯਾਦ ਆਇਆ:

ਲੈਮਰ ਹੈਕਰ ਨੂੰ ਆਉਂਦਾ ਹੈ।
-ਮੇਰੇ ਲਈ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਸਮੱਸਿਆ ਕਿੱਥੇ ਹੈ।
-ਡੀਐਨਏ ਵਿੱਚ...

ਪਰ ਬੇਸ਼ੱਕ, ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ. "ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਸਾਨੂੰ ਸਮਝ ਨਾ ਸਕਣ"(ਨਾਲ)। ਸਾਨੂੰ ਇਸ ਨੂੰ ਬਾਹਰ ਦਾ ਿਹਸਾਬ ਲਗਾਉਣ ਦੀ ਲੋੜ ਹੈ.
ਖੈਰ, ਆਓ ਖੁਦਾਈ ਕਰੀਏ. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਨਤੀਜੇ ਵਜੋਂ ਕੁਝ ਇਕੱਠਾ ਹੋ ਜਾਵੇਗਾ.

ਜਾਂਚ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ

ਇਸ ਲਈ, ਸਪਸ਼ਟੀਕਰਨ ਦਾ ਸਹਾਰਾ ਲਏ ਬਿਨਾਂ, ਨੰਗੀ ਅੱਖ ਨਾਲ ਤੁਰੰਤ ਕੀ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ.
1) JOIN ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇਹ ਬੁਰਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਇੱਕ ਤੋਂ ਵੱਧ ਹੈ।
2) ਪਰ ਇਸ ਤੋਂ ਵੀ ਮਾੜੀ ਗੱਲ ਹੈ ਸਹਿਸਬੰਧਿਤ ਸਬਕਵੇਰੀਆਂ, ਇਸ ਤੋਂ ਇਲਾਵਾ, ਏਕੀਕਰਣ ਦੇ ਨਾਲ। ਇਹ ਬਹੁਤ ਬੁਰਾ ਹੈ।
ਇਹ ਜ਼ਰੂਰ ਬੁਰਾ ਹੈ. ਪਰ ਇਹ ਸਿਰਫ ਇੱਕ ਪਾਸੇ ਹੈ. ਦੂਜੇ ਪਾਸੇ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਕਿਉਂਕਿ ਸਮੱਸਿਆ ਦਾ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਇੱਕ ਹੱਲ ਹੈ ਅਤੇ ਇੱਕ ਬੇਨਤੀ ਹੈ ਜਿਸ ਨੂੰ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ.
ਕਿਸੇ ਕਿਸਮਤ ਦੱਸਣ ਵਾਲੇ (ਸੀ) ਕੋਲ ਨਾ ਜਾਓ।
ਪੁੱਛਗਿੱਛ ਯੋਜਨਾ ਇੰਨੀ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਸੰਕੇਤਕ ਹੈ:
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ

ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਅਤੇ ਉਪਯੋਗੀ, ਆਮ ਵਾਂਗ, ਸ਼ੁਰੂਆਤ ਅਤੇ ਅੰਤ ਵਿੱਚ ਹੈ.
ਨੇਸਟਡ ਲੂਪ (ਲਾਗਤ=935.84..479763226.18 ਕਤਾਰਾਂ=3322 ਚੌੜਾਈ=135) (ਅਸਲ ਸਮਾਂ=31.536..8220420.295 ਕਤਾਰਾਂ=8111656 ਲੂਪਸ=1)
ਪਲੈਨਿੰਗ ਟਾਈਮ: 3.807 ms
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ: 8222351.640 ms
ਪੂਰਾ ਹੋਣ ਦਾ ਸਮਾਂ 2 ਘੰਟਿਆਂ ਤੋਂ ਵੱਧ ਹੈ।

ਝੂਠੀਆਂ ਧਾਰਨਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਸਮਾਂ ਲਿਆ

ਹਾਈਪੋਥੀਸਿਸ 1 - ਆਪਟੀਮਾਈਜ਼ਰ ਗਲਤੀ ਕਰਦਾ ਹੈ ਅਤੇ ਗਲਤ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ।

ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਾਈਟ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ https://explain.depesz.com/. ਹਾਲਾਂਕਿ, ਸਾਈਟ ਨੇ ਕੁਝ ਵੀ ਦਿਲਚਸਪ ਜਾਂ ਉਪਯੋਗੀ ਨਹੀਂ ਦਿਖਾਇਆ. ਪਹਿਲੀ ਅਤੇ ਦੂਜੀ ਨਜ਼ਰ 'ਤੇ, ਇੱਥੇ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ. ਕੀ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਪੂਰਾ ਸਕੈਨ ਨਿਊਨਤਮ ਹੈ। ਲੰਗ ਜਾਓ.

ਹਾਈਪੋਥੀਸਿਸ 2- ਆਟੋਵੈਕਿਊਮ ਸਾਈਡ ਤੋਂ ਅਧਾਰ 'ਤੇ ਪ੍ਰਭਾਵ, ਤੁਹਾਨੂੰ ਬ੍ਰੇਕਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਪਰ ਆਟੋਵੈਕਿਊਮ ਡੈਮਨ ਵਧੀਆ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਕੋਈ ਲੰਬੀ-ਲਟਕਣ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਹੀਂ ਹਨ। ਕੋਈ ਗੰਭੀਰ ਲੋਡ ਨਹੀਂ। ਸਾਨੂੰ ਕੁਝ ਹੋਰ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ।

ਹਾਇਪੋਥੀਸਿਸ 3 - ਅੰਕੜੇ ਪੁਰਾਣੇ ਹਨ, ਹਰ ਚੀਜ਼ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਦੁਬਾਰਾ ਫਿਰ, ਇਹ ਨਹੀਂ. ਅੰਕੜੇ ਅੱਪ ਟੂ ਡੇਟ ਹਨ। ਜੋ ਕਿ, ਆਟੋਵੈਕਿਊਮ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਘਾਟ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ.

ਆਉ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰੀਏ

ਮੁੱਖ ਸਾਰਣੀ 'wdata' ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਛੋਟਾ ਨਹੀਂ ਹੈ, ਲਗਭਗ 3 ਮਿਲੀਅਨ ਰਿਕਾਰਡ ਹਨ।
ਅਤੇ ਇਹ ਇਹ ਸਾਰਣੀ ਹੈ ਜੋ ਪੂਰਾ ਸਕੈਨ ਕਰਦਾ ਹੈ.

ਹੈਸ਼ ਕੰਡ: ((w."SPENT_ID" = s."SPENT_ID") ਅਤੇ ((SubPlan 1) = s."SPENT_DATE"))
-> ਸੀਕ ਸਕੈਨ wdata 'ਤੇ w (ਲਾਗਤ=0.00..574151.49 ਕਤਾਰਾਂ=26886249 ਚੌੜਾਈ=46) (ਅਸਲ ਸਮਾਂ=0.005..8153.565 ਕਤਾਰਾਂ=26873950 ਲੂਪਸ=1)
ਅਸੀਂ ਮਿਆਰੀ ਕੰਮ ਕਰਦੇ ਹਾਂ: "ਆਓ, ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਈਏ ਅਤੇ ਸਭ ਕੁਝ ਉੱਡ ਜਾਵੇਗਾ।"
"SPENT_ID" ਖੇਤਰ 'ਤੇ ਇੱਕ ਸੂਚਕਾਂਕ ਬਣਾਇਆ ਗਿਆ
ਫਲਸਰੂਪ:
ਸੂਚਕਾਂਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰੋ

ਖੈਰ, ਕੀ ਇਸਨੇ ਮਦਦ ਕੀਤੀ?
ਸੀ: 8 222 351.640 ms (2 ਘੰਟਿਆਂ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ)
ਇਹ ਬਣ ਗਿਆ: 6 985 431.575 ms (ਲਗਭਗ 2 ਘੰਟੇ)
ਆਮ ਤੌਰ 'ਤੇ, ਉਹੀ ਸੇਬ, ਸਾਈਡ ਵਿਊ.
ਆਓ ਕਲਾਸਿਕਾਂ ਨੂੰ ਯਾਦ ਕਰੀਏ:
“ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਉਹੀ ਹੈ, ਪਰ ਖੰਭਾਂ ਤੋਂ ਬਿਨਾਂ? ਭਾਲਣਗੇ"।

ਸਿਧਾਂਤ ਵਿੱਚ, ਇਸ ਨੂੰ ਇੱਕ ਚੰਗਾ ਨਤੀਜਾ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ, ਠੀਕ ਹੈ, ਚੰਗਾ ਨਹੀਂ, ਪਰ ਸਵੀਕਾਰਯੋਗ ਹੈ. ਬਹੁਤ ਘੱਟ ਤੋਂ ਘੱਟ, ਗਾਹਕ ਨੂੰ ਇੱਕ ਵੱਡੀ ਰਿਪੋਰਟ ਪ੍ਰਦਾਨ ਕਰੋ ਜਿਸ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਕਿੰਨਾ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕਿਉਂ ਕੀਤਾ ਗਿਆ ਸੀ ਚੰਗਾ ਸੀ।
ਪਰ ਅੰਤਮ ਫੈਸਲਾ ਅਜੇ ਬਹੁਤ ਦੂਰ ਹੈ। ਬਹੁਤ ਹੀ ਦੂਰ.

ਅਤੇ ਹੁਣ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ - ਅਸੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ, ਅਸੀਂ ਬੇਨਤੀ ਨੂੰ ਪਾਲਿਸ਼ ਕਰਾਂਗੇ

ਪਹਿਲਾ ਕਦਮ - JOIN ਦੀ ਵਰਤੋਂ ਕਰੋ

ਮੁੜ-ਲਿਖੀ ਬੇਨਤੀ ਹੁਣ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ (ਨਾਲ ਨਾਲ ਘੱਟੋ ਘੱਟ ਹੋਰ ਸੁੰਦਰ):
JOIN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੁੱਛਗਿੱਛ ਕਰੋਚੁਣੋ
p. “PARAMETER_ID” parameter_id ਵਜੋਂ,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "LOTID" as lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” as low_spec_limit,
w.“UPPER_SPEC_LIMIT” as upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS spent_name,
s. “SPENT_DATE” AS spent_date,
ਐਬਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਸਾਲ) AS ਸਾਲ,
ਐਕਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਮਹੀਨਾ) ਮਹੀਨੇ ਵਜੋਂ,
s."REPORT_NAME" AS report_name,
p."STPM_NAME" AS stpm_name,
p. “CUSTOMERPARAM_NAME” AS customerparam_name
"SPENT_ID"=s." "SPENT_ID" 'ਤੇ ਖਰਚ ਕੀਤੇ ਗਏ ਡਬਲਯੂਡੈਟਾ ਤੋਂ ਅੰਦਰੂਨੀ ਜੁਆਇਨ
INNER Join pmtr p ON p. “PARAMETER_ID” = w.“PARAMETER_ID”
INNER Join spent_pd sp ON s। “SPENT_ID” = sp। “SPENT_ID”
ਅੰਦਰੂਨੀ ਜੁੜੋ pd pd ON pd. “PD_ID” = sp. “PD_ID”
ਕਿੱਥੇ
s. “SPENT_DATE” >= '2018-07-01' ਅਤੇ s. “SPENT_DATE” <= '2018-09-30'ਅਤੇ
s. “SPENT_DATE” = (MAX ਚੁਣੋ(s2. “SPENT_DATE”)
w2 w2 INNER Join w2 'ਤੇ s2 ਖਰਚੇ ਗਏ wdata ਤੋਂ।“SPENT_ID”=sXNUMX।“SPENT_ID”
INNER Join wdata w
ON w2.“LRM” = w.“LRM”);
ਪਲੈਨਿੰਗ ਟਾਈਮ: 2.486 ms
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ: 1223680.326 ms

ਇਸ ਲਈ, ਪਹਿਲਾ ਨਤੀਜਾ.
ਸੀ: 6 ms (ਲਗਭਗ 985 ਘੰਟੇ)।
ਇਹ ਬਣ ਗਿਆ: 1 223 680.326 ms (ਸਿਰਫ਼ 20 ਮਿੰਟ ਤੋਂ ਵੱਧ)।
ਚੰਗਾ ਨਤੀਜਾ. ਸਿਧਾਂਤ ਵਿੱਚ, ਦੁਬਾਰਾ, ਅਸੀਂ ਉੱਥੇ ਰੁਕ ਸਕਦੇ ਹਾਂ. ਪਰ ਇਹ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ, ਤੁਸੀਂ ਰੋਕ ਨਹੀਂ ਸਕਦੇ.
ਲਈ

ਕਦਮ ਦੋ - ਸਬੰਧਿਤ ਸਬਕਵੇਰੀ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓ

ਬਦਲਿਆ ਗਿਆ ਬੇਨਤੀ ਪਾਠ:
ਸੰਬੰਧਤ ਸਬਕਵੇਰੀ ਤੋਂ ਬਿਨਾਂਚੁਣੋ
p. “PARAMETER_ID” parameter_id ਵਜੋਂ,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "LOTID" as lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” as low_spec_limit,
w.“UPPER_SPEC_LIMIT” as upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS spent_name,
s. “SPENT_DATE” AS spent_date,
ਐਬਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਸਾਲ) AS ਸਾਲ,
ਐਕਸਟਰੈਕਟ ("SPENT_DATE" ਤੋਂ ਮਹੀਨਾ) ਮਹੀਨੇ ਵਜੋਂ,
s."REPORT_NAME" AS report_name,
p."STPM_NAME" AS stpm_name,
p. “CUSTOMERPARAM_NAME” AS customerparam_name
ਡਬਲਯੂਡੈਟਾ ਤੋਂ INNER JOIN ਖਰਚੇ s ON s. “SPENT_ID” = w. “SPENT_ID”
INNER Join pmtr p ON p. “PARAMETER_ID” = w.“PARAMETER_ID”
INNER Join spent_pd sp ON s। “SPENT_ID” = sp। “SPENT_ID”
ਅੰਦਰੂਨੀ ਜੁੜੋ pd pd ON pd. “PD_ID” = sp. “PD_ID”
ਅੰਦਰੂਨੀ ਸ਼ਾਮਲ ਹੋਵੋ (w2 ਚੁਣੋ. “LRM”, MAX(s2. “SPENT_DATE”)
s2 'ਤੇ ਖਰਚੇ ਗਏ s2 INNER JOIN wdata w2 ON s2। “SPENT_ID” = wXNUMX. “SPENT_ID”
W2 ਦੁਆਰਾ ਸਮੂਹ. "LRM"
) md on w.“LRM” = md.“LRM”
ਕਿੱਥੇ
s."SPENT_DATE" >= '2018-07-01' ਅਤੇ s."SPENT_DATE" <= '2018-09-30';
ਪਲੈਨਿੰਗ ਟਾਈਮ: 2.291 ms
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ: 165021.870 ms

ਸੀ: 1 223 680.326 ms (ਸਿਰਫ਼ 20 ਮਿੰਟ ਤੋਂ ਵੱਧ)।
ਇਹ ਬਣ ਗਿਆ: 165 021.870 ms (ਸਿਰਫ਼ 2 ਮਿੰਟ ਤੋਂ ਵੱਧ)।
ਇਹ ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਵਧੀਆ ਹੈ.
ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਬ੍ਰਿਟਿਸ਼ ਕਹਿੰਦੇ ਹਨ "ਪਰ, ਹਮੇਸ਼ਾ ਇੱਕ ਪਰ ਹੁੰਦਾ ਹੈ" ਇੱਕ ਨਤੀਜਾ ਜੋ ਬਹੁਤ ਵਧੀਆ ਹੈ ਆਪਣੇ ਆਪ ਹੀ ਸ਼ੱਕ ਪੈਦਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਇੱਥੇ ਕੁਝ ਗਲਤ ਹੈ।

ਸਬੰਧਿਤ ਸਬਕਵੇਰੀ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਲਈ ਪੁੱਛਗਿੱਛ ਨੂੰ ਠੀਕ ਕਰਨ ਬਾਰੇ ਅਨੁਮਾਨ ਸਹੀ ਹੈ। ਪਰ ਅੰਤਮ ਨਤੀਜਾ ਸਹੀ ਹੋਣ ਲਈ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਥੋੜਾ ਜਿਹਾ ਬਦਲਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.
ਨਤੀਜੇ ਵਜੋਂ, ਪਹਿਲਾ ਵਿਚਕਾਰਲਾ ਨਤੀਜਾ:
ਸਬੰਧਿਤ ਸਬਕਵੇਰੀ ਤੋਂ ਬਿਨਾਂ ਸੰਪਾਦਿਤ ਪੁੱਛਗਿੱਛਚੁਣੋ
p. “PARAMETER_ID” parameter_id ਵਜੋਂ,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "LOTID" as lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” as low_spec_limit,
w.“UPPER_SPEC_LIMIT” as upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS spent_name,
s. “SPENT_DATE” AS spent_date,
ਐਕਸਟਰੈਕਟ (s. “SPENT_DATE” ਤੋਂ ਸਾਲ) AS ਸਾਲ,
ਐਕਸਟਰੈਕਟ (s. “SPENT_DATE” ਤੋਂ ਮਹੀਨਾ) ਮਹੀਨੇ ਵਜੋਂ,
s."REPORT_NAME" AS report_name,
p."STPM_NAME" AS stpm_name,
p. “CUSTOMERPARAM_NAME” AS customerparam_name
ਡਬਲਯੂਡੈਟਾ ਤੋਂ INNER JOIN ਖਰਚੇ s ON s. “SPENT_ID” = w. “SPENT_ID”
INNER Join pmtr p ON p. “PARAMETER_ID” = w.“PARAMETER_ID”
INNER Join spent_pd sp ON s। “SPENT_ID” = sp। “SPENT_ID”
ਅੰਦਰੂਨੀ ਜੁੜੋ pd pd ON pd. “PD_ID” = sp. “PD_ID”
ਅੰਦਰੂਨੀ ਸ਼ਾਮਲ ਹੋਵੋ ( w2. “LRM”, MAX(s2. “SPENT_DATE”) “SPENT_DATE” ਵਜੋਂ ਚੁਣੋ
s2 'ਤੇ ਖਰਚੇ ਗਏ s2 INNER JOIN wdata w2 ON s2। “SPENT_ID” = wXNUMX. “SPENT_ID”
W2 ਦੁਆਰਾ ਸਮੂਹ. "LRM"
) md ON md. “SPENT_DATE” = s. “SPENT_DATE” ਅਤੇ md. “LRM” = w. “LRM”
ਕਿੱਥੇ
s."SPENT_DATE" >= '2018-07-01' ਅਤੇ s."SPENT_DATE" <= '2018-09-30';
ਪਲੈਨਿੰਗ ਟਾਈਮ: 3.192 ms
ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ: 208014.134 ms

ਇਸ ਲਈ, ਜੋ ਅਸੀਂ ਖਤਮ ਕਰਦੇ ਹਾਂ ਉਹ ਪਹਿਲਾ ਸਵੀਕਾਰਯੋਗ ਨਤੀਜਾ ਹੈ, ਜੋ ਗਾਹਕ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਸ਼ਰਮ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ:
ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ: 8 222 351.640 ms (2 ਘੰਟੇ ਤੋਂ ਵੱਧ)
ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ: 1 ms (223 ਮਿੰਟਾਂ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ)।
ਨਤੀਜਾ (ਅੰਤਰਿਮ): 208 014.134 ms (ਸਿਰਫ਼ 3 ਮਿੰਟ ਤੋਂ ਵੱਧ)।

ਸ਼ਾਨਦਾਰ ਨਤੀਜਾ.

ਨਤੀਜਾ

ਅਸੀਂ ਉੱਥੇ ਰੁਕ ਸਕਦੇ ਸੀ।
ਪਰ…
ਖਾਣ ਨਾਲ ਭੁੱਖ ਲਗਦੀ ਹੈ। ਜਿਹੜਾ ਤੁਰਦਾ ਹੈ, ਉਹ ਸੜਕ ਉੱਤੇ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰੇਗਾ। ਕੋਈ ਵੀ ਨਤੀਜਾ ਵਿਚਕਾਰਲਾ ਹੁੰਦਾ ਹੈ। ਰੁਕ ਗਿਆ ਅਤੇ ਮਰ ਗਿਆ। ਆਦਿ।
ਆਓ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਜਾਰੀ ਰੱਖੀਏ।
ਉੱਤਮ ਵਿਚਾਰ. ਖਾਸ ਤੌਰ 'ਤੇ ਇਸ ਗੱਲ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹੋਏ ਕਿ ਗਾਹਕ ਨੂੰ ਵੀ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ ਸੀ. ਅਤੇ ਇਸਦੇ ਲਈ ਵੀ ਜ਼ੋਰਦਾਰ.

ਇਸ ਲਈ, ਇਹ ਡੇਟਾਬੇਸ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ. ਪੁੱਛਗਿੱਛ ਬਣਤਰ ਨੂੰ ਹੁਣ ਆਪਟੀਮਾਈਜ਼ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਇਹ ਬਾਅਦ ਵਿੱਚ ਸਾਹਮਣੇ ਆਇਆ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਵਿਕਲਪ ਹੈ ਕਿ ਹਰ ਚੀਜ਼ ਅਸਲ ਵਿੱਚ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ)। ਪਰ ਡੇਟਾਬੇਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਅਤੇ ਵਿਕਸਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਬਹੁਤ ਹੀ ਵਧੀਆ ਵਿਚਾਰ ਹੈ. ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਦਿਲਚਸਪ. ਫੇਰ, ਆਪਣੀ ਜਵਾਨੀ ਨੂੰ ਯਾਦ ਕਰੋ. ਮੈਂ ਤੁਰੰਤ ਇੱਕ ਡੀਬੀਏ ਨਹੀਂ ਬਣਿਆ, ਮੈਂ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ (ਬੇਸਿਕ, ਅਸੈਂਬਲਰ, ਸੀ, ਡਬਲ-ਪਲੱਸ ਸੀ, ਓਰੇਕਲ, plsql) ਵਜੋਂ ਵੱਡਾ ਹੋਇਆ। ਇੱਕ ਦਿਲਚਸਪ ਵਿਸ਼ਾ, ਬੇਸ਼ਕ, ਇੱਕ ਵੱਖਰੀ ਯਾਦ ਲਈ ;-).
ਹਾਲਾਂਕਿ, ਆਓ ਅਸੀਂ ਵਿਚਲਿਤ ਨਾ ਹੋਈਏ।

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ,

ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਵੰਡ ਸਾਡੀ ਮਦਦ ਕਰੇਗੀ?
ਸਪੋਇਲਰ - "ਹਾਂ, ਇਸ ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।"

ਪਰ ਇਹ ਬਿਲਕੁਲ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ ...

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ…

ਸਰੋਤ: www.habr.com