ເຈົ້າຈື່ໄດ້ບໍວ່າມັນທັງໝົດເລີ່ມຕົ້ນແນວໃດ. ທຸກສິ່ງທຸກຢ່າງແມ່ນຄັ້ງທໍາອິດແລະອີກເທື່ອຫນຶ່ງ

ກ່ຽວກັບວິທີທີ່ພວກເຮົາຕ້ອງເພີ່ມປະສິດທິພາບການສອບຖາມ PostgreSQL ແລະສິ່ງທີ່ອອກມາຈາກມັນທັງຫມົດ.
ເປັນຫຍັງເຈົ້າຕ້ອງ? ແມ່ນແລ້ວ, ເພາະວ່າ 4 ປີກ່ອນ, ທຸກຢ່າງເຮັດວຽກຢ່າງງຽບໆ, ສະຫງົບ, ຄືກັບໂມງ.
ເປັນ epigraph.

ອີງໃສ່ເຫດການທີ່ແທ້ຈິງ.
ຊື່ທັງຫມົດໄດ້ຖືກປ່ຽນ, ບັງເອີນແມ່ນ Random.

ໃນເວລາທີ່ທ່ານບັນລຸຜົນໄດ້ຮັບທີ່ແນ່ນອນ, ມັນເປັນທີ່ຫນ້າສົນໃຈສະເຫມີທີ່ຈະຈື່ຈໍາສິ່ງທີ່ເປັນແຮງກະຕຸ້ນສໍາລັບການເລີ່ມຕົ້ນ, ບ່ອນທີ່ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນ.

ດັ່ງນັ້ນ, ສິ່ງທີ່ເກີດຂຶ້ນເປັນຜົນໄດ້ຮັບແມ່ນໄດ້ອະທິບາຍໂດຍຫຍໍ້ໃນບົດຄວາມ "ການສັງເຄາະເປັນຫນຶ່ງໃນວິທີການປັບປຸງການປະຕິບັດ PostgreSQL".

ມັນອາດຈະເປັນທີ່ຫນ້າສົນໃຈທີ່ຈະສ້າງລະບົບຕ່ອງໂສ້ຂອງເຫດການທີ່ຜ່ານມາ.
ປະຫວັດສາດບັນທຶກວັນທີເລີ່ມຕົ້ນທີ່ແນ່ນອນ - 2018-09-10 18:02:48.
ນອກຈາກນັ້ນ, ໃນເລື່ອງຍັງມີຄໍາຮ້ອງຂໍທີ່ມັນເລີ່ມຕົ້ນທັງຫມົດ:
ຮ້ອງຂໍບັນຫາSELECT
p.“PARAMETER_ID” ເປັນ parameter_id,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "ຫຼາຍ" ເປັນ lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS lower_spec_limit,
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS ໃຊ້_ຊື່,
s.“SPENT_DATE” AS ໃຊ້ຈ່າຍວັນທີ,
ສະກັດ(ປີຈາກ "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,
spend_pd sp,
pd pd
WHERE s.“SPENT_ID” = w.“SPENT_ID”
AND p"PARAMETER_ID" = w."PARAMETER_ID"
AND s.“SPENT_ID” = sp.“SPENT_ID”
AND pd."PD_ID" = sp.PD_ID"
ແລະ s.“SPENT_DATE” >= '2018-07-01' ແລະ s.“SPENT_DATE” <= '2018-09-30'
ແລະ s.“SPENT_DATE” = (SELECT MAX(s2.“SPENT_DATE”)
ຈາກ​ການ​ໃຊ້​ເວ​ລາ s2​,
wdata w2
WHERE s2.“SPENT_ID” = w2.“SPENT_ID”
AND w2.“LRM” = w.“LRM”);

ລາຍລະອຽດຂອງບັນຫາແມ່ນມາດຕະຖານທີ່ຄາດເດົາໄດ້ - “ທຸກຢ່າງບໍ່ດີ. ບອກຂ້ອຍວ່າບັນຫາແມ່ນຫຍັງ.”
ຂ້າ​ພະ​ເຈົ້າ​ຈື່​ໄດ້​ທັນ​ທີ​ເລື່ອງ​ຫຍໍ້​ຈາກ​ເວ​ລາ​ຂອງ 3 ແລະ​ເຄິ່ງ​ນິ້ວ​ຂັບ​ລົດ​ໄດ້​:

lamer ມາຫາແຮກເກີ.
- ບໍ່ມີຫຍັງເຮັດວຽກສໍາລັບຂ້ອຍ, ບອກຂ້ອຍວ່າບັນຫາຢູ່ໃສ.
- ໃນ DNA...

ແຕ່ແນ່ນອນ, ນີ້ບໍ່ແມ່ນວິທີແກ້ໄຂບັນຫາການປະຕິບັດ. “ພວກເຂົາອາດຈະບໍ່ເຂົ້າໃຈພວກເຮົາ" (ກັບ). ພວກເຮົາຈໍາເປັນຕ້ອງຄິດມັນອອກ.
ດີ, ໃຫ້ຂອງຂຸດ. ບາງທີບາງສິ່ງບາງຢ່າງຈະສະສົມເປັນຜົນໄດ້ຮັບ.

ການສືບສວນໄດ້ເລີ່ມຕົ້ນ

ດັ່ງນັ້ນ, ສິ່ງທີ່ສາມາດເຫັນໄດ້ໃນທັນທີດ້ວຍຕາເປົ່າ, ໂດຍບໍ່ມີການແມ້ກະທັ້ງ resorting ກັບຄໍາອະທິບາຍ.
1) ເຂົ້າຮ່ວມບໍ່ໄດ້ຖືກນໍາໃຊ້. ນີ້ແມ່ນບໍ່ດີ, ໂດຍສະເພາະຖ້າຈໍານວນການເຊື່ອມຕໍ່ມີຫຼາຍກວ່າຫນຶ່ງ.
2) ແຕ່ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າແມ່ນການສອບຖາມຍ່ອຍທີ່ກ່ຽວຂ້ອງ, ນອກຈາກນັ້ນ, ດ້ວຍການລວບລວມ. ນີ້ແມ່ນບໍ່ດີຫຼາຍ.
ນີ້ແມ່ນບໍ່ດີແນ່ນອນ. ແຕ່ນີ້ແມ່ນຢູ່ໃນມືຫນຶ່ງເທົ່ານັ້ນ. ໃນທາງກົງກັນຂ້າມ, ນີ້ແມ່ນດີຫຼາຍ, ເພາະວ່າບັນຫາທີ່ຊັດເຈນມີການແກ້ໄຂແລະຄໍາຮ້ອງຂໍທີ່ສາມາດປັບປຸງໄດ້.
ຢ່າໄປຫາໝໍດູ (ຄ).
ແຜນ​ການ​ສອບ​ຖາມ​ບໍ່​ແມ່ນ​ສັບ​ສົນ​, ແຕ່​ວ່າ​ມັນ​ເປັນ​ຕົວ​ຊີ້​ວັດ​ທີ່​ຂ້ອນ​ຂ້າງ​:
ແຜນ​ການ​ປະ​ຕິ​ບັດ​

ຫນ້າສົນໃຈແລະເປັນປະໂຫຍດທີ່ສຸດ, ຕາມປົກກະຕິ, ແມ່ນໃນຕອນເລີ່ມຕົ້ນແລະສິ້ນສຸດ.
Nested Loop (cost=935.84..479763226.18 rows=3322 width=135) (ເວລາຈິງ=31.536..8220420.295 rows=8111656 loops=1)
ເວລາວາງແຜນ: 3.807 ms
ເວລາປະຕິບັດ: 8222351.640 ms
ເວລາສໍາເລັດແມ່ນຫຼາຍກ່ວາ 2 ຊົ່ວໂມງ.

ສົມມຸດຕິຖານທີ່ບໍ່ຖືກຕ້ອງທີ່ໄດ້ໃຊ້ເວລາ

ສົມມຸດຕິຖານ 1 - ຜູ້ເພີ່ມປະສິດທິພາບເຮັດຜິດພາດແລະສ້າງແຜນການທີ່ບໍ່ຖືກຕ້ອງ.

ເພື່ອເບິ່ງພາບແຜນການປະຕິບັດ, ພວກເຮົາຈະນໍາໃຊ້ເວັບໄຊທ໌ https://explain.depesz.com/. ຢ່າງໃດກໍຕາມ, ເວັບໄຊທ໌ບໍ່ໄດ້ສະແດງໃຫ້ເຫັນສິ່ງທີ່ຫນ້າສົນໃຈຫຼືເປັນປະໂຫຍດ. ຢູ່ glance ທໍາອິດແລະທີສອງ, ບໍ່ມີຫຍັງທີ່ສາມາດຊ່ວຍໄດ້. ມັນເປັນໄປໄດ້ບໍວ່າການສະແກນເຕັມແມ່ນຫນ້ອຍທີ່ສຸດ. ສືບຕໍ່ເດີນຫນ້າ.

ສົມມຸດຕິຖານ 2-ຜົນກະທົບຕໍ່ພື້ນຖານຈາກຂ້າງ autovacuum, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍາຈັດເບກ.

ແຕ່ daemons autovacuum ປະຕິບັດຕົວດີ, ບໍ່ມີຂະບວນການທີ່ຫ້ອຍຍາວ. ບໍ່ມີການໂຫຼດທີ່ຮ້າຍແຮງ. ພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາສິ່ງອື່ນ.

ສົມມຸດຕິຖານ 3 - ສະຖິຕິແມ່ນລ້າສະໄຫມ, ທຸກສິ່ງທຸກຢ່າງຕ້ອງໄດ້ຮັບການຄິດໄລ່ຄືນໃຫມ່

ອີກເທື່ອຫນຶ່ງ, ບໍ່ວ່າ. ສະຖິຕິແມ່ນທັນສະໄຫມ. ເຊິ່ງ, ເນື່ອງຈາກການຂາດບັນຫາກັບ autovacuum, ແມ່ນບໍ່ແປກໃຈ.

ໃຫ້ເລີ່ມຕົ້ນການເພີ່ມປະສິດທິພາບ

ຕາຕະລາງຕົ້ນຕໍ 'wdata' ແນ່ນອນວ່າບໍ່ແມ່ນຂະຫນາດນ້ອຍ, ເກືອບ 3 ລ້ານບັນທຶກ.
ແລະມັນແມ່ນຕາຕະລາງນີ້ທີ່ Full Scan ປະຕິບັດຕາມ.

Hash Cond: ((w.SPENT_ID" = s.SPENT_ID") AND ((SubPlan 1) = s.SPENT_DATE"))
-> ສະແກນ ໃນ wdata w (cost=0.00..574151.49 rows=26886249 width=46) (ເວລາຈິງ=0.005..8153.565 rows=26873950 loops=1)
ພວກເຮົາເຮັດຕາມມາດຕະຖານ: "ມາ, ໃຫ້ດັດສະນີແລະທຸກສິ່ງທຸກຢ່າງຈະບິນ."
ສ້າງດັດຊະນີໃນຊ່ອງ “SPENT_ID”
ດັ່ງນັ້ນ:
ແຜນການປະຕິບັດການສອບຖາມໂດຍໃຊ້ດັດສະນີ

ດີ, ມັນຊ່ວຍໄດ້ບໍ?
ແມ່ນ: 8 222 351.640 ມສ (ບໍ່​ເກີນ 2 ຊົ່ວ​ໂມງ​)
ມັນໄດ້ກາຍເປັນ: 6 985 431.575 ms (ເກືອບ 2 ຊົ່ວໂມງ)
ໂດຍທົ່ວໄປ, ຫມາກໂປມດຽວກັນ, ມຸມເບິ່ງຂ້າງ.
ຂໍໃຫ້ຈື່ຈໍາຄລາສສິກ:
“ເຈົ້າມີອັນດຽວກັນ, ແຕ່ບໍ່ມີປີກບໍ? ຈະຊອກຫາ".

ໃນຫຼັກການ, ນີ້ສາມາດເອີ້ນວ່າຜົນໄດ້ຮັບທີ່ດີ, ດີ, ບໍ່ດີ, ແຕ່ຍອມຮັບໄດ້. ຢ່າງຫນ້ອຍ, ໃຫ້ບົດລາຍງານຂະຫນາດໃຫຍ່ໃຫ້ກັບລູກຄ້າທີ່ອະທິບາຍວ່າໄດ້ເຮັດຫຼາຍປານໃດແລະເປັນຫຍັງສິ່ງທີ່ເຮັດໄດ້ດີ.
ຢ່າງໃດກໍຕາມ, ການຕັດສິນໃຈສຸດທ້າຍແມ່ນຍັງໄກ. ໄກຫຼາຍ.

ແລະໃນປັດຈຸບັນສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດ - ພວກເຮົາສືບຕໍ່ເພີ່ມປະສິດທິພາບ, ພວກເຮົາຈະຂັດຄໍາຮ້ອງຂໍ

ຂັ້ນຕອນທີຫນຶ່ງ - ໃຊ້ເຂົ້າຮ່ວມ

ຄໍາຮ້ອງຂໍທີ່ຂຽນຄືນໃຫມ່ໃນປັດຈຸບັນເບິ່ງຄືວ່ານີ້ (ດີ ຢ່າງ ຫນ້ອຍ ງາມ ຫຼາຍ):
ສອບຖາມໂດຍໃຊ້ JOINSELECT
p.“PARAMETER_ID” ເປັນ parameter_id,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "ຫຼາຍ" ເປັນ lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS lower_spec_limit,
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS ໃຊ້_ຊື່,
s.“SPENT_DATE” AS ໃຊ້ຈ່າຍວັນທີ,
ສະກັດ(ປີຈາກ "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 INner JOIN ໃຊ້ເວລາ s ຢູ່ໃນ w.“SPENT_ID”=s.”“SPENT_ID”
INNER JOIN pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN ໃຊ້ເວລາ_pd sp ON s.“SPENT_ID” = sp.“SPENT_ID”
INner JOIN 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” = (SELECT MAX(s2.“SPENT_DATE”)
ຈາກ wdata w2 INner JOIN ໃຊ້ s2 ON w2.“SPENT_ID”=s2.“SPENT_ID”
ພາຍໃນເຂົ້າຮ່ວມ wdata w
ON w2.“LRM” = w.“LRM” );
ເວລາວາງແຜນ: 2.486 ms
ເວລາປະຕິບັດ: 1223680.326 ms

ດັ່ງນັ້ນ, ຜົນໄດ້ຮັບທໍາອິດ.
ແມ່ນ: 6 ms (ເກືອບ 985 ຊົ່ວໂມງ).
ມັນໄດ້ກາຍເປັນ: 1 223 680.326 ms (ພຽງແຕ່ຫຼາຍກວ່າ 20 ນາທີ).
ຜົນໄດ້ຮັບທີ່ດີ. ໃນຫຼັກການ, ອີກເທື່ອຫນຶ່ງ, ພວກເຮົາສາມາດຢຸດຢູ່ທີ່ນັ້ນ. ແຕ່ມັນບໍ່ຫນ້າສົນໃຈຫຼາຍ, ທ່ານບໍ່ສາມາດຢຸດໄດ້.
ສໍາລັບ

ຂັ້ນຕອນທີສອງ - ກໍາຈັດ subquery ທີ່ກ່ຽວຂ້ອງ

ປ່ຽນຂໍ້ຄວາມຄຳຮ້ອງຂໍ:
ໂດຍບໍ່ມີການສອບຖາມຍ່ອຍທີ່ກ່ຽວຂ້ອງSELECT
p.“PARAMETER_ID” ເປັນ parameter_id,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "ຫຼາຍ" ເປັນ lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS lower_spec_limit,
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS ໃຊ້_ຊື່,
s.“SPENT_DATE” AS ໃຊ້ຈ່າຍວັນທີ,
ສະກັດ(ປີຈາກ "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 Inner JOIN ໃຊ້ເວລາ s.“SPENT_ID” = w.“SPENT_ID”
INNER JOIN pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN ໃຊ້ເວລາ_pd sp ON s.“SPENT_ID” = sp.“SPENT_ID”
INner JOIN pd pd ON pd.“PD_ID” = sp.“PD_ID”
ເຂົ້າຮ່ວມພາຍໃນ (ເລືອກ w2.“LRM”, MAX(s2.“SPENT_DATE”)
ຈາກການໃຊ້ s2 ພາຍໃນເຂົ້າຮ່ວມ wdata w2 ON s2.“SPENT_ID” = w2.“SPENT_ID”
ຈັດກຸ່ມໂດຍ w2.“LRM”
) md ສຸດ w.“LRM” = md.“LRM”
ບ່ອນທີ່
s."SPENT_DATE" >= '2018-07-01' AND s."SPENT_DATE" <= '2018-09-30';
ເວລາວາງແຜນ: 2.291 ms
ເວລາປະຕິບັດ: 165021.870 ms

ແມ່ນ: 1 223 680.326 ms (ພຽງແຕ່ຫຼາຍກວ່າ 20 ນາທີ).
ມັນໄດ້ກາຍເປັນ: 165 021.870 ms (ພຽງແຕ່ 2 ນາທີ).
ນີ້ແມ່ນດີແລ້ວ.
ຢ່າງໃດກໍຕາມ, ດັ່ງທີ່ອັງກິດເວົ້າວ່າ "ແຕ່, ມີສະເຫມີແຕ່" ຜົນໄດ້ຮັບທີ່ດີເກີນໄປຄວນຈະເຮັດໃຫ້ເກີດຄວາມສົງໃສໂດຍອັດຕະໂນມັດ. ມີບາງຢ່າງຜິດພາດຢູ່ບ່ອນນີ້.

ສົມມຸດຕິຖານກ່ຽວກັບການແກ້ໄຂການສອບຖາມເພື່ອກໍາຈັດການສອບຖາມຍ່ອຍທີ່ກ່ຽວຂ້ອງແມ່ນຖືກຕ້ອງ. ແຕ່ທ່ານຈໍາເປັນຕ້ອງປັບມັນເລັກນ້ອຍເພື່ອໃຫ້ຜົນໄດ້ຮັບສຸດທ້າຍຖືກຕ້ອງ.
ດັ່ງນັ້ນ, ຜົນໄດ້ຮັບຂັ້ນກາງທໍາອິດ:
ແກ້ໄຂຄໍາຖາມໂດຍບໍ່ມີການສອບຖາມຍ່ອຍທີ່ກ່ຽວຂ້ອງSELECT
p.“PARAMETER_ID” ເປັນ parameter_id,
pd."PD_NAME" AS pd_name,
pd."CUSTOMER_PARTNUMBER" AS customer_partnumber,
w. "LRM" AS LRM,
w. "ຫຼາຍ" ເປັນ lotid,
w.“RTD_VALUE” AS RTD_value,
w.“LOWER_SPEC_LIMIT” AS lower_spec_limit,
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit,
p."TYPE_CALCUL" AS type_calcul,
s."SPENT_NAME" AS ໃຊ້_ຊື່,
s.“SPENT_DATE” AS ໃຊ້ຈ່າຍວັນທີ,
ສະກັດ(ປີຈາກ s.“SPENT_DATE”) ເປັນປີ,
ສະກັດ(ເດືອນຈາກ s.“SPENT_DATE”) ເປັນເດືອນ,
s."REPORT_NAME" AS report_name,
p."STPM_NAME" AS stpm_name,
p.“CUSTOMERPARAM_NAME” AS customerparam_name
ຈາກ wdata w Inner JOIN ໃຊ້ເວລາ s.“SPENT_ID” = w.“SPENT_ID”
INNER JOIN pmtr p ON p.“PARAMETER_ID” = w.“PARAMETER_ID”
INNER JOIN ໃຊ້ເວລາ_pd sp ON s.“SPENT_ID” = sp.“SPENT_ID”
INner JOIN pd pd ON pd.“PD_ID” = sp.“PD_ID”
ເຂົ້າຮ່ວມພາຍໃນ (ເລືອກ w2.“LRM”, MAX(s2.“SPENT_DATE”) ເປັນ “SPENT_DATE”
ຈາກການໃຊ້ s2 ພາຍໃນເຂົ້າຮ່ວມ 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' AND 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, assembler, C, double-plus C, Oracle, plsql). ຫົວຂໍ້ທີ່ຫນ້າສົນໃຈ, ແນ່ນອນ, ສໍາລັບ memoir ແຍກຕ່າງຫາກ ;-).
ຢ່າງໃດກໍຕາມ, ໃຫ້ພວກເຮົາບໍ່ໄດ້ຮັບການລົບກວນ.

ດັ່ງ​ນັ້ນ

ຫຼືບາງທີການແບ່ງສ່ວນຈະຊ່ວຍພວກເຮົາບໍ?
Spoiler - "ແມ່ນແລ້ວ, ມັນຊ່ວຍ, ລວມທັງການເພີ່ມປະສິດທິພາບການເຮັດວຽກ."

ແຕ່​ນັ້ນ​ເປັນ​ເລື່ອງ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຫມົດ ...

ຕິດ​ຕາມ​ຕອນ​ຕໍ່​ໄປ…

ແຫຼ່ງຂໍ້ມູນ: www.habr.com