| ประเภทของ Indexes | ประเภทของ Indexes |
|---|---|
| Clustered Indexes | เงื่อนไขของ Clustered Indexes |
| Non-Clustered Indexes | เงื่อนไขของ Non-Clustered Indexes |
| คุณลักษณะและองค์ประกอบของ Indexes | คุณลักษณะและองค์ประกอบของ Indexes |
| Single Columns และ Multi-Columns Indexes | คุณสมบัติ Single Columns และ Multi-Columns Indexes |
| Page Splits และ Fragmentation | Page Splits และ Fragmentation |
| View กับ Indexes | เงื่อนไขการใช้ View กับ Indexes |
| หลักการพิจารณาเพื่อเลือกสร้าง Indexes | หลักการพิจารณาเพื่อเลือกสร้าง Indexes |
| หลักการพิจารณาเพื่อเลือกไม่สร้าง Indexes | หลักการพิจารณาเพื่อเลือกไม่สร้าง Indexes |
| หลักการพิจารณา column ที่สามารถสร้างให้เป็น Clustered Indexes ได้ | หลักการพิจารณา column ที่สามารถสร้างให้เป็น Clustered Indexes ได้ |
| หลักการพิจารณา column ที่สามารถสร้างให้เป็น Non-Clustered Indexes ได้ | หลักการพิจารณา column ที่สามารถสร้างให้เป็น Non-Clustered Indexes ได้ |
| CREATE INDEX | การสร้าง Index |
| DROP INDEX | การลบ Index |
subject:ประเภทของ Indexes
content:Indexes มี 2 ประเภท ได้แก่ > Clustered Indexes > Non-Clustered Indexes
subject:เงื่อนไขของ Clustered Indexes
content:> ในตารางหนึ่งๆจะมีได้เพียง 1 Clustered Indexes > ใช้โครงสร้างแบบ B-Tree > ขั้นตอนการสร้างเริ่มจากระบบจะทำสำเนาตารางข้อมูลจริงไปยังพื้นที่ชั่วคราว พร้อมทั้งเรียงลำดับจากน้อยไปหามากตาม column ที่กำหนดให้เป็น Indexes จากนั้นจึงประกอบกันให้เป็นโครงสร้างแบบ B-Tree จนเมื่อทุกอย่างเสร็จสิ้น จึงทำการลบตารางจริงทิ้งไป > ในแต่ละ Indexes Page ตั้งแต่ root เป็นต้นไป ประกอบด้วย Indexes Row ที่จะใช้เก็บค่าของ column ที่เป็น Indexes ข้อมูล ที่ใช้ในการ Pointer ไปยัง Indexes Page อื่นๆต่อไป แต่ถ้าเป็น Data Page ซึ่งอยู่ในระดับ Leaf จะเก็บข้อมูลจริง ( Rows of Data ) > ทำให้ไม่จำเป็นต้องใช้ order by เรียงลำดับ column ที่เป็น Indexes > ข้อเสียคือ ถ้าข้อมูลเยอะจะทำให้ใช้เวลาเชื่อมโยงนาน
subject:เงื่อนไขของ Non-Clustered Indexes
content:> ในตารางหนึ่งๆจะมีได้เพียง 249 Non-Clustered Indexes > ใช้โครงสร้างแบบ B-Tree > ในแต่ละ Indexes Page ตั้งแต่ root เป็นต้นไป ประกอบด้วย Indexes Row ซึ่งเก็บค่าของ column ที่เป็น Indexes ข้อมูล ที่ใช้ในการ Pointer ไปยัง Indexes Page อื่นๆต่อไป และในระดับ Leaf ก็จะยังเป็น Indexes Page อยู่ > โดยถ้าในตารางนั้นๆมี Clustered Indexes แล้ว ในระดับ Leaf ของ Non-Clustered Indexes จะชี้ไปยัง Data Page ( ระดับ Leaf ) ของ Clustered Indexes > โดยถ้าในตารางน้นๆไม่มี Clustered Indexes แล้ว ในระดับ Leaf ของ Non-Clustered Indexes จะชี้ไปยัง แถวข้อมูลของตารางจริง > ข้อเสียคือ ถ้าข้อมูลเยอะจะทำให้ใช้เวลาเชื่อมโยงนาน
subject:คุณลักษณะและองค์ประกอบของ Indexes
content:> Unique Indexes คือจะบังคับให้ค่าคอลัมน์ที่เป็น Indexes นี้สามารถจัดเก็บได้เฉพาะค่าที่ไม่ซ้ำกัน > NonUnique Indexes คือสามารถจัดเก็บค่าที่ซ้ำกันได้ ( โดยปกติแล้ว Clustered Indexes จะเป็นแบบ Unique Indexes โดยปริยาย )
subject:คุณสมบัติ Single Columns และ Multi-Columns Indexes
content:> การสร้าง Indexes มักจะใช้ column เดียว แต่ก็สามารถนำหลายๆ column มาทำเป็น Indexes ได้ เหมือน Primary Key โดยเรียกว่า Composite Indexes ( แต่ประกอบกันสูงสุดได้ไม่เกิน 16 column และไม่เกิน 900 Bytes ด้วย ) > โดยการสร้าง Indexes จาก หลายๆ column จะช่วยลดจำนวน Indexes Page ให้น้อยลง มีผลทำให้การทำงานมีประสิทธิภาพมากขึ้นด้วย ( โดยเฉพาะการ query ที่ระบุเงื่อนไขให้ทุก column ที่เป็น Indexes )
subject:Page Splits และ Fragmentation
content:> เมื่อมีการจัดเก็บข้อมูลแถวใหม่เข้าไป ทำให้ต้องมีการจัดลำดับ Indexes Page ใหม่ทุกครั้ง > โดยความยุ่งยากของการทำงานนี้ ได้แก่ เมื่อ Indexes Page ได้จัดเก็บข้อมูลไว้เต็มแล้ว ทำให้ต้องมีการแยก ออกมาเป็น Page ใหม่ ( หรือเรียกว่า Page Splits ) ซึ่งเป็นการต่อยอดระหว่าง Page เดิมกับ Page ใหม่เท่าๆกัน อีกทั้งการทำ Page Split นั้นอาจจะมีผลกระทบไปยัง Page อื่นๆอีกด้วย ซึ่งทำให้เกิด Page Splits ต่อๆไปตามลำดับ สำหรับวิธีการลดการเกิด Page Split ทำได้โดยการกำหนดค่า Fill Factor เพื่อใช้กันพื้นที่ส่วนหนึ่ง ไว้ให้กับค่า Indexes ที่ถูก Insert เข้าไป > เมื่อมีการลบข้อมูลแล้ว ถ้ามีการกำหนดค่า Fill Factor เพื่อกันที่ว่างไว้อยู่เป็นจำนวนมาก จะทำให้เกิดลักษณะที่เรียกว่า Fragmentation อันเป็นผลทำให้ประสิทธิภาพการค้นหาไม่ดีเท่าที่ควร เนื่องจากระบบต้องไล่หาข้อมูลในแต่ละ Page ที่มีข้อมูลอยู่น้อย โอกาสที่จะพบข้อมูลในระดับลึกๆ ต้องเสียเวลาจำนวนมาก > วิธีการของการปรับปรุงประสิทธิภาพที่ดีที่สุดหลังพบว่ามี Fragmentation ก็คือการลบ Indexes แล้วสร้างใหม่ แต่วิธีการนี้จะยังเพิ่ม Overhead ให้กับระบบมากขึ้น สำหรับตารางที่มีข้อมูลอยู่เป็นจำนวนมาก และหากว่ามีทั้ง Clustered Indexes และ Non-Clustered Indexes อยู่ด้วยกัน แล้วมีการลบ Clustered Indexes ทิ้ง จะทำให้ Non-Clustered Indexes ต้องจัดโครงสร้างใหม่ เพื่อแก้ไขข้อมูลในระดับ Leaf ให้ Pointer ไปที่แถวข้อมูลของตารางจริง และเมื่อทำการสร้าง Clustered Indexes ขึ้นมาอีกที จะทำให้ Leaf ของ Non-Clustered Indexes ต้องกลับไป Pointer ที่ Leaf ของ Clustered Indexes อีกครั้ง
subject:เงื่อนไขการใช้ View กับ Indexes
content:> View ต้องมีการระบุออพชั่น WITH SCHEMABINDING ไว้ด้วย > View ต้องมีคุณสมบัติ Deterministic > สามารถใช้กับข้อมูลประเภท float และเป็น non-key เท่านั้น > ควรสร้าง Clustered Indexes ต้องทำก่อนการสร้าง Non-Clustered Indexes > ต้องกำหนดออพชั่น ARITHABORT, CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, QUOTED_IDENTIFIER, ANSI_PADDING และ ANSI_WARNING ให้เป็น on > ต้องกำหนดออพชั่น NUMERIC_ROUNDABORT เป็น off
subject:หลักการพิจารณาเพื่อเลือกสร้าง Indexes
content:> column ที่มักถูกใช้ในการ JOIN ระหว่างตาราง > column ที่มักถูกเรียงด้วย ORDER BY > column ที่มักถูกจัดกลุ่มด้วย GROUP BY > column ที่มักถูกใช้กับ Aggreate Function > column ที่มักถูกเปรียบเทียบเงื่อนไขโดย WHERE > column ที่มักถูกใช้เป็น FOREIGN KEY
subject:หลักการพิจารณาเพื่อเลือกไม่สร้าง Indexes
content:> column ที่เป็นประเภท text, image และ bit > column ที่มีค่าซ้ำกันบ่อยๆ เช่น เพศ ที่มีเพียง 2 ค่า > column ที่มีขนาดของข้อมูลมากๆ เช่น char(100) > column ที่ไม่เคยถูกใช้ใน query เลย > table ที่มีแถวข้อมูลไม่มากนัก > table ที่มีการเพิ่ม ลบ แก้ไข ข้อมูลบ่อยๆ
subject:หลักการพิจารณา column ที่สามารถสร้างให้เป็น Clustered Indexes ได้
content:> column ที่มักใช้ในการ JOIN ระหว่าง Table > column ที่มีการระบุเงื่อนไขอย่างชัดเจน เช่น a = 100 > column ที่มีค่าอยู่ในช่วงเงื่อนไข เช่น a > 5 หรือ a BETWEEN 1 TO 10 > column ที่ควรมีขนาดไม่เกิน 25 bytes
subject:หลักการพิจารณา column ที่สามารถสร้างให้เป็น Non-Clustered Indexes ได้
content:> column ที่มักถูกใช้กับ Aggreate Function > column ที่เป็น Foreign Key > column ที่มักถูกเรียงด้วย ORDER BY > column ที่มักถูกจัดกลุ่มด้วย GROUP BY > column ที่ควรเป็น Clustered Indexes แต่ไม่ได้เป็นเพราะว่ามีตัวที่เหมาะสมกว่า
subject:CREATE INDEX
syntax:CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name ON { TABLE | VIEW } ( column_1 [ ASC | DESC ], column_2 [ ASC | DESC ], .... column_n [ ASC | DESC ] ) [ WITH <index_option> ] [ ON file_group ]
content:โดย <index_option> มีรูปแบบ ดังนี้ { PAD_INDEX | FILLFACTOR = fillfactor | IGNORE_DUP_KEY | DROP_EXISTING | STATISTICS_NORECOMPUTE | SORT_IN_TEMPDB }
example:CREATE TABLE person ( id IDENTITY NOT NULL, firstname VARCHAR(120) NOT NULL, lastname VARCHAR(120) NOT NULL, age INT NOT NULL ); CREATE INDEX index_age ON TABLE ( age ASC )
subject:DROP INDEX
syntax:DROP INDEX table_name.index_name
content:ใช้ในการลบ Index
example:CREATE TABLE person ( id IDENTITY NOT NULL, firstname VARCHAR(120) NOT NULL, lastname VARCHAR(120) NOT NULL, age INT NOT NULL ); CREATE INDEX index_age ON TABLE ( age ASC ); DROP INDEX person.index_age