ปฏิวัติกระบวนการระบุดัชนีซ้ำซ้อนในฐานข้อมูล SQL Server

ดัชนี ซ้ำซ้อน
ดัชนีที่ไร้ประโยชน์และไม่จำเป็นเนื่องจากมีดัชนีหรือชุดของดัชนีอื่นอยู่

คุณเคยได้ยินคำกล่าวที่ว่า "ของดีมากเกินไปอาจได้ไม่ดี" ไหม? นั่นใช้กับดัชนี SQL Server เช่นกัน ฉันหมายความว่า แน่นอน คุณสามารถสร้างดัชนีที่ไม่ใช่คลัสเตอร์ได้มากเท่าที่คุณต้องการ แต่ทำไมคุณถึงสร้าง มันเหมือนกับการพยายามสร้างความประทับใจให้กับคนที่คุณชอบด้วยการใส่โคโลญจน์สิบชั้น — มันไม่ได้ผลและทำให้ทุกอย่างแย่ลงไปอีก

ปัญหาสองเท่า

อันตรายของดัชนีที่ซ้ำกันใน SQL Server

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

1. ดัชนีที่ซ้ำกันใช้พื้นที่จัดเก็บเพิ่มเติม และใครชอบที่จะเสียพื้นที่เก็บข้อมูลอันมีค่า? ไม่ใช่เรา! ด้วยการวิเคราะห์ Index Redundancy (คำแฟนซีสำหรับการวิเคราะห์สำหรับดัชนีที่ซ้ำซ้อน) เราสามารถระบุดัชนีที่ซ้ำซ้อนและประหยัดพื้นที่จัดเก็บได้เกือบ 10% นั่นเหมือนกับการค้นหาหีบสมบัติ 400GB ที่ซ่อนอยู่ในฐานข้อมูล 4TB ของคุณ!
2. ดัชนีที่ซ้ำซ้อนอาจทำให้คำสั่ง DML ช้าลง (การแทรก การอัปเดต การลบข้อมูล) ลองนึกภาพว่าต้องอัปเดตดัชนีเดียวกันหลายชุดทุกครั้งที่คุณทำการเปลี่ยนแปลง พูดคุยเกี่ยวกับการเสียเวลา! แต่อย่ากลัวไปเลย การลบดัชนีที่ซ้ำซ้อนสามารถปรับปรุงประสิทธิภาพและทำให้ฐานข้อมูลของคุณรู้สึกเหมือน Incredible Hulk นอกจากนี้ คุณจะประหยัดเงินในคอร์ CPU ที่คุณลดได้
3. การสร้างหรือจัดระเบียบดัชนีใหม่อาจสร้างความเจ็บปวดให้กับดัชนีที่ซ้ำกัน การกำจัดดัชนีที่ซ้ำซ้อนจะทำให้กระบวนการนี้เร็วขึ้นและกลับไปทำสิ่งที่สำคัญกว่าได้ (เช่น การดูรายการโปรดของคุณมากเกินไป)
4. การมีดัชนีหลายรายการในออบเจ็กต์เดียวกันอาจทำให้เครื่องมือเพิ่มประสิทธิภาพการสืบค้นทำงานได้ยากขึ้น และไม่มีใครต้องการเครื่องมือเพิ่มประสิทธิภาพบ้าๆ บอๆ! ด้วยการทำให้ดัชนีของคุณง่ายขึ้น คุณสามารถทำให้ชีวิตของเครื่องมือเพิ่มประสิทธิภาพง่ายขึ้นและปรับปรุงประสิทธิภาพการค้นหาได้

ภาวะที่กลืนไม่เข้าคายไม่ออกของดัชนีใน SQL Server

ดัชนีอาจถือว่าซ้ำซ้อนแม้ว่าจะไม่เหมือนกันก็ตาม ในดัชนี คอลัมน์จะแบ่งออกเป็นสองประเภท: คอลัมน์ดัชนี และคอลัมน์รวม

อย่าเล่น Jenga กับดัชนีของคุณ: ทำไมการสั่งซื้อจึงเป็นเรื่องสำคัญ!

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

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

การจำแนกประเภทของดัชนีซ้ำซ้อน

ดัชนีสำรองมีสามประเภท:

• ดัชนีที่ซ้ำกัน:ดัชนีสองรายการมีคอลัมน์หลักที่เหมือนกันทุกประการในลำดับเดียวกัน (เช่น ดัชนีที่เหมือนกัน) โดยมีคอลัมน์รวมที่เหมือนกัน เนื่องจากลำดับของคอลัมน์รวมไม่สำคัญ
  เช่น: ดัชนีทั้งสองมีคอลัมน์หลัก "ColumnA" และ "ColumnB" เหมือนกันในลำดับเดียวกัน และมีคอลัมน์ที่ไม่ใช่คีย์ "ColumnC" และ "ColumnD" เหมือนกัน ทำให้ดัชนีซ้ำกัน
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnC, ColumnD);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnD, ColumnC);


• ดัชนีที่ทับซ้อนกัน:ดัชนีหนึ่งมีคอลัมน์หลักที่สร้างชุดย่อยลำดับซ้ายของคอลัมน์หลักของดัชนีอื่น และมีชุดย่อยของคอลัมน์ที่ไม่ใช่คีย์ของคอลัมน์ที่ไม่ใช่คีย์ของดัชนีอื่นเป็นดัชนีที่ทับซ้อนกัน คอลัมน์หลักในดัชนีที่ทับซ้อนกันต้องเรียงลำดับจากซ้าย หมายความว่าคอลัมน์เหล่านี้เรียงตามลำดับความสำคัญที่ลดลง โดยคอลัมน์ที่สำคัญที่สุดจะปรากฏก่อน นี่เป็นเพราะ SQL Server สามารถใช้ดัชนีสำหรับการสแกนช่วงเฉพาะเมื่อระบุคอลัมน์ซ้ายสุด และจากนั้นเฉพาะเมื่อระบุคอลัมน์ซ้ายสุดถัดไป เป็นต้น
  เช่น: ในตัวอย่างนี้ ดัชนี “idx1” มีคอลัมน์หลัก “ColumnA” และ “ColumnB” ซึ่งเป็นชุดย่อยด้านซ้ายของคอลัมน์หลัก “ColumnA”, “ColumnB” ในดัชนี “idx2” ดังนั้น "idx2" จึงซ้อนทับ "idx1" และดัชนีทั้งสองนี้จึงเป็นดัชนีที่ทับซ้อนกัน
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB, ColumnD) INCLUDE (ColumnX, ColumnY, ColumnZ);


• ดัชนีที่คล้ายกัน:ดัชนีที่มีคอลัมน์หลักเหมือนกันในลำดับเดียวกัน แต่มีคอลัมน์รวมต่างกัน ในการแก้ปัญหาสำหรับดัชนีที่คล้ายกัน ควรอัปเดตหนึ่งดัชนีเพื่อให้มีคอลัมน์รวมของดัชนีที่ซ้ำซ้อนทั้งสอง
  เช่น: Solution Index: ในตัวอย่างนี้ ดัชนี “idx2” มีคอลัมน์หลัก “ColumnA” และ “ColumnB” ซึ่งเหมือนกับ “idx1” อย่างไรก็ตาม คอลัมน์รวมจะแตกต่างกัน และดัชนีผลลัพธ์ต้องมีคอลัมน์รวมที่แยกจากกันของคอลัมน์รวมดัชนีทั้งสอง
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnP, ColumnQ);

CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY, ColumnP, ColumnQ);


การค้นหาประสิทธิภาพใน SQL Server

เมื่อเราเจาะลึกเข้าไปในโลกลึกลับของฐานข้อมูล SQL Server เราพบปรากฏการณ์แปลก ๆ นั่นคือดัชนีที่ไม่ได้ใช้! ดัชนีเหล่านี้เป็นเหมือนวิญญาณของฐานข้อมูลในอดีต หลอกหลอนที่เก็บข้อมูลของเราและกินพลังการประมวลผลอันมีค่าของเราด้วยการอัพเดทดัชนีที่ไม่จำเป็น

เราสังเกตเห็นปัญหาร้ายแรงบางอย่างกับฐานข้อมูลขนาดใหญ่ของเรา — CPU และ Data IO ของเรามักจะพุ่งสูงขึ้น ซึ่งไม่ใช่สัญญาณที่ดีเลยสำหรับฐานข้อมูลที่ดี สาเหตุหลักคือข้อความค้นหาที่น่ารำคาญ แต่ในบางกรณี ข้อความค้นหาก็ดูไร้เดียงสาและดัชนีก็ดูดี หลังจากเจาะลึกลงไป เราพบว่าปัญหาที่แท้จริงคือดัชนีที่ไม่ได้ใช้หลายรายการในคอลัมน์หลัก ดัชนีที่ซ้ำซ้อนเหล่านี้ทำให้เกิดการอัปเดตจำนวนมากเกินไปและสร้างแผนการสืบค้นหลายรายการ ซึ่งส่งผลให้ประสิทธิภาพของฐานข้อมูลของเราเสียหาย

ดังนั้นเราจึงเริ่มภารกิจเพื่อลบดัชนีที่ซ้ำซ้อนเหล่านี้ทีละรายการ แต่อนิจจา กระบวนการลบดัชนีที่ซ้ำซ้อนกลายเป็นเรื่องงีบหลับจริงๆ ในฐานะผู้ดูแลระบบฐานข้อมูล การค้นหาดัชนีที่ซ้ำซ้อนก็เหมือนกับการเล่นเกม Where's Waldo ในชีวิตจริง คุณต้องกรองสคริปต์ SQL จำนวนมาก เรียกใช้สคริปต์ที่แสดงรายการดัชนีทั้งหมดและคอลัมน์ที่จัดทำดัชนีและรวมไว้ จากนั้นหวีผ่านแต่ละดัชนีเพื่อระบุดัชนีที่ซ้ำซ้อน การประชดไม่ได้หายไปสำหรับเรา - เรากำลังพยายามเพิ่มประสิทธิภาพฐานข้อมูลโดยทำสิ่งที่ไม่มีประสิทธิภาพอย่างไม่น่าเชื่อ และเมื่อคุณคิดว่าได้ระบุดัชนีที่ซ้ำซ้อนแล้ว คุณยังต้องลบออกทีละรายการ ซึ่งอาจทำให้คุณเดาทางเลือกอาชีพของคุณเป็นครั้งที่สองและฝันที่จะแลกแล็ปท็อปของคุณกับเก้าอี้ชายหาดและพินยาโคลาดา

และโอ้ เรากำลังอยู่ในการรักษา — กลายเป็นว่าปัญหาฐานข้อมูลของเราเพิ่งเริ่มต้น! เราพบว่าการกำจัดดัชนีที่ไร้ประโยชน์นั้นค่อนข้างต่ำในรายการลำดับความสำคัญสำหรับ DBA ที่รักของเรา มันเหมือนกับการพยายามให้พวกเขาเลิกคาเฟอีนที่พวกเขารัก — แทบเป็นไปไม่ได้เลย! แต่เรารู้ว่าเราต้องทำให้กระบวนการมีประสิทธิภาพมากขึ้นหากเราต้องการมีความหวังในการแก้ไขความเสียหายของฐานข้อมูลของเรา

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

snorql คืออะไร?

วิเคราะห์ฐานข้อมูลอย่างหัวหน้า!

พัฒนาที่ udaan snorql เป็นเฟรมเวิร์กแบบโอเพ่นซอร์สและใช้งานฟรีโดยสมบูรณ์ มุ่งเป้าไปที่การวินิจฉัย แก้ไข และปรับเมทริก SQL ให้เหมาะสม snorql สามารถเสียบปลั๊กได้และสามารถนำไปใช้กับฐานข้อมูลใด ๆ ได้อย่างง่ายดาย และพร้อมแล้วที่จะทำให้ชีวิตของคุณง่ายขึ้น เริ่มต้นด้วยคำแนะนำที่ทำตามได้ง่ายของเราเรื่อง “ การเริ่มต้นใช้งาน snorql ”

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

ที่เก็บ Snorql:
1. snorql (เฟรมเวิร์ก): https://github.com/udaan-com/snorql
2. snorql-ส่วนหน้า: https://github.com/udaan-com/snorql-frontend

ในกรณีที่คุณต้องการความน่าเชื่อถือเพิ่มเติม อย่าลืมอ่านบทความที่ยอดเยี่ยมsnorql — การวิเคราะห์ฐานข้อมูลอย่างเจ้านาย

การจัดทำดัชนี Follies

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

เพื่อจัดการกับดัชนีที่ซ้ำซ้อน เราได้คิดค้นอัลกอริทึมเพื่อจัดประเภทดัชนีของเรา ฟังดูง่ายพอใช่มั้ย? เพียงเปรียบเทียบและตัดกัน voila — ดัชนีที่ไม่ได้ใช้ ซ้ำ ทับซ้อน และคล้ายกันจะถูกจัดเรียงอย่างเรียบร้อย แต่จับม้าไว้ เพื่อนเอ๋ย นี่ไม่ใช่การเดินเล่นในสวน! ต้องใช้การทำซ้ำหลายครั้งเพื่อทำให้เมตริกของเราสมบูรณ์แบบ และเราได้รับข้อมูลเชิงลึกอันมีค่าตลอดการดำเนินการ

1. การเชิญฐานข้อมูล Read-Replica และ Geo-Replica เข้าร่วมปาร์ตี้:
   เราตระหนักว่าเพียงเพราะมีดัชนีอยู่ในฐานข้อมูลหลัก ไม่ได้หมายความว่าจะได้รับการปฏิบัติเช่นเดียวกันในอินสแตนซ์ Read-Replica และ Geo-Replica และเพื่อทำให้สิ่งต่าง ๆ ซับซ้อนยิ่งขึ้น ดัชนีที่ถูกใช้งานอย่างหนักในฐานข้อมูล Read-Replica หรือ Geo-Replica อาจถูกทำเครื่องหมายเป็นดัชนีที่ไม่ได้ใช้ในฐานข้อมูลหลัก ดังนั้น เพื่อให้ได้สถิติที่แม่นยำสำหรับอัลกอริทึมการจัดหมวดหมู่ดัชนีของเรา เราต้องรวบรวมและสรุปทั้งการใช้ดัชนีและการอัปเดตดัชนีจากทุกอินสแตนซ์
2. ตรวจสอบให้แน่ใจว่าดัชนีที่ไม่ซ้ำกันอยู่ในปาร์ตี้:
   ดังนั้น นี่คือข้อตกลง — ดัชนีที่ไม่ซ้ำและข้อจำกัดที่ไม่ซ้ำใครเป็นเหมือนพี่น้องที่บังคับความเป็นเอกลักษณ์ในลักษณะเดียวกัน เมื่อคุณสร้างข้อจำกัดที่ไม่ซ้ำใคร SQL Server จะเหมือนกับนักมายากลที่สร้างดัชนีที่ไม่ซ้ำใครจากอากาศที่เบาบาง และเนื่องจากเวทมนตร์นี้ คุณจึงไม่สามารถทิ้งดัชนีเฉพาะจากฐานข้อมูลได้โดยตรง ดังนั้น เพื่อหลีกเลี่ยงอุบัติเหตุ เราต้องแยกดัชนีเฉพาะออกจากอัลกอริทึมการจัดหมวดหมู่ของเรา
3. ทำอย่างไรไม่ให้ UX:
   ในเวอร์ชันแรกของ Index Redundancy Analysis เราได้ลองจัดกลุ่มดัชนีที่ซ้ำซ้อนในระดับดัชนี ซึ่งทำให้ยากที่จะเข้าใจความสัมพันธ์ระหว่างดัชนีหลักและดัชนีย่อยโดยไม่ต้องดูทั้งตาราง นอกจากนี้ อัลกอริทึมที่เราพัฒนาขึ้นนั้นซับซ้อนพอๆ กับเกมหมากรุก 3 มิติ และเราก็ตระหนักได้อย่างรวดเร็วว่านี่ไม่ใช่แนวทาง

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

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

ดังนั้นใครพร้อมที่จะทำให้มือของพวกเขาสกปรก? มาทำสิ่งนี้กันเถอะ!

เจาะลึกตัวชี้วัดความซ้ำซ้อนของดัชนี

ถึงเวลาที่จะมุ่งเน้นไปที่นักมายากลที่อยู่เบื้องหลังอัลกอริทึมนี้!

หมายเหตุ: ขณะนี้การวิเคราะห์ความซ้ำซ้อนของดัชนีพร้อมใช้งานสำหรับฐานข้อมูล SQL Server และการใช้งานนั้นเฉพาะกับระบบฐานข้อมูลนี้

Github Issue ✅ #79 New Metric — Index Redundancy Metric Github PR ⛓ #84 [New metric] Index Redundancy Metric

ฉันได้แบ่งอัลกอริทึมออกเป็นขั้นตอน:

1. รับข้อมูลโดยละเอียดของดัชนีทั้งหมดในฐานข้อมูลโดยใช้แบบสอบถาม sql ด้านล่าง

3. จัดกลุ่มดัชนีตามตาราง และวนซ้ำในแต่ละตาราง กรองดัชนีที่จะname == NULLกรองดัชนีฮีป และเรียงลำดับจากมากไปหาน้อยตามจำนวนคอลัมน์ที่จัดทำดัชนี
เรายังรักษารายการดัชนีที่จะข้ามไป ซึ่งรวมถึงดัชนีที่จำแนกไว้แล้วหรือดัชนีเฉพาะ

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

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

6. โพสต์สิ่งนี้ เราจะวนซ้ำในแต่ละดัชนี และวิเคราะห์เพื่อค้นหาดัชนีที่ซ้ำซ้อน

ก. จำแนกดัชนีที่ซ้ำกัน:
การจัดประเภทดัชนีที่ซ้ำกันนั้นตรงไปตรงมา คอลัมน์ที่จัดทำดัชนีและคอลัมน์รวมต้องเหมือนกันและคอลัมน์ดัชนีต้องอยู่ในลำดับเดียวกัน

ข. จัดประเภทดัชนีที่ทับซ้อนกัน:
คอลัมน์ดัชนีย่อยที่ทำดัชนีควรเป็นชุดย่อยด้านซ้ายของคอลัมน์จัดทำดัชนีหลักในลำดับเดียวกัน และคอลัมน์รวมควรเหมือนกัน

ค. จัดประเภทดัชนีที่คล้ายกัน:
คอลัมน์ที่ทำดัชนีควรเหมือนกัน ในขณะที่คอลัมน์รวมอาจแตกต่างกัน

อูดานได้อะไรจากสิ่งนี้?

ประหยัดมากขึ้น เครียดน้อยลง และ DBA มีความสุข!

ปรากฎว่าการวิเคราะห์ความซ้ำซ้อนของดัชนีไม่ได้เป็นเพียงการรักษาสำหรับ DBA แต่สำหรับทั้งองค์กร เรามีประโยชน์ดีๆ ที่อยากอวด:

1. ชะ-ชิง! เราประหยัดเงินได้โดยการลดขนาดฐานข้อมูลของเราโดยไม่ทำให้ประสิทธิภาพการทำงานสะดุด การประมวลผลฐานข้อมูลสูงสุดโดยเฉลี่ยลดลง 8% และพื้นที่จัดเก็บลดลง 10% ตัวอย่างเช่น เราลดขนาดฐานข้อมูล 32 vCore ให้เหลือเพียง 24 vCore และเราประหยัดค่าใช้จ่ายได้ 22%! ใครต้องการแกนเสริมทั้งหมดเหล่านี้ล่ะ?

3. DBA อยู่เหนือดวงจันทร์ เรายังเคยได้ยินข่าวลือว่าพวกเขาจูบจอภาพโดยเปิด Index Redundancy Metric ไว้บนหน้าจอ เฮ้ เราไม่ได้ตัดสิน ถ้านั่นเป็นสิ่งที่ทำให้พวกเขามีความสุข ก็ช่างมัน!