ສູດສໍາລັບ Sick SQL Queries

ເມື່ອຫລາຍເດືອນກ່ອນ ພວກເຮົາປະກາດ ອະທິບາຍ.tensor.ru - ສາທາລະນະ ການ​ບໍ​ລິ​ການ​ສໍາ​ລັບ​ການ​ວິ​ເຄາະ​ແລະ​ການ​ເບິ່ງ​ແຜນ​ການ​ສອບ​ຖາມ​ ກັບ PostgreSQL.

ທ່ານໄດ້ໃຊ້ມັນຫຼາຍກວ່າ 6000 ເທື່ອນັບຕັ້ງແຕ່ນັ້ນມາ, ແຕ່ຫນຶ່ງໃນລັກສະນະທີ່ມີປະໂຫຍດອາດຈະບໍ່ໄດ້ສັງເກດເຫັນແມ່ນ ຂໍ້ຄຶດໂຄງສ້າງ, ຊຶ່ງ​ເບິ່ງ​ຄື​ແນວ​ນີ້​:

ຟັງພວກເຂົາແລະຄໍາຮ້ອງຂໍຂອງທ່ານຈະ "ກາຍເປັນກ້ຽງ". 🙂

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

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

ຂໍໃຫ້ພິຈາລະນາຢ່າງລະອຽດກ່ຽວກັບກໍລະນີເຫຼົ່ານີ້ - ວິທີການທີ່ພວກເຂົາຖືກກໍານົດແລະຄໍາແນະນໍາໃດທີ່ເຂົາເຈົ້ານໍາໄປສູ່.

ສໍາລັບການ immersion ທີ່ດີກວ່າໃນຫົວຂໍ້, ທໍາອິດທ່ານສາມາດຟັງຕັນທີ່ສອດຄ້ອງກັນຈາກ ບົດລາຍງານຂອງຂ້ອຍຢູ່ PGConf.Russia 2020, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນໄປຫາການວິເຄາະລາຍລະອຽດຂອງແຕ່ລະຕົວຢ່າງ:

#1: ດັດສະນີ "undersorting"

ເມື່ອ​ເກີດ​ຂຶ້ນ

ສະແດງໃບເກັບເງິນສຸດທ້າຍສໍາລັບລູກຄ້າ "LLC Kolokolchik".

ວິທີການກໍານົດ

-> Limit
   -> Sort
      -> Index [Only] Scan [Backward] | Bitmap Heap Scan

ຂໍ້ສະເຫນີແນະ

ດັດຊະນີທີ່ໃຊ້ ຂະຫຍາຍດ້ວຍຊ່ອງຂໍ້ມູນການຈັດຮຽງ.

ຕົວຢ່າງ:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 1 -- отбор по конкретной связи
ORDER BY
  pk DESC -- хотим всего одну "последнюю" запись
LIMIT 1;

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ທ່ານສາມາດສັງເກດເຫັນໄດ້ທັນທີວ່າຫຼາຍກວ່າ 100 ບັນທຶກໄດ້ຖືກຫັກອອກໂດຍດັດຊະນີ, ເຊິ່ງຫຼັງຈາກນັ້ນໄດ້ຖືກຈັດຮຽງທັງຫມົດ, ແລະຫຼັງຈາກນັ້ນພຽງແຕ່ຫນຶ່ງອັນດຽວທີ່ຖືກປະໄວ້.

ພວກເຮົາແກ້ໄຂ:

DROP INDEX tbl_fk_cli_idx;
CREATE INDEX ON tbl(fk_cli, pk DESC); -- добавили ключ сортировки

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ເຖິງແມ່ນວ່າຢູ່ໃນຕົວຢ່າງເບື້ອງຕົ້ນດັ່ງກ່າວ - ໄວກວ່າ 8.5x ແລະອ່ານໜ້ອຍລົງ 33x. ຜົນກະທົບຈະຊັດເຈນກວ່າ, ຫຼາຍ "ຄວາມຈິງ" ທ່ານມີສໍາລັບແຕ່ລະມູນຄ່າ. fk.

ຂ້າພະເຈົ້າສັງເກດວ່າດັດຊະນີດັ່ງກ່າວຈະເຮັດວຽກເປັນ "ຄໍານໍາຫນ້າ" ດັດຊະນີບໍ່ຮ້າຍແຮງກວ່າເກົ່າກ່ວາອັນທີ່ຜ່ານມາສໍາລັບການສອບຖາມອື່ນໆທີ່ມີ. fk, ບ່ອນທີ່ຈັດຮຽງຕາມ pk ບໍ່ແມ່ນ ແລະບໍ່ແມ່ນ (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ ໃນບົດຄວາມຂອງຂ້ອຍກ່ຽວກັບການຊອກຫາດັດສະນີທີ່ບໍ່ມີປະສິດທິພາບ). ໂດຍສະເພາະ, ມັນຈະສະຫນອງການປົກກະຕິ ການສະໜັບສະໜູນຫຼັກຂອງຕ່າງປະເທດຢ່າງຈະແຈ້ງ ໂດຍພາກສະຫນາມນີ້.

#2: ຈຸດຕັດກັນຂອງດັດຊະນີ (BitmapAnd)

ເມື່ອ​ເກີດ​ຂຶ້ນ

ສະແດງສັນຍາທັງຫມົດສໍາລັບລູກຄ້າ "LLC Kolokolchik" ສະຫຼຸບໃນນາມຂອງ "NJSC Lyutik".

ວິທີການກໍານົດ

-> BitmapAnd
   -> Bitmap Index Scan
   -> Bitmap Index Scan

ຂໍ້ສະເຫນີແນະ

ສ້າງ ດັດຊະນີປະສົມ ໂດຍຊ່ອງຂໍ້ມູນຈາກທັງສອງແຫຼ່ງ ຫຼືຂະຫຍາຍໜຶ່ງໃນຊ່ອງຂໍ້ມູນທີ່ມີຢູ່ແລ້ວຈາກອັນທີສອງ.

ຕົວຢ່າງ:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org); -- индекс для foreign key
CREATE INDEX ON tbl(fk_cli); -- индекс для foreign key

SELECT
  *
FROM
  tbl
WHERE
  (fk_org, fk_cli) = (1, 999); -- отбор по конкретной паре

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ພວກເຮົາແກ້ໄຂ:

DROP INDEX tbl_fk_org_idx;
CREATE INDEX ON tbl(fk_org, fk_cli);

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ໃນທີ່ນີ້ຜົນປະໂຫຍດແມ່ນນ້ອຍລົງ, ນັບຕັ້ງແຕ່ Bitmap Heap Scan ແມ່ນຂ້ອນຂ້າງມີປະສິດທິພາບຂອງມັນເອງ. ແຕ່ຢ່າງໃດກໍ່ຕາມ ໄວກວ່າ 7x ແລະອ່ານໜ້ອຍລົງ 2.5x.

#3: ການລວມດັດຊະນີ (BitmapOr)

ເມື່ອ​ເກີດ​ຂຶ້ນ

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

ວິທີການກໍານົດ

-> BitmapOr
   -> Bitmap Index Scan
   -> Bitmap Index Scan

ຂໍ້ສະເຫນີແນະ

ໃຊ້ ສະຫະພັນ [ທັງໝົດ] ເພື່ອສົມທົບການສອບຖາມຍ່ອຍສໍາລັບແຕ່ລະເງື່ອນໄຂ OR ຕັນ.

ຕົວຢ່າງ:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk  -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL -- с вероятностью 1:16 запись "ничья"
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own;

CREATE INDEX ON tbl(fk_own, pk); -- индекс с "вроде как подходящей" сортировкой

SELECT
  *
FROM
  tbl
WHERE
  fk_own = 1 OR -- свои
  fk_own IS NULL -- ... или "ничьи"
ORDER BY
  pk
, (fk_own = 1) DESC -- сначала "свои"
LIMIT 20;

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ພວກເຮົາແກ້ໄຂ:

(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own = 1 -- сначала "свои" 20
  ORDER BY
    pk
  LIMIT 20
)
UNION ALL
(
  SELECT
    *
  FROM
    tbl
  WHERE
    fk_own IS NULL -- потом "ничьи" 20
  ORDER BY
    pk
  LIMIT 20
)
LIMIT 20; -- но всего - 20, больше и не надо

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ພວກເຮົາໄດ້ໃຊ້ປະໂຍດຈາກຄວາມຈິງທີ່ວ່າບັນທຶກທີ່ຈໍາເປັນທັງຫມົດ 20 ໄດ້ຖືກໄດ້ຮັບທັນທີໃນທ່ອນໄມ້ທໍາອິດ, ດັ່ງນັ້ນອັນທີສອງ, ດ້ວຍການສະແກນ Bitmap Heap "ລາຄາແພງກວ່າ", ບໍ່ໄດ້ຖືກປະຕິບັດ - ດັ່ງນັ້ນ. ໄວກວ່າ 22x, ອ່ານໜ້ອຍລົງ 44x!

ເລື່ອງລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບວິທີການເພີ່ມປະສິດທິພາບນີ້ ກ່ຽວກັບຕົວຢ່າງທີ່ຊັດເຈນ ສາມາດອ່ານໄດ້ໃນບົດຄວາມ PostgreSQL Antipatterns: ການເຂົ້າຮ່ວມທີ່ເປັນອັນຕະລາຍ ແລະ ORs и PostgreSQL Antipatterns: ນິທານເລື່ອງຂອງການປັບປຸງໃຫມ່ຂອງການຄົ້ນຫາໂດຍຊື່, ຫຼື "ການເພີ່ມປະສິດທິພາບກັບຄືນໄປບ່ອນແລະອອກໄປ".

ສະບັບທົ່ວໄປ ສັ່ງເລືອກດ້ວຍຫຼາຍປຸ່ມ (ແລະບໍ່ພຽງແຕ່ສໍາລັບຄູ່ຂອງ const / NULL) ແມ່ນສົນທະນາໃນບົດຄວາມ SQL HowTo: ຂຽນ while-loop ໂດຍກົງໃນການສອບຖາມ, ຫຼື "ປະຖົມສາມທາງ".

#4: ພວກເຮົາອ່ານຫຼາຍເກີນໄປ

ເມື່ອ​ເກີດ​ຂຶ້ນ

ຕາມກົດລະບຽບ, ມັນເກີດຂື້ນໃນເວລາທີ່ທ່ານຕ້ອງການ "ແນບຕົວກອງອື່ນ" ກັບຄໍາຮ້ອງຂໍທີ່ມີຢູ່.

"ແລະເຈົ້າບໍ່ມີຄືກັນ, ແຕ່ ມີປຸ່ມໄຂ່ມຸກ? » ຮູບເງົາ "ມືເພັດ"

ຕົວຢ່າງ, ການແກ້ໄຂວຽກງານຂ້າງເທິງ, ສະແດງໃຫ້ເຫັນ 20 ຄໍາຮ້ອງຂໍ "ສໍາຄັນ" ທີ່ເກົ່າແກ່ທີ່ສຸດສໍາລັບການປຸງແຕ່ງ, ໂດຍບໍ່ຄໍານຶງເຖິງຈຸດປະສົງຂອງພວກເຂົາ.

ວິທີການກໍານົດ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && 5 × rows < RRbF -- отфильтровано >80% прочитанного
   && loops × RRbF > 100 -- и при этом больше 100 записей суммарно

ຂໍ້ສະເຫນີແນະ

ສ້າງ [ເພີ່ມເຕີມ] ພິເສດ index ກັບ WHERE clause ຫຼືລວມເອົາຊ່ອງຂໍ້ມູນເພີ່ມເຕີມໃນດັດຊະນີ.

ຖ້າເງື່ອນໄຂການກັ່ນຕອງແມ່ນ "static" ສໍາລັບວຽກງານຂອງທ່ານ - ນັ້ນແມ່ນ ບໍ່ລວມການຂະຫຍາຍ ບັນຊີລາຍຊື່ຂອງມູນຄ່າໃນອະນາຄົດ - ມັນດີກວ່າທີ່ຈະໃຊ້ດັດສະນີ WHERE. ສະຖານະ boolean/enum ຕ່າງໆ ເໝາະກັບປະເພດນີ້.

ຖ້າເງື່ອນໄຂການກັ່ນຕອງ ສາມາດເອົາຄ່າທີ່ແຕກຕ່າງກັນ, ມັນດີກວ່າທີ່ຈະຂະຫຍາຍດັດຊະນີກັບຂົງເຂດເຫຼົ່ານີ້ - ຄືກັບສະຖານະການທີ່ມີ BitmapAnd ຂ້າງເທິງ.

ຕົວຢ່າງ:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk -- 100K "фактов"
, CASE
    WHEN random() < 1::real/16 THEN NULL
    ELSE (random() * 100)::integer -- 100 разных внешних ключей
  END fk_own
, (random() < 1::real/50) critical; -- 1:50, что заявка "критичная"

CREATE INDEX ON tbl(pk);
CREATE INDEX ON tbl(fk_own, pk);

SELECT
  *
FROM
  tbl
WHERE
  critical
ORDER BY
  pk
LIMIT 20;

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ພວກເຮົາແກ້ໄຂ:

CREATE INDEX ON tbl(pk)
  WHERE critical; -- добавили "статичное" условие фильтрации

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການກັ່ນຕອງຈາກແຜນການແມ່ນຫມົດໄປ, ແລະການຮ້ອງຂໍໄດ້ກາຍເປັນ ໄວກວ່າ 5 ເທົ່າ.

#5: ຕາຕະລາງກະແຈກກະຈາຍ

ເມື່ອ​ເກີດ​ຂຶ້ນ

ຄວາມພະຍາຍາມຕ່າງໆເພື່ອເຮັດໃຫ້ຄິວການປຸງແຕ່ງວຽກງານຂອງທ່ານເອງ, ເມື່ອຈໍານວນການປັບປຸງ / ການລຶບບັນທຶກໃນຕາຕະລາງຈໍານວນຫລາຍເຮັດໃຫ້ສະຖານະການຂອງບັນທຶກ "ຕາຍ" ຈໍານວນຫລາຍ.

ວິທີການກໍານົດ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

ຂໍ້ສະເຫນີແນະ

ປະຕິບັດດ້ວຍຕົນເອງເປັນປົກກະຕິ ສູນຍາກາດ [FULL] ຫຼືບັນລຸການປຸງແຕ່ງເລື້ອຍໆຢ່າງພຽງພໍ ອັດຕະໂນມັດ ໂດຍການປັບປຸງຕົວກໍານົດການຂອງມັນ, ລວມທັງ ສໍາລັບຕາຕະລາງສະເພາະ.

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ບັນຫາດັ່ງກ່າວແມ່ນເກີດມາຈາກຮູບແບບການສອບຖາມທີ່ບໍ່ດີເມື່ອຖືກເອີ້ນຈາກເຫດຜົນທາງທຸລະກິດ, ເຊັ່ນວ່າການສົນທະນາໃນ. PostgreSQL Antipatterns: ຕໍ່ສູ້ກັບ hordes ຂອງ "ຕາຍ".

ແຕ່ພວກເຮົາຕ້ອງເຂົ້າໃຈວ່າເຖິງແມ່ນວ່າ VACUUM FULL ກໍ່ບໍ່ສາມາດຊ່ວຍໄດ້ສະເໝີ. ສໍາລັບກໍລະນີດັ່ງກ່າວ, ທ່ານຄວນຄຸ້ນເຄີຍກັບ algorithm ຈາກບົດຄວາມ. DBA: ເມື່ອ VACUUM ຜ່ານໄປ, ພວກເຮົາເຮັດຄວາມສະອາດຕາຕະລາງດ້ວຍຕົນເອງ.

#6: ອ່ານຈາກ "ກາງ" ຂອງດັດຊະນີ

ເມື່ອ​ເກີດ​ຂຶ້ນ

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

ວິທີການກໍານົດ

-> Index [Only] Scan [Backward]
   && loops × (rows + RRbF) < (shared hit + shared read) × 8
      -- прочитано больше 1KB на каждую запись
   && shared hit + shared read > 64

ຂໍ້ສະເຫນີແນະ

ກວດເບິ່ງໂຄງສ້າງຂອງດັດຊະນີທີ່ນໍາໃຊ້ແລະພາກສະຫນາມທີ່ສໍາຄັນທີ່ລະບຸໄວ້ໃນແບບສອບຖາມ - ສ່ວນຫຼາຍອາດຈະ, ສ່ວນດັດສະນີບໍ່ໄດ້ຕັ້ງ. ສ່ວນຫຼາຍເຈົ້າຈະຕ້ອງສ້າງດັດສະນີທີ່ຄ້າຍຄືກັນ, ແຕ່ບໍ່ມີ prefix fields, ຫຼື ຮຽນຮູ້ທີ່ຈະ iterate ຄຸນຄ່າຂອງເຂົາເຈົ້າ.

ຕົວຢ່າງ:

CREATE TABLE tbl AS
SELECT
  generate_series(1, 100000) pk      -- 100K "фактов"
, (random() *  100)::integer fk_org  -- 100 разных внешних ключей
, (random() * 1000)::integer fk_cli; -- 1K разных внешних ключей

CREATE INDEX ON tbl(fk_org, fk_cli); -- все почти как в #2
-- только вот отдельный индекс по fk_cli мы уже посчитали лишним и удалили

SELECT
  *
FROM
  tbl
WHERE
  fk_cli = 999 -- а fk_org не задано, хотя стоит в индексе раньше
LIMIT 20;

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ທຸກຢ່າງເບິ່ງຄືວ່າດີ, ເຖິງແມ່ນວ່າໃນແງ່ຂອງດັດສະນີ, ແຕ່ມີຄວາມສົງໃສບາງຢ່າງ - ສໍາລັບແຕ່ລະບັນທຶກ 20 ທີ່ອ່ານ, 4 ຫນ້າຂອງຂໍ້ມູນຕ້ອງຖືກຫັກອອກ, 32KB ຕໍ່ບັນທຶກ - ມັນບໍ່ກ້າຫານບໍ? ແມ່ນແລະຊື່ດັດສະນີ tbl_fk_org_fk_cli_idx ນໍາໄປສູ່ຄວາມຄິດ.

ພວກເຮົາແກ້ໄຂ:

CREATE INDEX ON tbl(fk_cli);

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ທັນ​ທີ​ທັນ​ໃດ - ໄວກວ່າ 10 ເທົ່າ ແລະອ່ານໜ້ອຍລົງ 4 ເທົ່າ!

ສໍາລັບຕົວຢ່າງເພີ່ມເຕີມຂອງການນໍາໃຊ້ດັດສະນີທີ່ບໍ່ມີປະສິດທິພາບ, ເບິ່ງບົດຄວາມ DBA: ຊອກຫາດັດສະນີທີ່ບໍ່ມີປະໂຫຍດ.

#7: CTE × CTE

ເມື່ອ​ເກີດ​ຂຶ້ນ

ໃນການຮ້ອງຂໍ ໄດ້ຄະແນນ "ໄຂມັນ" CTE ຈາກຕາຕະລາງທີ່ແຕກຕ່າງກັນ, ແລະຫຼັງຈາກນັ້ນຕັດສິນໃຈເຮັດລະຫວ່າງເຂົາເຈົ້າ JOIN.

ກໍ​ລະ​ນີ​ທີ່​ກ່ຽວ​ຂ້ອງ​ສໍາ​ລັບ​ການ​ສະ​ບັບ​ຂ້າງ​ລຸ່ມ​ນີ້ v12 ຫຼື​ການ​ຮ້ອງ​ຂໍ​ກັບ​ WITH MATERIALIZED.

ວິທີການກໍານົດ

-> CTE Scan
   && loops > 10
   && loops × (rows + RRbF) > 10000
      -- слишком большое декартово произведение CTE

ຂໍ້ສະເຫນີແນະ

ວິເຄາະຄໍາຮ້ອງຂໍຢ່າງລະອຽດ CTEs ມີຄວາມຈໍາເປັນຢູ່ທີ່ນີ້ທັງຫມົດ? ຖ້າແມ່ນ, ຫຼັງຈາກນັ້ນ ນຳໃຊ້ "ວັດຈະນານຸກົມ" ໃນ hstore/json ອີງຕາມຕົວແບບທີ່ໄດ້ອະທິບາຍໄວ້ໃນ PostgreSQL Antipatterns: Dictionary Hit Heavy JOIN.

#8: swap to disk ( temp ຂຽນ​)

ເມື່ອ​ເກີດ​ຂຶ້ນ

ການປະມວນຜົນຄັ້ງດຽວ (ການຈັດຮຽງຫຼືການເປັນເອກະລັກ) ຂອງບັນທຶກຈໍານວນຫລາຍບໍ່ເຫມາະສົມກັບຫນ່ວຍຄວາມຈໍາທີ່ຈັດສັນສໍາລັບການນີ້.

ວິທີການກໍານົດ

-> *
   && temp written > 0

ຂໍ້ສະເຫນີແນະ

ຖ້າຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ໂດຍການດໍາເນີນງານບໍ່ເກີນມູນຄ່າທີ່ກໍານົດໄວ້ຂອງພາລາມິເຕີ work_mem, ມັນຄວນຈະຖືກແກ້ໄຂ. ທ່ານສາມາດທັນທີໃນການຕັ້ງຄ່າສໍາລັບທຸກຄົນ, ຫຼືທ່ານສາມາດຜ່ານ SET [LOCAL] ສໍາລັບການຮ້ອງຂໍ / ການເຮັດທຸລະກໍາສະເພາະ.

ຕົວຢ່າງ:

SHOW work_mem;
-- "16MB"

SELECT
  random()
FROM
  generate_series(1, 1000000)
ORDER BY
  1;

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ພວກເຮົາແກ້ໄຂ:

SET work_mem = '128MB'; -- перед выполнением запроса

[ເບິ່ງທີ່ອະທິບາຍ.tensor.ru]

ສໍາລັບເຫດຜົນທີ່ຊັດເຈນ, ຖ້າພຽງແຕ່ຫນ່ວຍຄວາມຈໍາຖືກນໍາໃຊ້ແລະບໍ່ແມ່ນແຜ່ນ, ຫຼັງຈາກນັ້ນການສອບຖາມຈະໄວຂຶ້ນຫຼາຍ. ໃນເວລາດຽວກັນ, ບາງສ່ວນຂອງການໂຫຼດຍັງຖືກໂຍກຍ້າຍອອກຈາກ HDD.

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

#9: ສະຖິຕິທີ່ບໍ່ກ່ຽວຂ້ອງ

ເມື່ອ​ເກີດ​ຂຶ້ນ

ຫຼາຍ​ຢ່າງ​ໄດ້​ຖືກ​ຖອກ​ລົງ​ໃສ່​ຖານ​ໃນ​ເວ​ລາ​ດຽວ, ແຕ່​ພວກ​ເຂົາ​ເຈົ້າ​ບໍ່​ມີ​ເວ​ລາ​ທີ່​ຈະ​ຂັບ​ລົດ​ມັນ​ໄປ ANALYZE.

ວິທີການກໍານົດ

-> Seq Scan | Bitmap Heap Scan | Index [Only] Scan [Backward]
   && ratio >> 10

ຂໍ້ສະເຫນີແນະ

ໃຊ້ຈ່າຍຄືກັນ ANALYZE.

ສະຖານະການນີ້ໄດ້ຖືກອະທິບາຍໃນລາຍລະອຽດເພີ່ມເຕີມໃນ PostgreSQL Antipatterns: ສະຖິຕິເປັນຫົວຫນ້າຂອງທຸກສິ່ງທຸກຢ່າງ.

#10: "ມີບາງຢ່າງຜິດພາດ"

ເມື່ອ​ເກີດ​ຂຶ້ນ

ມີການລັອກລໍຖ້າຄໍາຮ້ອງຂໍການແຂ່ງຂັນ, ຫຼືບໍ່ມີຊັບພະຍາກອນຮາດແວ CPU/hypervisor ບໍ່ພຽງພໍ.

ວິທີການກໍານົດ

-> *
   && (shared hit / 8K) + (shared read / 1K) < time / 1000
      -- RAM hit = 64MB/s, HDD read = 8MB/s
   && time > 100ms -- читали мало, но слишком долго

ຂໍ້ສະເຫນີແນະ

ໃຊ້ພາຍນອກ ລະ​ບົບ​ຕິດ​ຕາມ​ກວດ​ກາ​ ເຄື່ອງແມ່ຂ່າຍສໍາລັບການສະກັດຫຼືການບໍລິໂພກຊັບພະຍາກອນທີ່ຜິດປົກກະຕິ. ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບສະບັບຂອງພວກເຮົາໃນການຈັດຕັ້ງຂະບວນການນີ້ສໍາລັບເຄື່ອງແມ່ຂ່າຍຫຼາຍຮ້ອຍຄົນ. ທີ່ນີ້ и ທີ່ນີ້.

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