อะไรคือ DOs และ DONT สำหรับการปรับปรุงประสิทธิภาพของฐานข้อมูลโดยใช้ดัชนี?
DO จะเป็นกรณีที่ควรสร้างดัชนีหรือดัชนีอื่นที่เกี่ยวข้องกับเคล็ดลับที่จะปรับปรุงประสิทธิภาพ
DONT จะเป็นกรณีที่ไม่ควรสร้างดัชนีหรือดัชนีที่เกี่ยวข้องกับการกระทำที่อาจส่งผลกระทบต่อประสิทธิภาพการทำงาน
คำตอบ:
ส่วนนี้ขึ้นอยู่กับว่าจะใช้ฐานข้อมูลใดเนื่องจากในดัชนีทั่วไปจะทำให้การแทรกและการอัพเดทช้าลงและเร็วขึ้น ในคลังข้อมูลโดยทั่วไปจะไม่มีการอัพเดทและการแทรกแบบแบทช์ทำให้ง่ายต่อการสร้างดัชนีและแบบสอบถามจำนวนมากและมากซึ่งทำให้มีดัชนีจำนวนมาก ในฐานข้อมูลออนไลน์สำหรับการขายทางเว็บและสิ่งที่คล้ายกันมีการแทรกและการอัปเดตมากมายดังนั้นการมีดัชนีที่เลือกอย่างระมัดระวังมากกว่าสองสามรายการจะทำให้ช้าลง
หากคุณได้รับแบบสอบถามจำนวนมากที่มีประเภทเฉพาะคุณสามารถสร้างดัชนีสำหรับแบบสอบถามได้แม้ว่าจะมีการประมวลผลแบบออนไลน์มากกว่าคลังข้อมูล หากคอลัมน์บางรายการมีคำถามจำนวนมากคุณอาจต้องการดัชนีในคอลัมน์นั้นและนี่เป็นประโยชน์อย่างยิ่งสำหรับคลังข้อมูลซึ่งได้รับการสอบถามด้วยวิธีที่แตกต่างกันและมักไม่แน่นอน
เมื่อใดก็ตามที่คุณเพิ่มหรือลบดัชนีให้ลองทำการทดสอบประสิทธิภาพเพื่อดูว่ามีผลอะไรบ้าง ถ้าปราศจากอย่างนั้นคุณก็จะตาบอด
มีหนังสือเกี่ยวกับการปรับแต่งคิวรีและฐานข้อมูลซึ่งมักจะเป็นระบบฐานข้อมูลเดียวและใช้เครื่องมือของ RDBMS นั้น หากคุณพบว่าตัวเองต้องการเพิ่มประสิทธิภาพฐานข้อมูลมากคุณกำลังเรียกใช้การดำเนินการขนาดใหญ่และอาจจ้าง DBA ด้วยความเชี่ยวชาญที่เหมาะสม
มันขึ้นอยู่กับว่าคุณใช้ตารางของคุณอย่างไร ไม่มีคำตอบเดียวและเรียบง่าย
คำแนะนำที่ดีที่สุดที่ฉันสามารถให้คุณคือ: ใช้ที่ปรึกษาการปรับแต่ง พวกเขาจะวิเคราะห์คำสั่งฐานข้อมูลในขณะที่คุณใช้งานแอปพลิเคชันจากนั้นพวกเขาจะทำการทดสอบโหลดเพื่อให้คำแนะนำที่มีความหมายแก่คุณ
พวกเขามีอยู่สำหรับSQL Serverและออราเคิล ฉันไม่รู้ว่า DBMS อื่นมีหรือไม่ฉันสงสัยว่าพวกเขาไม่มีเครื่องมือพื้นฐานเช่นนั้น
การแนะนำแบบสุ่มน้อย:
คำแนะนำสุดท้าย : หากการแสดงฐานข้อมูลมีความสำคัญต่อโครงการของคุณจริงๆให้จ้างผู้เชี่ยวชาญ มันคือสิ่งที่ฉันทำ
aและbเป็นไม่ได้(a, b)เช่นเดียวกับดัชนีใน อันหลังเกือบจะดีเท่ากับดัชนีบนaสำหรับการเร่งคิวรีที่มีเงื่อนไขaเป็นอย่างดีกว่ามากสำหรับคิวรีที่มีเงื่อนไขaและbและไม่เป็นประโยชน์สำหรับเคียวรีbเพียงอย่างเดียว (ฐานข้อมูลส่วนใหญ่จะไม่ใช้งาน Oracle จะทำเช่นนั้น แต่จะไม่ได้รับไมล์สะสมจากการใช้งานปกติ)
@ เปียโน 303 พูดแล้ว แต่ฉันจะพูดอีกครั้ง DOดัชนีการใช้งานในการรวมกันของคอลัมน์ ดัชนีแบบรวมบน(a, b)นั้นจะช้ากว่าการสืบค้นaแบบดัชนีaเพียงอย่างเดียวเล็กน้อยและจะดีกว่ามากหากแบบสอบถามของคุณรวมทั้งสองคอลัมน์ ฐานข้อมูลบางอย่างสามารถเข้าร่วมดัชนีในaและbก่อนที่จะกดปุ่มตาราง แต่ก็ไม่ดีเท่าที่มีดัชนีรวมกัน เมื่อคุณสร้างดัชนีแบบรวมคุณควรใส่คอลัมน์ที่มีแนวโน้มมากที่สุดที่จะค้นหาก่อนในดัชนีแบบรวม
ถ้าฐานข้อมูลของคุณสนับสนุนDOใส่ดัชนีในฟังก์ชั่นที่ปรากฏในคำสั่งมากกว่าคอลัมน์ (หากคุณกำลังเรียกใช้ฟังก์ชันบนคอลัมน์ดัชนีในคอลัมน์นั้นจะไร้ประโยชน์)
หากคุณกำลังใช้ฐานข้อมูลที่มีตารางชั่วคราวจริงที่คุณสามารถสร้างและทำลายในการบิน (เช่น PostgreSQL, MySQL, แต่ไม่ออราเคิล) แล้วไม่สร้างดัชนีในตารางชั่วคราว
หากคุณกำลังใช้ฐานข้อมูลที่ช่วยให้มัน (เช่นออราเคิล) ซึ่งเป็นDOล็อคในแผนของแบบสอบถามที่ดี การเพิ่มประสิทธิภาพข้อความค้นหาเมื่อเวลาผ่านไปจะเปลี่ยนแผนคิวรี พวกเขามักจะปรับปรุงแผน แต่บางครั้งพวกเขาก็ทำให้แย่ลงอย่างมาก โดยทั่วไปคุณจะไม่สังเกตเห็นการปรับปรุงแผนจริงๆ - แบบสอบถามไม่ใช่คอขวด แต่การวางแผนที่ไม่ดีเพียงครั้งเดียวอาจทำให้เว็บไซต์ยุ่ง
ไม่มีดัชนีในตารางที่คุณกำลังจะทำการโหลดข้อมูลขนาดใหญ่ มันเร็วกว่ามากในการดร็อปดัชนีโหลดข้อมูลจากนั้นสร้างดัชนีใหม่กว่าเพื่อรักษาไว้ในขณะที่คุณโหลดตาราง
ไม่ใช้ดัชนีกับข้อความค้นหาที่ต้องเข้าถึงมากกว่าเศษส่วนเล็ก ๆ ของตารางขนาดใหญ่ (ขนาดเล็กขึ้นอยู่กับฮาร์ดแวร์ 5% เป็นกฎง่ายๆ) ตัวอย่างเช่นถ้าคุณมีข้อมูลที่มีชื่อและเพศชื่อเป็นตัวเลือกที่ดีสำหรับการทำดัชนีเนื่องจากชื่อใดก็ตามที่แสดงถึงเศษเสี้ยวของแถวทั้งหมด มันจะไม่เป็นประโยชน์ในการจัดทำดัชนีเพศเนื่องจากคุณจะต้องเข้าถึง 50% ของแถว คุณต้องการใช้การสแกนแบบเต็มตารางแทน เหตุผลก็คือดัชนีปิดท้ายการเข้าถึงไฟล์ขนาดใหญ่แบบสุ่มทำให้คุณต้องค้นหาดิสก์ การค้นหาดิสก์ช้า ในกรณีที่ฉันเพิ่งจัดการเพื่อเร็วแบบสอบถามยาวชั่วโมงที่ดูเหมือน:
SELECT small_table.id, SUM(big_table.some_value)
FROM small_table
JOIN big_table
ON big_table.small_table_id = small_table.id
GROUP BY small_table.id
ต่ำกว่า 3 นาทีโดยเขียนใหม่ดังนี้:
SELECT small_table.id, big_table_summary.summed_value
FROM small_table
JOIN (
SELECT small_table_id, SUM(some_value) as summed_value
FROM big_table
GROUP BY small_table_id
) big_table_summary
ON big_table_summary.small_table_id = small_table.id
big_table.small_table_idซึ่งบังคับให้ฐานข้อมูลเพื่อให้เข้าใจว่ามันไม่ควรพยายามที่จะใช้ดัชนีที่ดึงดูดบน (ฐานข้อมูลที่ดีเช่น Oracle ควรเข้าใจด้วยตนเองแบบสอบถามนี้รันบน MySQL)
ปรับปรุง:นี่คือคำอธิบายของดิสก์แสวงหาจุดที่ฉันทำ ดัชนีให้การค้นหาอย่างรวดเร็วเพื่อบอกตำแหน่งของข้อมูลในตาราง นี่เป็นชัยชนะเพราะคุณจะดูเฉพาะข้อมูลที่คุณต้องการดู แต่ไม่เสมอไปโดยเฉพาะอย่างยิ่งหากคุณจะดูข้อมูลจำนวนมาก ดิสก์สตรีมข้อมูลได้ดี แต่ทำให้การค้นหาช้า การค้นหาข้อมูลแบบสุ่มบนดิสก์ใช้เวลา 1 / 200th ของวินาที ข้อความค้นหารุ่นที่ช้าทำสิ่งต่างๆเช่น 600,000 รายการและใช้เวลาเกือบหนึ่งชั่วโมง (มันทำการค้นหามากกว่านั้น แต่การแคชจับบางส่วน) ในทางตรงกันข้ามเวอร์ชันที่รวดเร็วรู้ว่ามันต้องอ่านทุกอย่างและสตรีมข้อมูลในระดับประมาณ 70 MB / วินาที มันผ่านตาราง 11 GB ภายในเวลาไม่ถึง 3 นาที
ทำ: จัดทำดัชนีฟิลด์น้อยที่สุดที่คุณเข้าถึงมากที่สุดผ่านการสืบค้นและ / หรือการเปรียบเทียบ
ไม่ได้: สร้างดัชนีทุกฟิลด์ในตารางโดยคิดว่ามันจะทำให้เร็วขึ้น
ฉันไม่มีสถิติเกี่ยวกับมัน แต่ฉันพยายามเก็บเขตข้อมูลที่มีการจัดทำดัชนีไม่เกิน 4 รายการในตารางหากฉันสามารถช่วยได้ การทำให้ฐานข้อมูลของฉันเป็นปกติจะช่วยให้ตัวเลขเหล่านี้ไม่ทำงานเนื่องจากทุกอย่างสามารถค้นหาได้โดยใช้คีย์ตัวเลข (ซึ่งเร็วกว่าอยู่ดี) ฉันพยายามหลีกเลี่ยงฟิลด์ข้อความแบบเต็มสำหรับการจัดทำดัชนี พวกมันค่อนข้างหนัก
โดยทั่วไปดัชนีจะเพิ่มความเร็วในการค้นหา แต่ทำให้การเขียนช้าลงและใช้พื้นที่มากขึ้น นั่นคือการปิดการซื้อขาย
เขตข้อมูลใด ๆ ที่ใช้บ่อยสำหรับการเข้าร่วมการค้นหา / การเปรียบเทียบหรือการสั่งซื้อโดยเป็นตัวเลือกสำหรับดัชนี หากต้องการทราบว่ามันเป็นประโยชน์อย่างแท้จริงวัด อย่างไรก็ตามคีย์ต่างประเทศของตารางที่เข้าร่วมจำนวนมากที่มีจำนวนมาก (> 1,000s) ของบันทึกและส่วนแทรกจำนวนน้อยจะได้รับผลตอบแทน
สำหรับฟิลด์ข้อความคุณสามารถจัดทำดัชนีในส่วนของฟิลด์ (ตัวอย่างเช่น 6 ตัวอักษรแรก) ซึ่งจะทำให้การสืบค้นของคุณเร็วขึ้น แต่ทำให้น้ำหนักของดัชนีเบาลง การค้นหาข้อความแบบเต็ม (ค้นหาบนlike %substring%) ต้องใช้เทคนิคที่แตกต่างกันซึ่งฉันไม่คุ้นเคยดังนั้นฉันจึงไม่สามารถให้คำแนะนำได้
สถานการณ์สำคัญที่ดัชนีไม่สามารถช่วยเหลือได้: คุณไม่สามารถใช้ดัชนีของวันที่หรือเขตข้อมูลที่สมบูรณ์เมื่อคุณค้นหา (/ เข้าร่วม / คำสั่งซื้อ) ในบางส่วนของวันที่ ดัชนีในจะไม่ช่วยให้คุณมีแบบสอบถามเหมือนdate_created select * from t where year(date_created) = 2011ใน mysql คุณไม่สามารถสร้างดัชนีในส่วนของวันที่ (เมื่อคุณใช้ ' between' มากกว่าที่year()จะสามารถใช้ดัชนีในฟิลด์วันที่)
ข้อมูลเพิ่มเติมเกี่ยวกับ MYSQL ในคู่มือ: http://dev.mysql.com/doc/refman/5.6/th/optimization-indexes.html
ทำ: พยายามรักษาขนาดรวมของดัชนีคลัสเตอร์ให้น้อยที่สุด รายการดัชนีคลัสเตอร์จะรวมอยู่ในดัชนีที่ไม่ได้ทำคลัสเตอร์อื่น ๆ และจากที่นี่มีโอกาสที่จะเสียพื้นที่ดิสก์
คิดว่าตารางเป็นพจนานุกรมซึ่งบทความจะเรียงตามลำดับของการปรากฏ (หรือไม่มีคำสั่งที่เป็นประโยชน์เลย) และดัชนีตารางเป็นดัชนีหนังสือไปยังพจนานุกรม
คุณใช้ดัชนีเพื่อค้นหาบางสิ่งบางอย่างในหนังสืออย่างรวดเร็ว แทนที่จะสแกนหนังสือทั้งเล่มคุณเพียงแค่ต้องค้นหากุญแจในดัชนี (โดยปกติดัชนีจะถูกจัดเรียงอย่างใด (ตามหมวดหมู่ตามสาขาวิทยาศาสตร์ตามยุคประวัติศาสตร์ ฯลฯ ) ซึ่งหมายความว่าคุณไม่ต้องสแกน ดัชนีทั้งหมด) จากนั้นข้ามไปยังหน้าขวา
ต่างจากหนังสืออย่างไรตารางจะไม่ถูกพิมพ์ครั้งเดียวแล้วไม่เปลี่ยนรูป มันได้รับการปรับปรุงตลอดเวลาและดังนั้นทุกดัชนีจะต้องได้รับการปรับปรุงด้วย ของหลักสูตรนี้มาในพื้นที่และเวลาค่าใช้จ่ายที่สามารถพิสูจน์ได้ด้วยประโยชน์ของดัชนี
ดังนั้นใช้ดัชนีสำหรับคอลัมน์หากคอลัมน์นั้นถูกใช้เป็นคีย์ในข้อความค้นหาที่ใช้บ่อยและห้ามใช้ถ้าไม่ใช้ คำที่ใช้บ่อยเป็นตัวบอกปริมาณที่ดีเท่าที่จะได้รับเมื่อพูดโดยทั่วไป ในที่สุดคุณจะต้องทำการประเมินที่ดีว่าคนใดเป็นประจำจากนั้นก็ทำการเปรียบเทียบประสิทธิภาพโดยมีหรือไม่มีดัชนีในกรณีที่มีข้อสงสัย