เป็นการเพิ่มประสิทธิภาพก่อนกำหนดเพื่อเพิ่มดัชนีฐานข้อมูลหรือไม่

เพื่อนร่วมงานของฉันในวันนี้แนะนำว่าเราผ่านการค้นหาทั้งหมดในใบสมัครของเราและเพิ่มดัชนีตาม

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

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

การเพิ่มประสิทธิภาพก่อนวัยอันควรคือ "การเพิ่มประสิทธิภาพ" บางสิ่งบางอย่างเพราะความคลุมเครือความรู้สึกที่ใช้งานง่ายที่ y รู้นี้อาจจะช้าโดยเฉพาะอย่างยิ่งเพื่อความเสียหายของการอ่านรหัสและการบำรุงรักษา ไม่ได้หมายความว่าจงใจไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่มีชื่อเสียงเกี่ยวกับประสิทธิภาพ

บางครั้งที่เป็นเส้นเรื่องยากที่จะวาด แต่แน่นอนผมบอกว่าไม่มีการเพิ่มดัชนีใด ๆ ก่อนที่คุณจะไปอยู่คือการเพิ่มประสิทธิภาพเกินไปปลาย ; สิ่งนี้จะลงโทษผู้ใช้งานช่วงแรก - ผู้ใช้ที่กระตือรือร้นและสำคัญที่สุดของคุณ - และให้มุมมองเชิงลบต่อผลิตภัณฑ์ของคุณซึ่งพวกเขาจะแพร่กระจายไปทั่วในบทวิจารณ์การอภิปราย ฯลฯ การตรวจสอบข้อความค้นหาเพื่อค้นหาจุดปวด ความคิดที่ดี แต่ฉันต้องแน่ใจว่าจะทำไม่เกินเบต้า

ตรวจสอบการค้นหาที่ช้าเมื่อเราเริ่มใช้งาน

เพราะไม่มีอะไรพูดถึงคุณภาพเช่นทำให้ผู้ใช้ของคุณต้องทนทุกข์ทรมานจากการขาดการออกแบบ!

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

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

โดยเฉพาะอย่างยิ่งมันถูกต้องตามกฎหมายที่จะเพิ่มประสิทธิภาพตามการทดสอบประสิทธิภาพก่อนที่จะมีชีวิตอยู่เพื่อให้แน่ใจว่าคุณสามารถตอบสนองความต้องการ (แม้ว่าโดยประมาณ) เพื่อให้แอพของคุณไม่ดูด

อย่างน้อยที่สุดคุณควรโหลดฐานข้อมูลของคุณด้วยข้อมูลทดสอบที่เป็นไปได้และตรวจสอบการตอบสนองของแอพของคุณ นี่ไม่ใช่การคลอดก่อนกำหนดเนื่องจากคุณรู้ว่ามันกำลังจะเกิดขึ้นและจะมีการสืบค้นที่ทำให้เกิดการสแกนช้าอย่างไร้เหตุผล อย่างที่ AE พูดในความคิดเห็น:

ใช้ดัชนีเพื่อหลีกเลี่ยงการสแกนแบบเต็มตารางสำหรับแบบสอบถามใด ๆ ที่ผู้ใช้ทั่วไปจะทำตามเวลาจริง

อย่างน้อยสำหรับตารางที่วางแผนจะใช้งานเพิ่มขึ้น

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

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

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

คุณต้องจำสิ่งหนึ่งไว้ในใจเพราะคุณไม่สามารถวาดภาพนี้ด้วยแปรงที่กว้าง

ภาระงานทั่วไปของคุณคืออะไร

นั่นอาจฟังดูชัดเจนหรือน่าเบื่อ แต่ก็มีความสำคัญในทางปฏิบัติ ถ้าคุณมี10 คำสั่งที่ทำขึ้น 98% ของภาระงานของคุณ (บ่อยเชื่อหรือไม่) คำแนะนำของฉันจะเป็นการวิเคราะห์หนักก่อนการผลิต ด้วยข้อมูลที่เป็นจริงและเป็นตัวแทนตรวจสอบให้แน่ใจว่าคำค้นหา 10 ข้อนั้นดีเท่าที่จะเป็นไปได้ (ที่สมบูรณ์แบบเป็นการเสียเวลาอันมีค่าและแทบจะไม่สามารถทำได้)

สำหรับการค้นหา 200 รายการอื่น ๆ ที่คิดเป็น 2% ของปริมาณงานคำเหล่านั้นเป็นคำถามที่น่าจะไม่คุ้มค่ามากนักและจะคิดหาวิธีแก้ไขปัญหาแปลก ๆ ในการผลิต นั่นเป็นความจริงและไม่ใช่สิ่งเลวร้ายมาก แต่นั่นไม่ได้หมายความว่าละเลยวิธีปฏิบัติที่ดีที่สุดในการจัดทำดัชนีหรือตั้งสมมติฐานโดยประมาณเกี่ยวกับการดึงข้อมูล

เป็นเรื่องปกติและเป็นวิธีปฏิบัติที่ดีในการหาประสิทธิภาพของฐานข้อมูลก่อนการผลิต ในความเป็นจริงมีเป็นตำแหน่งที่ค่อนข้างทั่วไปสำหรับประเภทของสิ่งนี้เรียกว่าDBA พัฒนา

แต่...

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

เช่นเดียวกับสิ่งส่วนใหญ่มีความสมดุลที่ดีต่อสุขภาพ

ในฐานะที่เป็นโน้ตเล็ก ๆ น้อย ๆ ที่สนุก ... พหูพจน์ของ "ดัชนี"

"ดัชนี" สำหรับคนการเงิน

"ดัชนี" สำหรับเรา

ไม่มันไม่ใช่การปรับให้เหมาะสมก่อนเวลา แต่ต้องทำอย่างถูกต้องตามที่ควรจะเป็น

นี่คือสิ่งที่ฉันจะทำ:

1. โหลดฐานข้อมูลที่มีข้อมูลการทดสอบเพียงพอที่จะเลียนแบบปริมาณการผลิต คุณไม่สามารถได้รับความถูกต้อง 100% นี้ แต่ก็ไม่เป็นไรเพียงแค่ใส่ข้อมูลให้เพียงพอตารางหนึ่งมีข้อมูลจำนวนคงที่หรือไม่ โหลดมันขึ้นมา คุณมีตารางหนึ่งตารางที่มีข้อมูลจำนวนมากเช่นตารางใด ๆ ที่มีคำถามในไซต์นี้หรือไม่ โหลดหลายล้านบันทึกแม้ว่าข้อมูลจำลอง
2. เปิดการทำโปรไฟล์ในเซิร์ฟเวอร์ฐานข้อมูลของคุณ
3. ปังไปที่แอปพลิเคชันโดยใช้การรวมกันของสคริปต์อัตโนมัติ (ให้ปริมาณ) และผู้ใช้จริง (พวกเขารู้วิธีแบ่งสิ่งต่าง ๆ )
4. ตรวจสอบข้อมูลการทำโปรไฟล์ ข้อความค้นหาเฉพาะเจาะจงทำงานช้าหรือไม่ ตรวจสอบการอธิบายแผนและดูว่าเซิร์ฟเวอร์ฐานข้อมูลกำลังบอกคุณว่าต้องการดัชนีหรือไม่ แต่ไม่มีอยู่

เซิร์ฟเวอร์ฐานข้อมูลเป็นซอฟต์แวร์ที่ซับซ้อนและชาญฉลาด พวกเขาสามารถบอกวิธีเพิ่มประสิทธิภาพพวกเขาหากคุณรู้วิธีฟัง

คีย์มีการวัดประสิทธิภาพการทำงานก่อนและหลังการเพิ่มประสิทธิภาพและการและให้ฐานข้อมูลบอกคุณสิ่งที่มันต้องการ

การทำตามรูปแบบที่พิสูจน์แล้วสำหรับปัญหาที่ทราบ (เช่นการค้นหาระเบียนด้วย ID) ไม่ใช่สิ่งที่เกิดขึ้นก่อนเวลาอันควร มันสมเหตุสมผลดี

ที่กล่าวว่าดัชนีไม่ได้เป็นธุรกิจที่ตรงไปตรงมาเสมอ มักจะยากที่จะรู้ในระหว่างขั้นตอนการออกแบบซึ่งดัชนีการรับส่งข้อมูลของคุณจะขึ้นอยู่กับและสิ่งที่จะดำเนินการเขียนคอขวด ดังนั้นฉันจะเถียงเพื่อใช้ประโยชน์จากแนวทางปฏิบัติที่ดีที่สุดในการออกแบบ schema "ชัดเจน" (ใช้ PK's ที่เหมาะสมสำหรับรูปแบบการอ่าน / เขียนและดัชนี FK ที่ออกแบบ); แต่อย่าใส่ดัชนีกับสิ่งอื่นจนกว่าการทดสอบความเครียดของคุณจะต้องการมัน

เมื่อใบสมัครของคุณถูกปล่อยออกมามันก็สายเกินไป

แต่กระบวนการพัฒนาที่เหมาะสมควรรวมถึงการทดสอบประสิทธิภาพ

ใช้ผลลัพธ์ของการทดสอบประสิทธิภาพของคุณเพื่อตัดสินใจว่าจะเพิ่มดัชนีใดและตรวจสอบประสิทธิภาพโดยการทดสอบประสิทธิภาพซ้ำ

แม้ว่าฉันจะไม่คิดว่าทุกคำถามควรได้รับการปรับให้เหมาะสม แต่ดัชนีนั้นเป็นส่วนหนึ่งของ RDBMS ที่พวกเขาจำเป็นต้องได้รับการพิจารณาก่อนปล่อย เมื่อคุณเรียกใช้คิวรีไม่เหมือนกับการเขียนโปรแกรมรูปแบบอื่น ๆ คุณไม่ได้บอกให้ระบบเรียกใช้งาน พวกเขาพัฒนาแผนของตัวเองและมักจะยึดตามความพร้อมของดัชนี การแต่งหน้าและปริมาณข้อมูลจะได้รับการพิจารณาในเวลาต่อมา

นี่คือบางสิ่งที่ฉันจะพิจารณา:

1. มีข้อซักถามบางข้อที่คุณควรระบุในการพัฒนาแรก ๆ ที่คุณเพิ่งรู้ว่าจะถูกใช้บ่อย มุ่งเน้นไปที่พวกเขา
2. จะมีข้อความค้นหาช้า โดยการจัดทำดัชนีก่อนคุณสามารถกำหนดได้ว่าประสิทธิภาพยังไม่เร็วพอหรือไม่และพิจารณาการออกแบบใหม่ (การทำให้ปกติเป็นปกติก่อนกำหนด) ฉันควรทำสิ่งนี้ก่อนปล่อย ไม่มีใครต้องการระบบที่ใช้เวลา 10 นาทีในการค้นหาบางสิ่งบางอย่างในสินค้าคงคลัง
3. ดัชนีอาจปรับปรุงประสิทธิภาพการสืบค้น แต่จะไม่ขัดขวางการแก้ไขข้อมูล
4. ระบบจำนวนมากมีเครื่องมือในการวิเคราะห์ข้อความค้นหาของคุณดังนั้นอย่ากลัวที่จะใช้มัน

หลังจากการตรวจสอบเบื้องต้นของคุณคุณควรติดตามด้วยสิ่งที่ควรพิจารณาเมื่อคุณควรทบทวนสิ่งนี้อีกครั้งและวิธีที่คุณจะสามารถรวบรวมข้อมูลเพื่อทำสิ่งนี้ (การใช้งานการตรวจสอบรับสำเนาข้อมูลลูกค้า ฯลฯ )

ฉันรู้ว่าคุณไม่ต้องการเพิ่มประสิทธิภาพก่อนเวลาอันควร แต่เกือบจะแน่นอนว่าคุณจะมีประสิทธิภาพต่ำโดยไม่ต้องจัดทำดัชนีฐานข้อมูลของคุณ คุณสามารถกำหนดได้ว่ามีส่วนอื่นที่ทำให้เกิดปัญหาประสิทธิภาพหรือไม่

ขึ้นอยู่กับจำนวนผู้ใช้ที่คุณคาดหวัง คุณควรทำการทดสอบโหลดอย่างแน่นอนและตรวจสอบให้แน่ใจว่าฐานข้อมูลของคุณสามารถติดตามคำขอพร้อมกันได้ตั้งแต่ 10 ถึง 100 ถึง 1,000 อีกครั้งขึ้นอยู่กับปริมาณการใช้ข้อมูลที่คุณคาดหวังและพื้นที่ที่คุณคาดว่าจะใช้มากกว่าพื้นที่อื่น

โดยทั่วไปแล้วฉันจะปรับพื้นที่ที่ฉันคาดว่าผู้ใช้จะได้รับความนิยมสูงสุด จากนั้นฉันก็จะปรับแต่งทุกอย่างที่ช้าจากมุมมองประสบการณ์ผู้ใช้ เมื่อใดก็ตามที่ผู้ใช้ต้องรอบางสิ่งพวกเขาจะได้รับประสบการณ์ที่แย่และอาจถูกปฏิเสธ ไม่ดี!

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

บางคำถามที่คุณต้องถามคือ:

• ขีด จำกัด การออกแบบสำหรับขนาดของแต่ละตารางจะเป็นเท่าไหร่

หากตารางมีขนาดเล็ก (พูดน้อยกว่า 100 แถว) จะไม่ใช่ความเสียหายหากฐานข้อมูลต้องสแกนทั้งตาราง อาจเป็นประโยชน์ในการเพิ่มดัชนี แต่ต้องใช้ความเชี่ยวชาญหรือการวัดเพิ่มเติมเล็กน้อยเพื่อพิจารณา

• แบบสอบถามแต่ละรายการจะถูกเรียกใช้บ่อยเพียงใดและเวลาตอบสนองที่ต้องการคือเท่าใด

หากแบบสอบถามรันไม่บ่อยและไม่มีข้อกำหนดเวลาตอบสนองที่เข้มงวด (เช่นการสร้างรายงาน) และจำนวนแถวไม่มากก็น่าจะค่อนข้างปลอดภัยที่จะเลื่อนการเพิ่มดัชนี อีกครั้งความเชี่ยวชาญหรือการวัดสามารถช่วยบอกได้ว่ามันจะเป็นประโยชน์หรือไม่

• แบบสอบถามต้องการค้นหาตารางด้วยบางสิ่งนอกเหนือจากคีย์หลักหรือไม่ เช่นกรองตามช่วงวันที่เข้าร่วมในต่างประเทศหรือไม่

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