ಇದು ಹೇಗೆ ಪ್ರಾರಂಭವಾಯಿತು ಎಂದು ನಿಮಗೆ ನೆನಪಿದೆಯೇ. ಎಲ್ಲವೂ ಮೊದಲ ಬಾರಿಗೆ ಮತ್ತು ಮತ್ತೆ

ನಾವು PostgreSQL ಪ್ರಶ್ನೆಯನ್ನು ಹೇಗೆ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅದರಲ್ಲಿ ಏನೆಲ್ಲಾ ಬಂದಿದೆ ಎಂಬುದರ ಕುರಿತು.
ಯಾಕೆ ಬಂತು? ಹೌದು, ಏಕೆಂದರೆ ಹಿಂದಿನ 4 ವರ್ಷಗಳಿಂದ ಎಲ್ಲವೂ ಗಡಿಯಾರ ಮಚ್ಚೆಯಂತೆ ಸದ್ದಿಲ್ಲದೆ, ಶಾಂತವಾಗಿ ಕೆಲಸ ಮಾಡಿತು.
ಶಿಲಾಶಾಸನದಂತೆ.

ನೈಜ ಘಟನೆಗಳನ್ನು ಆಧರಿಸಿದೆ.
ಎಲ್ಲಾ ಹೆಸರುಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ, ಕಾಕತಾಳೀಯವು ಯಾದೃಚ್ಛಿಕವಾಗಿದೆ.

ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಿದಾಗ, ಪ್ರಾರಂಭದ ಪ್ರಚೋದನೆ ಏನೆಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಯಾವಾಗಲೂ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಅದು ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭವಾಯಿತು.

ಆದ್ದರಿಂದ, ಪರಿಣಾಮವಾಗಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಲೇಖನದಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ "PostgreSQL ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವ ವಿಧಾನಗಳಲ್ಲಿ ಒಂದು ಸಂಶ್ಲೇಷಣೆ».

ಹಿಂದಿನ ಘಟನೆಗಳ ಸರಪಳಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಇದು ಬಹುಶಃ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ.
ಇತಿಹಾಸವು ನಿಖರವಾದ ಪ್ರಾರಂಭ ದಿನಾಂಕವನ್ನು ಉಳಿಸಿದೆ - 2018-09-10 18:02:48.
ಅಲ್ಲದೆ, ಕಥೆಯಲ್ಲಿ ಅದು ಪ್ರಾರಂಭವಾದ ವಿನಂತಿಯಿದೆ:
ಸಮಸ್ಯೆಯ ವಿನಂತಿಆಯ್ಕೆಮಾಡಿ
p.“PARAMETER_ID” parameter_id ಆಗಿ,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS ಗ್ರಾಹಕ_ಪಾಲು ಸಂಖ್ಯೆ,
w. "LRM" AS LRM,
w. "LOTID" AS ಲೋಟಿಡ್,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS low_spec_limit,
w.“UPPER_SPEC_LIMIT” AS top_spec_limit,
p."TYPE_CALCUL" AS ಪ್ರಕಾರ_ಕಲ್ಪನೆ,
s."SPENT_NAME" AS ಖರ್ಚು ಮಾಡಿದ_ಹೆಸರು,
s.“SPENT_DATE” AS ಕಳೆದ_ದಿನಾಂಕ,
ಸಾರ ("SPENT_DATE" ರಿಂದ ವರ್ಷ) AS ವರ್ಷ,
("SPENT_DATE" ರಿಂದ ತಿಂಗಳು) ತಿಂಗಳಂತೆ ಹೊರತೆಗೆಯಿರಿ,
s."REPORT_NAME" AS ವರದಿ_ಹೆಸರು,
p."STPM_NAME" AS stpm_name,
p.“CUSTOMERPARAM_NAME” AS customerparam_name
wdata w ನಿಂದ,
ಗಳನ್ನು ಖರ್ಚು ಮಾಡಿದೆ,
pmtr p,
ಖರ್ಚು_ಪಿಡಿ ಎಸ್ಪಿ,
ಪಿಡಿ ಪಿಡಿ
WHERE s.“SPENT_ID” = w.“SPENT_ID”
ಮತ್ತು p."PARAMETER_ID" = w."PARAMETER_ID"
ಮತ್ತು 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”)
ಖರ್ಚು ಮಾಡಿದ ಸೆ2 ರಿಂದ,
wdata w2
ಎಲ್ಲಿ s2.“SPENT_ID” = w2.“SPENT_ID”
ಮತ್ತು w2.“LRM” = w.“LRM”);

ಸಮಸ್ಯೆಯ ವಿವರಣೆಯು ನಿರೀಕ್ಷಿತ ಪ್ರಮಾಣಿತವಾಗಿದೆ - “ಎಲ್ಲವೂ ಕೆಟ್ಟದಾಗಿದೆ. ಏನು ಸಮಸ್ಯೆ ಹೇಳು.”
3 ಮತ್ತು ಒಂದೂವರೆ ಇಂಚಿನ ಡ್ರೈವ್‌ಗಳ ಸಮಯದ ಒಂದು ಉಪಾಖ್ಯಾನವನ್ನು ನಾನು ತಕ್ಷಣವೇ ನೆನಪಿಸಿಕೊಂಡೆ:

ಲ್ಯಾಮರ್ ಹ್ಯಾಕರ್‌ಗೆ ಬರುತ್ತದೆ.
-ನನಗೆ ಏನೂ ಕೆಲಸವಿಲ್ಲ, ಸಮಸ್ಯೆ ಎಲ್ಲಿದೆ ಎಂದು ಹೇಳಿ.
-ಡಿಎನ್ಎಯಲ್ಲಿ...

ಆದರೆ ಸಹಜವಾಗಿ, ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಘಟನೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಮಾರ್ಗವಲ್ಲ. "ಅವರು ನಮ್ಮನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದಿರಬಹುದು"(ಜೊತೆ). ನಾವು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗಿದೆ.
ಸರಿ, ನಾವು ಅಗೆಯೋಣ. ಬಹುಶಃ ಪರಿಣಾಮವಾಗಿ ಏನಾದರೂ ಸಂಗ್ರಹವಾಗುತ್ತದೆ.

ತನಿಖೆ ಆರಂಭವಾಯಿತು

ಆದ್ದರಿಂದ, ವಿವರಿಸಲು ಸಹ ಆಶ್ರಯಿಸದೆಯೇ ಬರಿಗಣ್ಣಿನಿಂದ ತಕ್ಷಣವೇ ಏನು ನೋಡಬಹುದು.
1) ಸೇರ್ಪಡೆಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಇದು ಕೆಟ್ಟದು, ವಿಶೇಷವಾಗಿ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಇದ್ದರೆ.
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") ಮತ್ತು ((ಉಪಯೋಜನೆ 1) = ಸೆ."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 ಗ್ರಾಹಕ_ಪಾಲು ಸಂಖ್ಯೆ,
w. "LRM" AS LRM,
w. "LOTID" AS ಲೋಟಿಡ್,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS low_spec_limit,
w.“UPPER_SPEC_LIMIT” AS top_spec_limit,
p."TYPE_CALCUL" AS ಪ್ರಕಾರ_ಕಲ್ಪನೆ,
s."SPENT_NAME" AS ಖರ್ಚು ಮಾಡಿದ_ಹೆಸರು,
s.“SPENT_DATE” AS ಕಳೆದ_ದಿನಾಂಕ,
ಸಾರ ("SPENT_DATE" ರಿಂದ ವರ್ಷ) AS ವರ್ಷ,
("SPENT_DATE" ರಿಂದ ತಿಂಗಳು) ತಿಂಗಳಂತೆ ಹೊರತೆಗೆಯಿರಿ,
s."REPORT_NAME" AS ವರದಿ_ಹೆಸರು,
p."STPM_NAME" AS stpm_name,
p.“CUSTOMERPARAM_NAME” AS customerparam_name
Wdata w INNER JOIN ನಿಂದ s ಗಳನ್ನು ಕಳೆದಿದೆ w.“SPENT_ID”=s.”“SPENT_ID”
ಒಳ ಸೇರಿಕೊಳ್ಳಿ pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN paid_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’AND
s.“SPENT_DATE” = (MAX ಆಯ್ಕೆ ಮಾಡಿ(s2.“SPENT_DATE”)
Wdata w2 INNER JOIN ನಿಂದ w2.“SPENT_ID”=s2.“SPENT_ID” ನಲ್ಲಿ s2 ಕಳೆದಿದೆ
INNER JOIN wdata w
ಆನ್ 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 ಗ್ರಾಹಕ_ಪಾಲು ಸಂಖ್ಯೆ,
w. "LRM" AS LRM,
w. "LOTID" AS ಲೋಟಿಡ್,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS low_spec_limit,
w.“UPPER_SPEC_LIMIT” AS top_spec_limit,
p."TYPE_CALCUL" AS ಪ್ರಕಾರ_ಕಲ್ಪನೆ,
s."SPENT_NAME" AS ಖರ್ಚು ಮಾಡಿದ_ಹೆಸರು,
s.“SPENT_DATE” AS ಕಳೆದ_ದಿನಾಂಕ,
ಸಾರ ("SPENT_DATE" ರಿಂದ ವರ್ಷ) AS ವರ್ಷ,
("SPENT_DATE" ರಿಂದ ತಿಂಗಳು) ತಿಂಗಳಂತೆ ಹೊರತೆಗೆಯಿರಿ,
s."REPORT_NAME" AS ವರದಿ_ಹೆಸರು,
p."STPM_NAME" AS stpm_name,
p.“CUSTOMERPARAM_NAME” AS customerparam_name
Wdata w INNER JOIN ನಿಂದ s ಗಳನ್ನು ಕಳೆದಿದೆ.“SPENT_ID” = w.“SPENT_ID”
ಒಳ ಸೇರಿಕೊಳ್ಳಿ pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN paid_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 INNER Wdata w2 ON s2 ನಲ್ಲಿ ಕಳೆದರು.“SPENT_ID” = w2.“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 ಗ್ರಾಹಕ_ಪಾಲು ಸಂಖ್ಯೆ,
w. "LRM" AS LRM,
w. "LOTID" AS ಲೋಟಿಡ್,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS low_spec_limit,
w.“UPPER_SPEC_LIMIT” AS top_spec_limit,
p."TYPE_CALCUL" AS ಪ್ರಕಾರ_ಕಲ್ಪನೆ,
s."SPENT_NAME" AS ಖರ್ಚು ಮಾಡಿದ_ಹೆಸರು,
s.“SPENT_DATE” AS ಕಳೆದ_ದಿನಾಂಕ,
ಹೊರತೆಗೆಯಿರಿ (ಸೆ.“SPENT_DATE” ರಿಂದ ವರ್ಷ) AS ವರ್ಷ,
ಹೊರತೆಗೆಯಿರಿ(ಸೆ.“SPENT_DATE” ರಿಂದ ತಿಂಗಳು) ತಿಂಗಳಂತೆ,
s."REPORT_NAME" AS ವರದಿ_ಹೆಸರು,
p."STPM_NAME" AS stpm_name,
p.“CUSTOMERPARAM_NAME” AS customerparam_name
Wdata w INNER JOIN ನಿಂದ s ಗಳನ್ನು ಕಳೆದಿದೆ.“SPENT_ID” = w.“SPENT_ID”
ಒಳ ಸೇರಿಕೊಳ್ಳಿ pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN paid_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 INNER Wdata w2 ON s2 ನಲ್ಲಿ ಕಳೆದರು.“SPENT_ID” = w2.“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 ನಿಮಿಷಗಳಿಗಿಂತ ಹೆಚ್ಚು).

ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶ.

ಫಲಿತಾಂಶ

ನಾವು ಅಲ್ಲಿ ನಿಲ್ಲಿಸಬಹುದಿತ್ತು.
ಆದರೆ...
ತಿನ್ನುವುದರೊಂದಿಗೆ ಹಸಿವು ಬರುತ್ತದೆ. ನಡೆಯುವವನು ರಸ್ತೆಯನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳುತ್ತಾನೆ. ಯಾವುದೇ ಫಲಿತಾಂಶವು ಮಧ್ಯಂತರವಾಗಿರುತ್ತದೆ. ನಿಲ್ಲಿಸಿ ಸತ್ತರು. ಇತ್ಯಾದಿ.
ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಮುಂದುವರಿಸೋಣ.
ಉತ್ತಮ ಉಪಾಯ. ವಿಶೇಷವಾಗಿ ಗ್ರಾಹಕರು ಸಹ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ. ಮತ್ತು ಅದಕ್ಕಾಗಿ ಬಲವಾಗಿ.

ಆದ್ದರಿಂದ, ಡೇಟಾಬೇಸ್ ಮರುವಿನ್ಯಾಸಕ್ಕೆ ಇದು ಸಮಯ. ಪ್ರಶ್ನೆ ರಚನೆಯನ್ನು ಇನ್ನು ಮುಂದೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ (ಆದಾಗ್ಯೂ, ಅದು ನಂತರ ಬದಲಾದಂತೆ, ಎಲ್ಲವೂ ನಿಜವಾಗಿ ವಿಫಲವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ). ಆದರೆ ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸವನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುವುದು ಈಗಾಗಲೇ ಬಹಳ ಭರವಸೆಯ ಕಲ್ಪನೆಯಾಗಿದೆ. ಮತ್ತು ಮುಖ್ಯವಾಗಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಮತ್ತೊಮ್ಮೆ, ನಿಮ್ಮ ಯೌವನವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಿ. ನಾನು ತಕ್ಷಣವೇ DBA ಆಗಲಿಲ್ಲ, ನಾನು ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ ಬೆಳೆದಿದ್ದೇನೆ (BASIC, ಅಸೆಂಬ್ಲರ್, C, ಡಬಲ್-ಪ್ಲಸ್ C, Oracle, plsql). ಆಸಕ್ತಿದಾಯಕ ವಿಷಯ, ಸಹಜವಾಗಿ, ಪ್ರತ್ಯೇಕ ಆತ್ಮಚರಿತ್ರೆಗಾಗಿ ;-).
ಆದರೂ ವಿಚಲಿತರಾಗುವುದು ಬೇಡ.

ಆದ್ದರಿಂದ,

ಅಥವಾ ವಿಭಜನೆಯು ನಮಗೆ ಸಹಾಯ ಮಾಡಬಹುದೇ?
ಸ್ಪಾಯ್ಲರ್ - "ಹೌದು, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುವಲ್ಲಿ ಇದು ಸಹಾಯ ಮಾಡಿದೆ."

ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಕಥೆ ...

ಮುಂದುವರೆಯುವುದು…

ಮೂಲ: www.habr.com