สิ่งที่ฉันหมายถึงคือต่อไปนี้:
หากสร้างดัชนีบนตารางที่มีnแถวต้องใช้tเวลา จะสร้างดัชนีในตารางเดียวกันกับ1000*nใช้เวลาประมาณ1000*tเวลา
สิ่งที่ฉันพยายามทำให้สำเร็จคือการประเมินเวลาที่ใช้ในการสร้างดัชนีในฐานข้อมูลการผลิตโดยการสร้างดัชนีเดียวกันในฐานข้อมูลทดสอบขนาดเล็กมาก
คำตอบ:
การสร้างดัชนีเป็นการดำเนินการเรียงลำดับดังนั้นที่ดีที่สุดมีความซับซ้อนในการเติบโตของลำดับn log nโดยเฉลี่ย (คุณอาจพบว่าการทำดัชนีนั้นทำได้ดีกว่าในบางกรณีและไม่น่าจะแย่กว่านี้มาก)
หากหน้าข้อมูลที่เกี่ยวข้องทั้งหมดของคุณพอดีกับ RAM และอยู่ใน RAM แล้วและดัชนีก็จะพอดีเช่นกันและ DBMS ของคุณจะไม่บังคับให้เขียนหน้าดัชนีก่อนที่การสร้างจะเสร็จสมบูรณ์ (ดังนั้นบล็อกดัชนีจะไม่ถูกอัพเดตบนดิสก์หลายครั้งในระหว่าง การดำเนินการ) จากนั้นความเร็วในการเขียนดัชนีผลลัพธ์ไปยังดิสก์จะมีความสำคัญมากกว่าเวลาที่ใช้ในการเรียงลำดับดังนั้นคุณอาจพบว่าคุณเข้าใกล้ความสัมพันธ์เชิงเส้นระหว่างจำนวนแถวและเวลาที่ใช้สร้างดัชนีมากขึ้น - แต่ถ้าคุณสมมติว่าแย่กว่านี้คุณก็จะไม่แปลกใจเท่าไรนัก!
โปรดจำไว้ว่าหากคุณไม่หยุดการเข้าถึงฐานข้อมูลการผลิตระหว่างการดำเนินการใด ๆ ที่ดัชนีที่สร้างจะแข่งขันกับแบนด์วิดท์ IO และ / หรือล็อคกับกิจกรรมอื่น ๆ ดังนั้นคุณควรลองทำสิ่งนี้หากคุณกำลังทำการทดสอบการประเมินระยะเวลา บนระบบอื่นแม้ว่าจะถูกกำหนดค่าเหมือนกัน
นอกจากนี้ยังมีข้อสังเกตว่าถ้าคุณสามารถแยกแกนหมุนสำหรับดัชนีจากแกนหมุนสำหรับตารางคุณจะสามารถทำงานจากดิสก์สองแผ่นในคราวเดียว (ยังคง จำกัด ความเร็วของตัวควบคุมดิสก์ที่อยู่ตรงกลางถ้า RAID หรือสิ่งที่ชอบ แต่ก็ยังเร็วกว่าดิสก์หนึ่งแผ่น)
ฉันรู้ว่าการสร้างดัชนีไม่ได้เป็นการดำเนินการแบบอ่าน - เขียนอย่างสมบูรณ์ แต่มันเพิ่มความเร็วได้อย่างมาก
ถ้ำ: ฉันเป็นคน MSSQL ด้วยตัวเองและฉันก็ไม่แน่ใจเกี่ยวกับ MySQL แต่ฉันต้องจินตนาการว่าแนวคิดของการแยกแกนหมุนไม่เฉพาะกับ SQLServer และ Oracle (ที่ฉันเคยได้ยินมาพูดถึงตรงนั้นด้วย IIRC ) ฉันไม่รู้จะทำยังไงเกี่ยวกับการสร้างแนวคิดนั้นขึ้นมา แต่ในแง่ SQLServer มันจะหมายถึงการมีแยก filegroup นอกเหนือPRIMARYและวางดัชนีในกลุ่มแฟ้มอื่น ๆ กับกลุ่มแฟ้มอื่น ๆ ที่ได้รับมอบหมายให้ชุดของแกนไม่ได้เกี่ยวข้องกับการPRIMARY(รับตำแหน่งแกน VS filegroups เป็นเรื่องอื่นทั้งหมด)
มันขึ้นอยู่กับ.
ตัวแปร # 1: ถ้า MySQL เลือกที่จะสร้างดัชนีทันทีหรือรอจนกว่าข้อมูลทั้งหมดอยู่ในนั้นให้ทำการเรียงลำดับ ฯลฯ เพื่อสร้างดัชนี หมายเหตุ: ดัชนี UNIQUE (ฉันคิดว่า) จะต้องถูกสร้างขึ้นทันทีเพื่อให้สามารถตรวจสอบ UNIQUEness ได้ คีย์หลักสำหรับ InnoDB จะถูกเก็บไว้กับข้อมูล (หรือคุณสามารถระบุไว้ในทางกลับกัน) เพื่อที่จะต้องสร้างแบบสุ่ม
ตัวแปร # 2: ดัชนีติดตามข้อมูล (เช่น AUTO_INCREMENT หรือการประทับเวลา) เทียบกับการสุ่ม (GUID, MD5) หรือที่อื่นระหว่าง (หมายเลขชิ้นส่วนชื่อ friend_id)
ตัวแปร # 3 (หากดัชนีถูกสร้างขึ้นทันที): ดัชนีอาจพอดีกับแคช (key_buffer หรือ innodb_buffer_pool) หรืออาจหกลงดิสก์
ดัชนีที่ติดตามข้อมูลนั้นมีประสิทธิภาพและเป็นเส้นตรงโดยไม่คำนึงถึงคำตอบที่ # 1
รหัสสุ่มเป็นความเจ็บปวด หากดัชนีไม่พอดีกับแคชเวลาในการสร้างจะยิ่งกว่าเชิงเส้นมากโดยไม่คำนึงถึงตัวแปรอื่น ๆ (ฉันไม่เห็นด้วยกับ Rolando ในกรณีนี้) ตาราง InnoDB ขนาดใหญ่ที่มี GUID สำหรับ PK นั้นช้าลงอย่างมากที่จะแทรก INSERT ลงในแผนประมาณ 100 แถว / วินาทีสำหรับดิสก์ธรรมดา อาจจะ 1,000 ถ้าคุณมี SSD โหลดข้อมูลและ INSERT แบบแบตช์คุณจะไม่ได้ผ่านพื้นที่เก็บข้อมูลแบบสุ่ม
3.53 ถึง 5.6 - มีการเปลี่ยนแปลงไม่มาก
แกนหมุนหลายอัน? การสตริป RAID จะดีกว่าในเกือบทุกสถานการณ์กว่าการกำหนดสิ่งนี้ด้วยตนเองที่นี่และที่นั่น การแบ่งด้วยตนเองนำไปสู่สถานการณ์ที่ไม่สมดุล - การสแกนตารางติดอยู่บนดิสก์ข้อมูล การดำเนินการเฉพาะดัชนีติดอยู่บนดิสก์ดัชนี แบบสอบถามแบบโดดๆอันดับแรกจะพบดิสก์ดัชนีจากนั้นดิสก์ข้อมูล (ไม่มีการทับซ้อนกัน); เป็นต้น