🥇ວິທີການເພີ່ມປະສິດທິພາບການສອບຖາມ LINQ ໃນ C#.NET

ການນໍາສະເຫນີ

В ບົດຂຽນນີ້ ບາງວິທີການເພີ່ມປະສິດທິພາບໄດ້ຖືກພິຈາລະນາ ສອບຖາມ LINQ.
ໃນທີ່ນີ້ພວກເຮົາຍັງນໍາສະເຫນີບາງວິທີການເພີ່ມເຕີມຕໍ່ກັບການເພີ່ມປະສິດທິພາບລະຫັດທີ່ກ່ຽວຂ້ອງກັບ ສອບຖາມ LINQ.

ມັນເປັນທີ່ຮູ້ຈັກວ່າ LINQ(Language-Integrated Query) ເປັນພາສາທີ່ງ່າຍດາຍ ແລະສະດວກໃນການສອບຖາມແຫຼ່ງຂໍ້ມູນ.

А LINQ ກັບ SQL ເປັນເທກໂນໂລຍີສໍາລັບການເຂົ້າເຖິງຂໍ້ມູນໃນ DBMS. ນີ້ແມ່ນເປັນເຄື່ອງມືທີ່ມີອໍານາດສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນ, ບ່ອນທີ່ການສອບຖາມໄດ້ຖືກສ້າງຂຶ້ນໂດຍຜ່ານພາສາປະກາດ, ຊຶ່ງຫຼັງຈາກນັ້ນຈະໄດ້ຮັບການປ່ຽນເປັນ. SQL ສອບຖາມ ເວທີແລະຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນສໍາລັບການປະຕິບັດ. ໃນກໍລະນີຂອງພວກເຮົາ, ໂດຍ DBMS ພວກເຮົາຫມາຍຄວາມວ່າ MS SQL Server.

ເຖິງຢ່າງໃດກໍ່ຕາມ, ສອບຖາມ LINQ ບໍ່ໄດ້ປ່ຽນເປັນລາຍລັກອັກສອນທີ່ດີທີ່ສຸດ SQL ສອບຖາມ, ເຊິ່ງ DBA ທີ່ມີປະສົບການສາມາດຂຽນດ້ວຍ nuances ທັງຫມົດຂອງການເພີ່ມປະສິດທິພາບ SQL ສອບຖາມ:

ການເຊື່ອມຕໍ່ທີ່ດີທີ່ສຸດ (ເຂົ້າຮ່ວມ) ແລະການກັ່ນຕອງຜົນໄດ້ຮັບ (ບ່ອນທີ່)
nuances ຫຼາຍໃນການນໍາໃຊ້ການເຊື່ອມຕໍ່ແລະເງື່ອນໄຂຂອງກຸ່ມ
ການປ່ຽນແປງຫຼາຍຢ່າງໃນການປ່ຽນເງື່ອນໄຂ IN ສຸດ ມີຢູ່и ບໍ່ຢູ່ໃນ, <> ສຸດ ມີຢູ່
caching ລະດັບປານກາງຂອງຜົນໄດ້ຮັບໂດຍຜ່ານຕາຕະລາງຊົ່ວຄາວ, CTE, ຕົວແປຕາຕະລາງ
ການນໍາໃຊ້ປະໂຫຍກ (ທາງເລືອກ) ມີຄໍາແນະນໍາແລະຄໍາແນະນໍາຕາຕະລາງ ກັບ ()
ການນໍາໃຊ້ການເບິ່ງດັດຊະນີເປັນຫນຶ່ງໃນວິທີການທີ່ຈະກໍາຈັດການອ່ານຂໍ້ມູນທີ່ຊໍ້າຊ້ອນໃນລະຫວ່າງການເລືອກ

ການປະຕິບັດຕົ້ນຕໍຂອງການຂັດຂວາງຜົນໄດ້ຮັບ SQL ສອບຖາມ ເມື່ອລວບລວມ ສອບຖາມ LINQ ແມ່ນ:

ການລວບລວມກົນໄກການຄັດເລືອກຂໍ້ມູນທັງຫມົດໃນຫນຶ່ງຄໍາຮ້ອງຂໍ
duplicating blocks ດຽວກັນຂອງລະຫັດ, ຊຶ່ງໃນທີ່ສຸດນໍາໄປສູ່ການອ່ານຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນຫຼາຍ
ກຸ່ມຂອງເງື່ອນໄຂຫຼາຍອົງປະກອບ (ເຫດຜົນ "ແລະ" ແລະ "ຫຼື") - ແລະ и OR, ປະສົມປະສານເຂົ້າໄປໃນເງື່ອນໄຂທີ່ສັບສົນ, ນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າ optimizer, ມີດັດຊະນີທີ່ບໍ່ແມ່ນກຸ່ມທີ່ເຫມາະສົມກັບຂົງເຂດທີ່ຈໍາເປັນ, ໃນທີ່ສຸດກໍ່ຈະເລີ່ມສະແກນກັບດັດຊະນີ clustered (INDEX ສະແກນ) ໂດຍກຸ່ມຂອງເງື່ອນໄຂ
ການສ້າງຮັງເລິກຂອງ subqueries ເຮັດໃຫ້ parsing ມີບັນຫາຫຼາຍ ຄຳຖະແຫຼງ SQL ແລະການວິເຄາະແຜນການສອບຖາມໃນສ່ວນຂອງນັກພັດທະນາແລະ DBA

ວິທີການເພີ່ມປະສິດທິພາບ

ຕອນນີ້ໃຫ້ພວກເຮົາຍ້າຍໂດຍກົງໄປຫາວິທີການເພີ່ມປະສິດທິພາບ.

1) ການສ້າງດັດສະນີເພີ່ມເຕີມ

ມັນເປັນສິ່ງທີ່ດີທີ່ສຸດທີ່ຈະພິຈາລະນາຕົວກອງໃນຕາຕະລາງການຄັດເລືອກຕົ້ນຕໍ, ເພາະວ່າເລື້ອຍໆການສອບຖາມທັງຫມົດແມ່ນສ້າງຂຶ້ນປະມານຫນຶ່ງຫຼືສອງຕາຕະລາງຕົ້ນຕໍ (ຄໍາຮ້ອງສະຫມັກ - ປະຊາຊົນ - ການດໍາເນີນງານ) ແລະມີເງື່ອນໄຂມາດຕະຖານ (IsClosed, Canceled, Enabled, Status). ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສ້າງຕົວຊີ້ວັດທີ່ເຫມາະສົມສໍາລັບຕົວຢ່າງທີ່ໄດ້ກໍານົດ.

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

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

ນອກຈາກນີ້, ການຂາດດັດສະນີສາມາດຖືກລະບຸໄດ້ໂດຍຜ່ານການເຕືອນສໍາລັບການວິເຄາະແຜນການສອບຖາມຫຼືເກັບກໍາສະຖິຕິການເບິ່ງລະບົບ. MS SQL Server:

ຂໍ້ມູນການເບິ່ງທັງໝົດມີຂໍ້ມູນກ່ຽວກັບດັດຊະນີທີ່ຂາດຫາຍໄປ, ຍົກເວັ້ນດັດຊະນີທາງກວ້າງຂອງພື້ນ.

ຢ່າງໃດກໍຕາມ, ດັດສະນີແລະຖານຄວາມຈໍາມັກຈະເປັນວິທີການຕໍ່ສູ້ກັບຜົນສະທ້ອນຂອງການຂຽນທີ່ບໍ່ດີ ສອບຖາມ LINQ и SQL ສອບຖາມ.

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

ນີ້ແມ່ນເຫດຜົນບາງສ່ວນ, ເພາະວ່າຜູ້ໃຊ້ບໍ່ຕ້ອງການຂໍ້ມູນລ້າສຸດສະເຫມີແລະມີລະດັບການຕອບສະຫນອງຂອງການໂຕ້ຕອບຜູ້ໃຊ້ທີ່ຍອມຮັບໄດ້.

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

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

ຖ້າຫາກວ່າມີດັດຊະນີທີ່ມີກໍານົດໄວ້ຄ້າຍຄືກັນຂອງພາກສະຫນາມ
ຖ້າຊ່ອງຂໍ້ມູນໃນຕາຕະລາງບໍ່ສາມາດຖືກດັດສະນີໄດ້ເນື່ອງຈາກຂໍ້ຈໍາກັດການດັດສະນີ (ອະທິບາຍລາຍລະອຽດເພີ່ມເຕີມ ທີ່ນີ້).

2) ການລວມຄຸນລັກສະນະເປັນຄຸນລັກສະນະໃຫມ່ຫນຶ່ງ

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

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

ຕົວຢ່າງ:

IsClosed = 0 AND Canceled = 0 AND Enabled = 0 ຖືກແທນທີ່ດ້ວຍ ສະຖານະ = 1.

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

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

3) ວັດສະດຸຂອງທັດສະນະ

ແຕ່ຫນ້າເສຍດາຍ, ໃນ ສອບຖາມ LINQ ຕາຕະລາງຊົ່ວຄາວ, CTEs, ແລະຕົວແປຕາຕະລາງບໍ່ສາມາດຖືກນໍາໃຊ້ໂດຍກົງ.

ຢ່າງໃດກໍ່ຕາມ, ມີວິທີອື່ນທີ່ຈະເພີ່ມປະສິດທິພາບສໍາລັບກໍລະນີນີ້ - indexed views .

ກຸ່ມເງື່ອນໄຂ (ຈາກຕົວຢ່າງຂ້າງເທິງ) IsClosed = 0 AND Canceled = 0 AND Enabled = 0 (ຫຼືຊຸດຂອງເງື່ອນໄຂທີ່ຄ້າຍຄືກັນອື່ນໆ) ກາຍເປັນທາງເລືອກທີ່ດີທີ່ຈະໃຊ້ພວກມັນໃນມຸມເບິ່ງທີ່ຖືກດັດສະນີ, ຈັດເກັບຂໍ້ມູນນ້ອຍໆຈາກຊຸດໃຫຍ່.

ແຕ່ມີຂໍ້ ຈຳ ກັດ ຈຳ ນວນ ໜຶ່ງ ໃນເວລາສ້າງທັດສະນະ:

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

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

ແຕ່ເມື່ອໂທຫາມຸມເບິ່ງ, ດັດຊະນີເຫຼົ່ານີ້ອາດຈະບໍ່ຖືກນໍາໃຊ້, ແລະເພື່ອນໍາໃຊ້ພວກມັນຢ່າງຈະແຈ້ງ, ທ່ານຕ້ອງລະບຸ. ກັບ(ບໍ່ຂະຫຍາຍ).

ຕັ້ງແຕ່ຢູ່ໃນ ສອບຖາມ LINQ ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກໍານົດຄໍາແນະນໍາໃນຕາຕະລາງ, ດັ່ງນັ້ນທ່ານຕ້ອງສ້າງຕົວແທນອື່ນ - "wrapper" ຂອງແບບຟອມຕໍ່ໄປນີ້:

CREATE VIEW ИМЯ_представления AS SELECT * FROM MAT_VIEW WITH (NOEXPAND);

4) ການນໍາໃຊ້ຫນ້າທີ່ຕາຕະລາງ

ມັກຢູ່ໃນ ສອບຖາມ LINQ ຕັນຂະຫນາດໃຫຍ່ຂອງ subqueries ຫຼືຕັນການນໍາໃຊ້ views ທີ່ມີໂຄງສ້າງສະລັບສັບຊ້ອນປະກອບເປັນຄໍາຖາມສຸດທ້າຍທີ່ມີໂຄງສ້າງການປະຕິບັດທີ່ສະລັບສັບຊ້ອນຫຼາຍແລະ suboptimal.

ຜົນປະໂຫຍດທີ່ສໍາຄັນຂອງການນໍາໃຊ້ຫນ້າທີ່ຕາຕະລາງໃນ ສອບຖາມ LINQ:

ຄວາມສາມາດ, ເຊັ່ນດຽວກັບກໍລະນີຂອງ views, ຖືກນໍາໃຊ້ແລະກໍານົດເປັນວັດຖຸ, ແຕ່ວ່າທ່ານສາມາດຜ່ານຊຸດຂອງຕົວກໍານົດການປ້ອນຂໍ້ມູນ:
ຈາກ FUNCTION(@param1, @param2 ...)
ດັ່ງນັ້ນ, ການເກັບຕົວຢ່າງຂໍ້ມູນທີ່ມີຄວາມຍືດຫຍຸ່ນສາມາດບັນລຸໄດ້
ໃນກໍລະນີຂອງການນໍາໃຊ້ຫນ້າທີ່ຕາຕະລາງ, ບໍ່ມີຂໍ້ຈໍາກັດທີ່ເຂັ້ມແຂງເຊັ່ນໃນກໍລະນີຂອງການເບິ່ງດັດສະນີໄດ້ອະທິບາຍຂ້າງເທິງ:
1. ຄໍາແນະນໍາຕາຕະລາງ:
  ໂດຍຜ່ານການ LINQ ທ່ານບໍ່ສາມາດລະບຸວ່າດັດຊະນີໃດຄວນຈະຖືກນໍາໃຊ້ແລະກໍານົດລະດັບການແຍກຂໍ້ມູນໃນເວລາທີ່ການສອບຖາມ.
  ແຕ່ຫນ້າທີ່ມີຄວາມສາມາດເຫຼົ່ານີ້.
  ດ້ວຍຟັງຊັນ, ທ່ານສາມາດບັນລຸແຜນການສອບຖາມການປະຕິບັດຄົງທີ່, ບ່ອນທີ່ກົດລະບຽບສໍາລັບການເຮັດວຽກກັບດັດສະນີແລະລະດັບການແຍກຂໍ້ມູນຖືກກໍານົດ.
2. ການນໍາໃຊ້ຫນ້າທີ່ອະນຸຍາດໃຫ້, ໃນການປຽບທຽບກັບມຸມເບິ່ງດັດສະນີ, ເພື່ອໃຫ້ໄດ້ຮັບ:
  - ເຫດຜົນການເກັບຕົວຢ່າງຂໍ້ມູນທີ່ຊັບຊ້ອນ (ແມ້ແຕ່ໃຊ້ loops)
  - ດຶງຂໍ້ມູນຈາກຕາຕະລາງທີ່ແຕກຕ່າງກັນຫຼາຍ
  - ການນໍາໃຊ້ຂອງ UNION и ມີຢູ່
ຂໍ້ສະ ເໜີ ທາງເລືອກ ມີປະໂຫຍດຫຼາຍເມື່ອພວກເຮົາຕ້ອງການໃຫ້ການຄວບຄຸມຄວາມສອດຄ່ອງກັນ OPTION(MAXDOP N), ຄໍາສັ່ງຂອງແຜນການປະຕິບັດການສອບຖາມ. ຍົກຕົວຢ່າງ:
- ທ່ານສາມາດກໍານົດການບັງຄັບໃຫ້ສ້າງແຜນການສອບຖາມຄືນໃຫມ່ ຕົວເລືອກ (ຕື່ມຂໍ້ມູນ)
- ທ່ານສາມາດກໍານົດວ່າຈະບັງຄັບແຜນການສອບຖາມເພື່ອນໍາໃຊ້ຄໍາສັ່ງເຂົ້າຮ່ວມທີ່ລະບຸໄວ້ໃນຄໍາຖາມ ຕົວເລືອກ (ບັງຄັບໃຫ້ສັ່ງ)
ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບ ທາງເລືອກ ອະທິບາຍ ທີ່ນີ້.
ການນໍາໃຊ້ຂະຫນາດຂໍ້ມູນທີ່ແຄບທີ່ສຸດແລະຕ້ອງການທີ່ສຸດ:
ບໍ່ຈໍາເປັນຕ້ອງເກັບຮັກສາຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່ໃນຖານຄວາມຈໍາ (ຄືກັນກັບກໍລະນີທີ່ມີມຸມເບິ່ງດັດສະນີ), ຈາກນັ້ນທ່ານຍັງຕ້ອງການກັ່ນຕອງຂໍ້ມູນໂດຍພາລາມິເຕີ.
ຕົວຢ່າງ, ມີຕາຕະລາງທີ່ມີຕົວກອງ ບ່ອນທີ່ ສາມພາກສະຫນາມຖືກນໍາໃຊ້ (a, b, c).

ຕາມທໍາມະດາ, ການຮ້ອງຂໍທັງຫມົດມີເງື່ອນໄຂຄົງທີ່ a = 0 ແລະ b = 0.

ຢ່າງໃດກໍຕາມ, ການຮ້ອງຂໍສໍາລັບພາກສະຫນາມ c ຕົວປ່ຽນແປງຫຼາຍກວ່າ.

ໃຫ້ເງື່ອນໄຂ a = 0 ແລະ b = 0 ມັນກໍ່ຊ່ວຍໃຫ້ພວກເຮົາຈໍາກັດການກໍານົດຜົນໄດ້ຮັບທີ່ກໍານົດໄວ້ເປັນພັນໆບັນທຶກ, ແຕ່ເງື່ອນໄຂໃນ с ຈຳກັດການເລືອກລົງເປັນຮ້ອຍບັນທຶກ.

ທີ່ນີ້ຫນ້າທີ່ຕາຕະລາງອາດຈະເປັນທາງເລືອກທີ່ດີກວ່າ.

ນອກຈາກນີ້, ຟັງຊັນຕາຕະລາງແມ່ນສາມາດຄາດເດົາໄດ້ຫຼາຍຂຶ້ນແລະສອດຄ່ອງໃນເວລາປະຕິບັດ.

ຕົວຢ່າງ

ໃຫ້ເບິ່ງການປະຕິບັດຕົວຢ່າງໂດຍໃຊ້ຖານຂໍ້ມູນຄໍາຖາມເປັນຕົວຢ່າງ.

ມີການຮ້ອງຂໍ SELECT, ເຊິ່ງລວມຕາຕະລາງຫຼາຍແລະນໍາໃຊ້ຫນຶ່ງເບິ່ງ (OperativeQuestions), ເຊິ່ງຄວາມກ່ຽວຂ້ອງໄດ້ຖືກກວດສອບໂດຍອີເມລ໌ (ຜ່ານ ມີຢູ່) ກັບ "ຄໍາຖາມປະຕິບັດງານ":

ຄໍາຮ້ອງສະຫມັກ 1

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM [dbo].[Questions] AS [Extent1]
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id],
[Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId],
[Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]) AND ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[OperativeQuestions] AS [Extent5]
WHERE (([Extent5].[Email] = @p__linq__0) OR (([Extent5].[Email] IS NULL) 
AND (@p__linq__0 IS NULL))) AND ([Extent5].[Id] = [Extent1].[Id])
));

ມຸມເບິ່ງມີໂຄງສ້າງທີ່ສັບສົນຫຼາຍ: ມັນມີ subquery ເຂົ້າຮ່ວມແລະນໍາໃຊ້ການຈັດລຽງ DISTINCT, ເຊິ່ງໂດຍທົ່ວໄປແລ້ວແມ່ນການດໍາເນີນງານທີ່ມີຊັບພະຍາກອນທີ່ຂ້ອນຂ້າງ.

ຕົວຢ່າງຈາກ OperativeQuestions ແມ່ນປະມານສິບພັນບັນທຶກ.

ບັນຫາຕົ້ນຕໍຂອງການສອບຖາມນີ້ແມ່ນວ່າສໍາລັບການບັນທຶກຈາກການສອບຖາມພາຍນອກ, ການສອບຖາມຍ່ອຍພາຍໃນຈະຖືກປະຕິບັດໃນມຸມເບິ່ງ [OperativeQuestions], ເຊິ່ງຄວນສໍາລັບ [Email] = @p__linq__0 ອະນຸຍາດໃຫ້ພວກເຮົາຈໍາກັດການເລືອກຜົນຜະລິດ (ຜ່ານ ມີຢູ່) ເຖິງຫຼາຍຮ້ອຍບັນທຶກ.

ແລະມັນອາດຈະເບິ່ງຄືວ່າ subquery ຄວນຄິດໄລ່ບັນທຶກຫນຶ່ງຄັ້ງໂດຍ [Email] = @p__linq__0, ແລະຫຼັງຈາກນັ້ນສອງສາມຮ້ອຍບັນທຶກເຫຼົ່ານີ້ຄວນຈະຖືກເຊື່ອມຕໍ່ໂດຍ Id ກັບຄໍາຖາມ, ແລະການສອບຖາມຈະໄວ.

ໃນຄວາມເປັນຈິງ, ມີການເຊື່ອມຕໍ່ຕາມລໍາດັບຂອງຕາຕະລາງທັງຫມົດ: ການກວດສອບການຕອບຄໍາຖາມຂອງ Id ກັບ Id ຈາກ OperativeQuestions, ແລະການກັ່ນຕອງໂດຍອີເມວ.

ໃນຄວາມເປັນຈິງ, ຄໍາຮ້ອງສະຫມັກເຮັດວຽກຮ່ວມກັບການທັງຫມົດສິບພັນຂອງການບັນທຶກຄໍາຖາມ Operative, ແຕ່ພຽງແຕ່ຂໍ້ມູນທີ່ສົນໃຈແມ່ນຕ້ອງການຜ່ານ Email.

ຄໍາຖາມປະຕິບັດງານເບິ່ງຂໍ້ຄວາມ:

ຄໍາຮ້ອງສະຫມັກ 2

 
CREATE VIEW [dbo].[OperativeQuestions]
AS
SELECT DISTINCT Q.Id, USR.email AS Email
FROM            [dbo].Questions AS Q INNER JOIN
                         [dbo].ProcessUserAccesses AS BPU ON BPU.ProcessId = CQ.Process_Id 
OUTER APPLY
                     (SELECT   1 AS HasNoObjects
                      WHERE   NOT EXISTS
                                    (SELECT   1
                                     FROM     [dbo].ObjectUserAccesses AS BOU
                                     WHERE   BOU.ProcessUserAccessId = BPU.[Id] AND BOU.[To] IS NULL)
) AS BO INNER JOIN
                         [dbo].Users AS USR ON USR.Id = BPU.UserId
WHERE        CQ.[Exp] = 0 AND CQ.AnswerId IS NULL AND BPU.[To] IS NULL 
AND (BO.HasNoObjects = 1 OR
              EXISTS (SELECT   1
                           FROM   [dbo].ObjectUserAccesses AS BOU INNER JOIN
                                      [dbo].ObjectQuestions AS QBO 
                                                  ON QBO.[Object_Id] =BOU.ObjectId
                               WHERE  BOU.ProcessUserAccessId = BPU.Id 
                               AND BOU.[To] IS NULL AND QBO.Question_Id = CQ.Id));

ແຜນທີ່ມຸມມອງເບື້ອງຕົ້ນໃນ DbContext (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}

ການສອບຖາມ LINQ ເບື້ອງຕົ້ນ

var businessObjectsData = await context
    .OperativeQuestions
    .Where(x => x.Email == Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

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

ເຖິງແມ່ນວ່ານີ້ແມ່ນການແກ້ໄຂທີ່ດີ, ມີທາງເລືອກອື່ນທີ່ຈະເພີ່ມປະສິດທິພາບບັນຫານີ້.

ຈຸດປະສົງຕົ້ນຕໍແມ່ນເພື່ອ cache entries ໂດຍ [Email] = @p__linq__0 ຈາກ OperativeQuestions view.

ແນະນໍາຟັງຊັນຕາຕະລາງ [dbo].[OperativeQuestionsUserMail] ເຂົ້າໄປໃນຖານຂໍ້ມູນ.

ໂດຍການສົ່ງອີເມວເປັນຕົວກໍານົດການປ້ອນຂໍ້ມູນ, ພວກເຮົາໄດ້ຮັບກັບຄືນມາຕາຕະລາງຂອງຄຸນຄ່າ:

ຄໍາຮ້ອງສະຫມັກ 3


CREATE FUNCTION [dbo].[OperativeQuestionsUserMail]
(
    @Email  nvarchar(4000)
)
RETURNS
@tbl TABLE
(
    [Id]           uniqueidentifier,
    [Email]      nvarchar(4000)
)
AS
BEGIN
        INSERT INTO @tbl ([Id], [Email])
        SELECT Id, @Email
        FROM [OperativeQuestions]  AS [x] WHERE [x].[Email] = @Email;
     
    RETURN;
END

ນີ້ສົ່ງຄືນຕາຕະລາງຂອງຄ່າທີ່ມີໂຄງສ້າງຂໍ້ມູນທີ່ກໍານົດໄວ້ກ່ອນ.

ເພື່ອໃຫ້ການສອບຖາມກັບ OperativeQuestionsUserMail ດີທີ່ສຸດແລະມີແຜນການສອບຖາມທີ່ດີທີ່ສຸດ, ຕ້ອງມີໂຄງສ້າງທີ່ເຄັ່ງຄັດ, ແລະບໍ່ແມ່ນ. ຕາຕະລາງສົ່ງຄືນຕາມການສົ່ງຄືນ...

ໃນກໍລະນີນີ້, Query 1 ທີ່ຕ້ອງການຈະຖືກປ່ຽນເປັນ Query 4:

ຄໍາຮ້ອງສະຫມັກ 4

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM (
    SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] (@p__linq__0)
) AS [Extent0]
INNER JOIN [dbo].[Questions] AS [Extent1] ON([Extent0].Id=[Extent1].Id)
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id], [Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId], [Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]);

ແຜນທີ່ມຸມເບິ່ງ ແລະຟັງຊັນໃນ DbContext (EF Core 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}
 
public static class FromSqlQueries
{
    public static IQueryable<OperativeQuestion> GetByUserEmail(this DbQuery<OperativeQuestion> source, string Email)
        => source.FromSql($"SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] ({Email})");
}

ການສອບຖາມ LINQ ສຸດທ້າຍ

var businessObjectsData = await context
    .OperativeQuestions
    .GetByUserEmail(Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

ຄໍາສັ່ງຂອງເວລາປະຕິບັດໄດ້ຫຼຸດລົງຈາກ 200-800 ms, ເປັນ 2-20 ms, ແລະອື່ນໆ, i.e. ຫຼາຍສິບເທື່ອໄວ.

ຖ້າພວກເຮົາເອົາມັນໂດຍສະເລ່ຍ, ຫຼັງຈາກນັ້ນແທນທີ່ຈະເປັນ 350 ms ພວກເຮົາໄດ້ຮັບ 8 ms.

ຈາກຂໍ້ໄດ້ປຽບທີ່ຈະແຈ້ງພວກເຮົາຍັງໄດ້ຮັບ:

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

ສະຫລຸບ

ການເພີ່ມປະສິດທິພາບແລະການປັບລະອຽດຂອງການໂທຖານຂໍ້ມູນ MS SQL ໂດຍຜ່ານການ LINQ ເປັນບັນຫາທີ່ສາມາດແກ້ໄຂໄດ້.

ຄວາມເອົາໃຈໃສ່ແລະຄວາມສອດຄ່ອງແມ່ນມີຄວາມສໍາຄັນຫຼາຍໃນວຽກງານນີ້.

ໃນຕອນເລີ່ມຕົ້ນຂອງຂະບວນການ:

ມັນເປັນສິ່ງຈໍາເປັນເພື່ອກວດກາເບິ່ງຂໍ້ມູນທີ່ຮ້ອງຂໍເຮັດວຽກ (ຄ່າ, ປະເພດຂໍ້ມູນທີ່ເລືອກ)
ດໍາເນີນການດັດສະນີຂໍ້ມູນນີ້ຢ່າງຖືກຕ້ອງ
ກວດເບິ່ງຄວາມຖືກຕ້ອງຂອງເງື່ອນໄຂການເຂົ້າຮ່ວມລະຫວ່າງຕາຕະລາງ

ການປັບປຸງແກ້ໄຂຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນວ່າ:

ພື້ນຖານຂອງຄໍາຮ້ອງຂໍແລະກໍານົດການກັ່ນຕອງຄໍາຮ້ອງຂໍຕົ້ນຕໍ
ເຮັດຊ້ໍາຄືນການສອບຖາມທີ່ຄ້າຍຄືກັນແລະການວິເຄາະຈຸດຕັດກັນຂອງເງື່ອນໄຂ
ໃນ SSMS ຫຼື GUI ອື່ນໆສໍາລັບ SQL Server optimizes ຕົວຂອງມັນເອງ SQL ສອບຖາມ (ການຈັດສັນການເກັບຮັກສາຂໍ້ມູນລະດັບປານກາງ, ສ້າງການສອບຖາມຜົນໄດ້ຮັບໂດຍໃຊ້ການເກັບຮັກສານີ້ (ອາດມີຫຼາຍ))
ໃນຂັ້ນຕອນສຸດທ້າຍ, ໃຊ້ເວລາເປັນພື້ນຖານຜົນໄດ້ຮັບ SQL ສອບຖາມ, ໂຄງສ້າງກໍາລັງຖືກສ້າງໃຫມ່ LINQ ສອບຖາມ

ຜົນໄດ້ຮັບ LINQ ສອບຖາມ ຄວນຈະກາຍເປັນໂຄງປະກອບການທີ່ດີທີ່ສຸດທີ່ກໍານົດໄວ້ SQL ສອບຖາມ ຈາກຈຸດ 3.

ຂອບໃຈ

ຂອບໃຈຫຼາຍໆກັບເພື່ອນຮ່ວມງານ ວຽກເຮັດງານທຳ и alex_ozr ຈາກບໍລິສັດ Fortis ສໍາລັບການຊ່ວຍເຫຼືອໃນການກະກຽມເອກະສານນີ້.

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

ວິທີການສໍາລັບການເພີ່ມປະສິດທິພາບການສອບຖາມ LINQ ໃນ C#.NET

ການນໍາສະເຫນີ

ວິທີການເພີ່ມປະສິດທິພາບ

1) ການສ້າງດັດສະນີເພີ່ມເຕີມ

2) ການລວມຄຸນລັກສະນະເປັນຄຸນລັກສະນະໃຫມ່ຫນຶ່ງ

3) ວັດສະດຸຂອງທັດສະນະ

4) ການນໍາໃຊ້ຫນ້າທີ່ຕາຕະລາງ

ຕົວຢ່າງ

ສະຫລຸບ

ຂອບໃຈ

ເພີ່ມຄວາມຄິດເຫັນ Отменитьответ

ວິທີການສໍາລັບການເພີ່ມປະສິດທິພາບການສອບຖາມ LINQ ໃນ C#.NET

ການນໍາສະເຫນີ

ວິທີການເພີ່ມປະສິດທິພາບ

1) ການສ້າງດັດສະນີເພີ່ມເຕີມ

2​) ການ​ລວມ​ຄຸນ​ລັກ​ສະ​ນະ​ເປັນ​ຄຸນ​ລັກ​ສະ​ນະ​ໃຫມ່​ຫນຶ່ງ​

3) ວັດສະດຸຂອງທັດສະນະ

4) ການນໍາໃຊ້ຫນ້າທີ່ຕາຕະລາງ

ຕົວຢ່າງ

ສະຫລຸບ

ຂອບໃຈ

ເພີ່ມຄວາມຄິດເຫັນ Отменитьответ

2) ການລວມຄຸນລັກສະນະເປັນຄຸນລັກສະນະໃຫມ່ຫນຶ່ງ