เคลียร์ Index ฐานข้อมูลส่วนเกินอย่างไรไม่ให้ประสิทธิภาพพัง
แนวทางการตรวจสอบและลบ Index ที่ไม่ได้ใช้อย่างปลอดภัยใน SQL Server พร้อมวิธีวิเคราะห์ข้อมูลการใช้งานและหลีกเลี่ยงข้อผิดพลาด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Index ส่วนเกินเพิ่มภาระให้การเขียนข้อมูลและการบำรุงรักษา
- sys.dm_db_index_usage_stats ช่วยตรวจสอบการใช้งานแต่ต้องระวังเรื่องรีสตาร์ท
- ควรเก็บข้อมูลสถิติข้ามรอบธุรกิจเช่นรอบเดือนหรือรอบปี
- Azure SQL รอมากกว่า 90 วันก่อนระบุว่า Index ไม่ได้ใช้งาน
ระบบฐานข้อมูลมักเผชิญปัญหา Index คงค้างจากอดีต เมื่อเกิดคำสั่งค้นหาที่ทำงานช้า วิศวกรจะสร้าง Index ขึ้นมาเพื่อแก้ปัญหาเฉพาะหน้าและปล่อยทิ้งไว้ แม้แอปพลิเคชันจะเปลี่ยนแปลงหรือเลิกใช้ฟีเจอร์นั้นไปแล้วก็ตาม ตารางที่มีการใช้งานสูงจึงสะสม Nonclustered Index จำนวนมากโดยไม่มีใครกล้าลบออก
เครื่องมือหลักในการตรวจสอบคือ sys.dm_db_index_usage_stats ซึ่งช่วยชี้เป้า Index ที่ไม่มีการเรียกใช้งานแต่มีการอัปเดตสอยต่อเนื่อง อย่างไรก็ตาม ตัวเลขเหล่านี้จะถูกรีเซ็ตเมื่อ SQL Server รีสตาร์ท ทำให้ DBA ต้องระมัดระวังในการตัดสินใจลบข้อมูลตามภาพถ่ายสถิติเพียงชั่วคราว
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การมี Index ที่ไม่ได้ใช้ไม่ได้แปลว่าไม่มีต้นทุน เพราะทุกครั้งที่มีการปรับปรุงข้อมูล เซิร์ฟเวอร์ต้องอัปเดตทั้งแถวและ Index ทุกตัวที่เกี่ยวข้อง ยิ่ง Index มีขนาดใหญ่หรือมีรายการ INCLUDE มาก ยิ่งทำให้กิจกรรมใน Log และงานบำรุงรักษาหนักขึ้น
แนวทางการตรวจสอบที่ปลอดภัยมีขั้นตอนสำคัญดังนี้:
- ตรวจสอบขนาด การใช้งาน และเมทาเดตาของ Index ร่วมกัน
- ใช้คำสั่ง SQL คัดกรองเฉพาะ Nonclustered Index มาตรฐาน
- บันทึกผลลัพธ์เก็บไว้ในระบบมอนิเตอร์เพื่อดูพฤติกรรมระยะยาว
- ครอบคลุมรอบการทำงานสำคัญ เช่น งานสิ้นเดือนหรือการทดสอบกู้คืนระบบ
ตัวอย่างคำสั่งสืบค้นเพื่อรวบรวมข้อมูล Index เบื้องต้น:
WITH index_size AS (SELECT object_id, index_id, SUM(used_page_count) * 8.0 / 1024 AS used_mb FROM sys.dm_db_partition_stats GROUP BY object_id, index_id) SELECT schema_name = s.name, table_name = t.name, index_name = i.name FROM sys.indexes AS i JOIN sys.tables AS t ON t.object_id = i.object_id WHERE i.type = 2;การบริหารจัดการ Index ในระบบฐานข้อมูลขนาดใหญ่เป็นงานที่ต้องอาศัยความละเอียดอ่อน เนื่องจากระบบการทำงานจริงมักมีรอบการประมวลผลที่ซ่อนอยู่ เช่น รายงานสิ้นปีหรือการตรวจสอบบัญชีประจำไตรมาส การตัดสินใจลบ Index เพียงเพราะสถิติไม่ขยับในช่วงสัปดาห์เดียวอาจทำให้ระบบเกิดอาการคอขวดเมื่อถึงรอบธุรกิจนั้นๆ การเก็บข้อมูลสถิติระยะยาวจึงเป็นหัวใจสำคัญที่สุด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อได้ข้อมูลครบถ้วนแล้ว ขั้นตอนถัดมาคือการมองหา Index ที่ซ้ำกันอย่างสมบูรณ์แบบ ซึ่งมีคอลัมน์และทิศทางการจัดเรียงเหมือนกันทุกประการ ส่วนกรณีที่ Index มีความทับซ้อนกันจะต้องอาศัยการวิเคราะห์เชิงลึกเพิ่มเติมก่อนตัดสินใจเปลี่ยนแปลง พร้อมทั้งเตรียมสคริปต์ย้อนกลับ (Rollback) ไว้เสมอหากประสิทธิภาพระบบเปลี่ยนไปในทางตรงกันข้าม
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น