เพื่อความเรียบง่ายทริกเกอร์เป็นวิธีที่จะนำไปใช้ในการติดตามการเปลี่ยนแปลงฐานข้อมูลทุกประเภท อย่างไรก็ตามคุณต้องระวังสิ่งที่เกิดขึ้นภายใต้ประทุนเมื่อคุณใช้ทริกเกอร์
ตามที่MySQL Stored Procedure Programming , หน้า 256 ใต้หัว "Trigger Overhead" กล่าวว่า:
เป็นสิ่งสำคัญที่ต้องจำไว้ว่าสิ่งกระตุ้นให้เพิ่มค่าใช้จ่ายในคำสั่ง DML ที่พวกเขาใช้ จำนวนค่าโสหุ้ยที่แท้จริงจะขึ้นอยู่กับลักษณะของทริกเกอร์ แต่ --- เนื่องจากทริกเกอร์ MySQL ทั้งหมดเรียกใช้งานสำหรับแต่ละแถว --- ค่าโสหุ้ยสามารถสะสมอย่างรวดเร็วสำหรับข้อความที่ประมวลผลแถวจำนวนมาก คุณควรหลีกเลี่ยงการวางคำสั่ง SQL ที่มีราคาแพงหรือรหัสโพรซีเดอร์ในทริกเกอร์
คำอธิบายเพิ่มเติมของค่าใช้จ่ายทริกเกอร์จะได้รับในหน้า 529-531 จุดสรุปจากส่วนนั้นระบุสิ่งต่อไปนี้:
บทเรียนที่นี่คือ: เนื่องจากรหัสทริกเกอร์จะทำงานหนึ่งครั้งสำหรับทุกแถวที่ได้รับผลกระทบจากคำสั่ง DML ทริกเกอร์สามารถกลายเป็นปัจจัยที่สำคัญที่สุดในประสิทธิภาพของ DML ได้อย่างง่ายดาย โค้ดภายในร่างกายของทริกเกอร์จำเป็นต้องมีน้ำหนักเบาที่สุดเท่าที่จะเป็นไปได้และโดยเฉพาะอย่างยิ่งคำสั่ง SQL ใด ๆ ในทริกเกอร์ควรได้รับการสนับสนุนโดยดัชนีเมื่อใดก็ตามที่ทำได้
ไม่ได้กล่าวถึงในหนังสือเป็นอีกปัจจัยหนึ่งเมื่อใช้ทริกเกอร์: เมื่อพูดถึงการบันทึกการตรวจสอบโปรดระวังสิ่งที่คุณบันทึกข้อมูล ฉันพูดแบบนี้เพราะคุณควรเลือกที่จะเข้าสู่ตาราง MyISAM แต่ละ INSERT ลงในตาราง MyISAM ผลิตล็อคตารางเต็มรูปแบบในช่วง INSERT สิ่งนี้อาจกลายเป็นคอขวดที่ร้ายแรงในสภาพแวดล้อมที่มีการรับส่งข้อมูลสูงและธุรกรรมสูง นอกจากนี้หากทริกเกอร์ขัดกับตาราง InnoDB และคุณบันทึกการเปลี่ยนแปลงใน MyISAM จากภายในทริกเกอร์สิ่งนี้จะปิดใช้งานการปฏิบัติตาม ACID อย่างลับๆ (เช่นลดทรานแซคชั่นบล็อกให้เป็นพฤติกรรมการทำงานอัตโนมัติ)
เมื่อใช้ทริกเกอร์ในตาราง InnoDB และการเปลี่ยนแปลงการบันทึก
- ตารางที่คุณเข้าสู่ระบบคือ InnoDB
- คุณปิดการเติมข้อความอัตโนมัติ
- คุณตั้งค่าเริ่มต้นการทำธุรกรรม ... คอมมิชชัน / ย้อนกลับบล็อกอย่างทั่วถึง
ด้วยวิธีนี้บันทึกการตรวจสอบจะได้ประโยชน์จาก COMMIT / ROLLBACK เช่นเดียวกับตารางหลัก
เกี่ยวกับการใช้กระบวนงานที่เก็บไว้คุณจะต้องเรียกขั้นตอนที่เก็บไว้อย่างระมัดระวังทุก ๆ จุดของ DML กับตารางที่ถูกติดตาม หนึ่งอาจพลาดการเปลี่ยนแปลงการบันทึกในหน้ารหัสแอพพลิเคชั่นนับหมื่นบรรทัด การวางรหัสดังกล่าวในทริกเกอร์จะช่วยลดการค้นหาคำสั่ง DML ทั้งหมด
ข้อแม้
ขึ้นอยู่กับความซับซ้อนของการเรียกมันยังคงเป็นคอขวด หากคุณต้องการลดปัญหาคอขวดในการบันทึกการตรวจสอบมีสิ่งที่คุณสามารถทำได้ อย่างไรก็ตามมันจะต้องมีการเปลี่ยนแปลงโครงสร้างพื้นฐานเล็กน้อย
ใช้ฮาร์ดแวร์สินค้าโภคภัณฑ์สร้างเซิร์ฟเวอร์ DB อีกสองรายการ
เซิร์ฟเวอร์นี้จะลดการเขียน I / O บนฐานข้อมูลหลัก (MD) เนื่องจากการบันทึกการตรวจสอบ นี่คือวิธีที่คุณสามารถทำได้:
ขั้นตอนที่ 01) เปิดการบันทึกแบบไบนารีในฐานข้อมูลหลัก
ขั้นตอนที่ 02) ใช้เซิร์ฟเวอร์ราคาไม่แพงตั้งค่า MySQL (รุ่นเดียวกันกับ MD) โดยเปิดใช้งานการบันทึกแบบไบนารี นี่จะเป็น DM ตั้งค่าการจำลองแบบจาก MD เป็น DM
ขั้นตอนที่ 03) ใช้เซิร์ฟเวอร์ราคาถูกตัวที่สองตั้งค่า MySQL (รุ่นเดียวกันกับ MD) โดยปิดใช้งานการบันทึกแบบไบนารี การตั้งค่าแต่ละตารางการตรวจสอบการใช้--replicate ทำตาราง นี่จะเป็น AU ตั้งค่าการจำลองแบบจาก DM เป็น AU
ขั้นตอนที่ 04) mysqldump โครงสร้างตารางจาก MD และโหลดลงใน DM และ AU
ขั้นตอนที่ 05) แปลงตารางการตรวจสอบทั้งหมดใน MD เพื่อใช้เครื่องมือเก็บข้อมูล BLACKHOLE
ขั้นตอนที่ 06) แปลงตารางทั้งหมดใน DM และ AU เพื่อใช้เครื่องมือเก็บข้อมูล BLACKHOLE
ขั้นตอนที่ 07) แปลงตารางการตรวจสอบทั้งหมดใน AU เพื่อใช้เครื่องมือจัดเก็บ MyISAM
เมื่อทำเสร็จแล้ว
- DM จะทำซ้ำจาก MD และบันทึกข้อมูลในบันทึกไบนารีเท่านั้น
- ด้วย--replicate-do-table filter บนตารางการตรวจสอบทั้งหมด AU จะทำซ้ำจาก DM
สิ่งนี้จะเก็บข้อมูลการตรวจสอบในเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหากและยังลดการย่อยสลายการเขียน I / O ใด ๆ ที่ MD จะมีตามปกติ