ทำไมฉันถึงชอบ ALGORITHM = COPY ถึง ALGORITHM = INPLACE

ตั้งแต่ MySQL 5.6 แนะนำ DDL ออนไลน์ALTER TABLEคำสั่งสามารถเลือกที่จะมีALGORITHM=INPLACEหรือALGORITHM=COPYระบุก็ได้ ภาพรวมของ DDL ออนไลน์หมายเหตุที่โดยปกติINPLACEจะใช้ที่ใดก็ตามที่เป็นไปได้และหมายถึง (โดยที่ไม่เคยระบุว่าค่อนข้าง) ว่าINPLACEอัลกอริทึมที่มีราคาถูกกว่าCOPYหนึ่งคือ

ดังนั้นฉันจะต้องระบุเหตุผลอะไรALGORITHM=COPYในALTER TABLEแถลงการณ์?

ใช่มีกรณีเมื่อคุณอาจระบุCOPYแต่มันจะเป็นด้วยเหตุผลอื่นนอกเหนือประสิทธิภาพ

สิ่งสำคัญคือต้องเข้าใจว่า MySQL แนะนำคุณสมบัติใหม่ - การประมวลผล DLL ออนไลน์ในรุ่น 5.6 มันไม่ได้ลบการประมวลผลออฟไลน์ ดังนั้นจึงจำเป็นต้องแยกความแตกต่างระหว่าง 2 โหมดนี้:

1. การทำงานบางอย่างยังคงทำงานในโหมดออฟไลน์เท่านั้น ดูตาราง 15.10“ สรุปสถานะออนไลน์สำหรับการปฏิบัติการ DDL ” สำหรับรายการการดำเนินการ DDL ที่สามารถหรือไม่สามารถดำเนินการได้

2. การทำงานในโหมดออนไลน์และออฟไลน์มีพฤติกรรมแตกต่างกันเล็กน้อยดังนั้นคุณสามารถเลือก "เก่า" เพื่อเหตุผลด้านความเข้ากันได้

ตัวอย่างบางส่วน (โปรดแนะนำเพิ่มเติม):

1. ตาราง InnoDB สร้างขึ้นก่อน MySQL 5.6 ไม่สนับสนุนALTER TABLE ... ALGORITHM=INPLACEสำหรับตารางที่มีคอลัมน์ชั่วคราว ( DATE, DATETIMEหรือTIMESTAMP) ALTER TABLE ... ALGORITHM=COPYและยังไม่ได้รับการสร้างขึ้นมาใหม่โดยใช้ ในกรณีนี้การALTER TABLE ... ALGORITHM=INPLACEดำเนินการส่งคืนข้อผิดพลาด

2. ADD PRIMARY KEYข้อในการCOPY modeแปลงเงียบNULLไปเป็นค่าเริ่มต้นสำหรับชนิดข้อมูลนั้น (0 สำหรับ INT สตริงว่างสำหรับ varchar) ในขณะที่IN_PLACEไม่ทำอย่างนั้น

ด้วย ALGORITHM = ส่วนคำสั่งการดำเนินการสำเร็จแม้จะมีค่า NULL ในคอลัมน์คีย์หลัก ข้อมูลถูกเปลี่ยนแปลงอย่างเงียบ ๆ ซึ่งอาจทำให้เกิดปัญหา

อีกเหตุผลที่ชอบCOPY:

การดำเนินการที่คุณระบุ ALGORITHM = COPY หรือ old_alter_table = 1 เพื่อบังคับใช้พฤติกรรมการคัดลอกตารางหากจำเป็นสำหรับความเข้ากันได้แบบย้อนหลังที่แม่นยำในสถานการณ์เฉพาะ

แม้ว่าคู่มือ MySQL จะไม่พูดถึงสถานการณ์จริง แต่คุณสามารถจินตนาการได้ นักพัฒนาเช่นอาศัยตารางที่ถูกล็อคในระหว่างALTER INDEXการดำเนินการเพื่อให้ตารางเป็นแบบอ่านอย่างเดียวหรือล็อกอย่างเต็มที่และมีกระบวนการที่อ่านตารางแบบคงที่ในระหว่างการสร้างดัชนีใหม่

@ Stoleg อาจมีคำตอบที่ดีที่สุด แต่นี่เป็นอีกคำตอบหนึ่ง มันเดาการศึกษาว่านักพัฒนาที่เหลือในฐานะผู้หนีออกจากไข่ในกรณีที่มีข้อผิดพลาดร้ายแรงใน=COPY =INLINEสิ่งนี้จะช่วยให้ผู้ใช้ยังคงใช้งานต่อไปALTERแม้ว่าคุณสมบัติใหม่จะใช้งานไม่ได้

ฉันได้เห็นสิ่งต่าง ๆ เช่นนี้ (ในธงsql_mode, my.cnfการตั้งค่า ฯลฯ ) ในช่วงหลายปีที่ผ่านมา ความตั้งใจของรุ่นใหม่นั้นชัดเจนเพื่อนำเสนอคุณสมบัติใหม่ที่ดีกว่าออกมา

การเพิ่มประสิทธิภาพตั้งค่าสถานะตกอยู่ในหมวดหมู่นี้ แต่มีเหตุผลมากขึ้นที่จะยึดติดกับการกระทำก่อนหน้านี้ - เครื่องมือเพิ่มประสิทธิภาพมักจะ "ทำผิด" บางครั้ง; มีความเป็นไปได้มากเกินไป

ในรุ่นของ MySQL ที่รองรับการเข้ารหัสแบบอินเทอร์เฟซของ InnoDB tablespace เมื่อคุณเปลี่ยนตารางเพื่อเพิ่มการเข้ารหัสการเปลี่ยนแปลงนั้นทำได้โดยใช้อัลกอริธึมการคัดลอกที่ไม่จำเป็น