วิธีในการป้องกันคิวรีไม่ให้รอการล็อกระดับตาราง

เราพบปัญหาหลังจากย้ายฐานข้อมูลของลูกค้าไปยังเซิร์ฟเวอร์เพิ่มเติม สิ่งนี้ควรมีผลในเชิงบวกต่อประสิทธิภาพของไซต์ แต่มีปัญหากับการล็อคตารางใน MyISAM (ฉันเคยได้ยินการใช้ InnoDB แทน MyISAM แต่เราไม่สามารถเปลี่ยนเครื่องยนต์ได้ในอนาคตอันใกล้)
เราสามารถตรวจสอบมันไปยังแบบสอบถามการปรับปรุงซึ่งจะดำเนินการเมื่อผู้ดูแลเปิดใช้งานความคิดเห็นในบทความ นี่คือกระบวนการ:

• มีการประมวลผลการอัพเดตเคียวรี SET status = 1 WHERE id = 5(ตั้งค่าดัชนีแล้ว)
• ไฟล์แคชของหน้าจะถูกลบ

เมื่อมาถึงจุดนี้ทั้งหน้าจะช้า ฐานข้อมูลไม่ว่างเป็นเวลาหลายนาที ฉันเรียก processlist ไม่กี่ครั้งและเห็นประมาณ 60 รายการที่แตกต่างกันการเลือกคำสั่งซึ่งทุกคนในรัฐรอล็อคระดับตาราง

1. ฉันไม่ได้ยกเลิกการยืนยันว่าเหตุใดการอัปเดตนี้ในตารางarticle_commentsอาจส่งผลกระทบต่อข้อความเลือกสำหรับตารางarticleเพื่อรอการล็อกระดับตาราง ในรายการกระบวนการแบบสอบถามที่รอเกือบทั้งหมดมาจากตารางนี้ ฉันได้อ่านเกี่ยวกับความจริงที่ว่าการปรับปรุง / การแทรกนั้นเป็นที่ต้องการของการเลือกและสิ่งนี้อาจทำให้เกิดปัญหาดังกล่าวได้ แต่ตัวบทความในตารางไม่ได้รับการอัพเดตเมื่อความคิดเห็นเปิดใช้งานดังนั้นการเลือกไม่ควรรอ ฉันผิดพลาดหรือไม่
2. มีอะไรอีกบ้างที่นอกเหนือจากการเปลี่ยนเป็น InnoDB เพื่อป้องกันพฤติกรรมนี้หรืออย่างน้อยก็เพื่อให้ได้สมดุลที่ดีขึ้น? ฉันหงุดหงิดมากเกี่ยวกับความจริงที่ว่าปัญหานี้ไม่ปรากฏขึ้นก่อนที่จะย้ายฐานข้อมูลไปยังเซิร์ฟเวอร์ใหม่ ฉันเดาว่ามีการกำหนดค่าผิดพลาดอยู่บ้าง แต่ฉันไม่รู้วิธีระบุตัวตน

MyISAM Storage Engine นั้นมีชื่อเสียงในด้านการล็อคตารางเต็มรูปแบบสำหรับ DML ใด ๆ (INSERTs, UPDATEs, DELETEs) InnoDB จะแก้ไขปัญหานี้ในระยะยาวอย่างแน่นอน

ฉันเขียนเกี่ยวกับข้อดีข้อเสียของการใช้ MyISAM กับ InnoDB

• InnoDB vs MyISAM พร้อมดัชนีมากมาย (05 ก.ค. 2555)
• InnoDB หรือ MyISAM ไหนเร็วกว่ากัน (03 พฤษภาคม 2012)
• มี gotchas เลยด้วยการแปลงจาก MyISAM เป็น InnoDB? (09 ม.ค. 2555)
• ฉันควรใช้เครื่องมือจัดเก็บข้อมูลอื่นนอกเหนือจาก MyISAM เพื่อปรับตารางเหล่านี้ให้เหมาะสมหรือควรได้รับดิสก์ที่ดีกว่า (07 ต.ค. 2554)
• ประโยชน์ของการล็อคระดับโต๊ะ (14 ก.ย. 2554)
• InnoDB และ MyISAM แตกต่างกันอย่างไร (14 เม.ย. 2554)

เกี่ยวกับคำถามปัจจุบันของคุณนี่เป็นสถานการณ์ที่เป็นไปได้:

• articleและarticle_commentsเป็นตาราง MyISAM
• article_commentsมีดัชนีตั้งแต่หนึ่งดัชนีขึ้นไปพร้อมstatusคอลัมน์
• การอัพเดตหน้าดัชนีสำหรับarticle_commentsถูกแคชใน MyISAM Key Buffer (ขนาดตามkey_buffer_size ) ทำให้หน้าดัชนีเก่าออกจาก MyISAM Key Buffer
• คุณมีคิวรี SELECT ที่ดำเนินการเข้าร่วมระหว่างarticleและarticle_comments

ในสถานการณ์ที่แนะนำของฉัน SELECT กับarticleตารางสามารถหยุดการอนุญาตให้เขียนได้เนื่องจากต้องรอarticle_commentsเป็นอิสระจาก DML ใด ๆ (ในกรณีนี้และUPDATE)

เมื่อมาถึงจุดนี้ทั้งหน้าจะช้า ฐานข้อมูลไม่ว่างเป็นเวลาหลายนาที

มีกลิ่นเหมือนคุณมี Query_cache ขนาดใหญ่ไหม?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

สำหรับระบบการผลิตที่มีการเขียนจำนวนมากคุณอาจปิด query_cache

รายการทั้งหมดใน query_cache สำหรับตารางที่กำหนดจะถูกลบทิ้งเมื่อการเขียนใด ๆเกิดขึ้นกับตารางนั้น ยิ่ง QC ยิ่งใหญ่ก็ยิ่งทำงานนี้ช้าลง

MyISAM ใช้การล็อค "ระดับตาราง" การอ่านและเขียนไม่สามารถเกิดขึ้นได้ในเวลาเดียวกัน (ในตารางเดียวกัน) ดิบ แต่มีประสิทธิภาพ