บทความนี้ต่อจากบทความ “เตรียมพร้อมก่อนอ่าน Execution Plan” หากผู้อ่านเปิดมาเจอบทความแล้วยังไม่ได้อ่านบทความแรกผู้เขียนแนะนำให้อ่านก่อน เพราะจะได้ทราบถึงขั้นตอนการประมวลผลคิวรี่ว่ามีกลไกเช่นไร สำหรับบทความนี้ผู้เขียนจะใช้ 2 เครื่องมือเป็นหลักคือ Microsoft SQL Server Management Studio (SSMS) และ Sentryone Plan Explorer หากผู้อ่านต้องการทำตามตัวอย่างในบทความ ก็สามารถหาดาวน์โหลดได้จาก https://www.sentryone.com/plan-explorer

การอ่าน Query Execution Plan ตอนที่ 1

สำหรับบทความนี้ผู้เขียนจะใช้ 2 เครื่องมือเป็นหลักคือ

Microsoft SQL Server Management Studio (SSMS) และ
Sentryone Plan Explorer

หากผู้อ่านต้องการทำตามตัวอย่างในบทความ ก็สามารถหาดาวน์โหลดได้จาก https://www.sentryone.com/plan-explorer

ประเภทการแสดงผล Query Execution Plan

การแสดงผล Query Execution Plan นั้นเป็นการแสดงผล Plan ที่ถูกเลือกจากขั้นตอน Query Optimization เสร็จไปแล้ว
ขอเรียกว่า Compiled Query Execution Plan หรือ Compiled Plan (รายละเอียดอยู่บทความ “เตรียมพร้อมก่อนอ่าน Execution Plan” สนุกมาก) ซึ่งการแสดงผลแบ่งออกได้ 2 ประเภทดังนี้

Estimated Execution Plan คือการแสดงผล Query Execution Plan ที่ถูก Compiled แล้วแต่ยังไม่ถูก Execute
Actual Execution Plan คือการแสดงผลทั้งข้อมูลที่เป็นค่าประเมิน (Estimated) และข้อมูลที่ได้จากการ Execute จริง (Actual)

ผู้อ่านที่ยังไม่ได้อ่านบทความ “เตรียมพร้อมก่อนอ่าน Execution Plan” ควรกับไปอ่านบทความก่อนเพื่อทำความเข้าใจกลไก Query Optimization และ Cardinality Estimation

การแสดงผล Estimated Execution Plan

สามารถแสดงผล Estimated Execution Plan ได้ 2 แบบคือ

แสดงผลเป็นเอกสาร XML ผ่านคำสั่ง SET SHOWPLAN_XML โดยมี Syntax ดังนี้

SET SHOWPLAN_XML { ON | OFF }

เมื่อเราป้อนคำสั่ง T-SQL ต่อจากการกำหนด SET SHOWPLAN_XML ให้มีค่าเป็น ON แล้วทำการ Execute
จะพบว่า Microsoft SQL Server จะแสดง Compiled Plan ออกมาในรูปแบบเอกสาร XML โดยไม่ประมวลผล Compiled Plan ดังกล่าว

ทดสอบด้วยสคริปต์ต่อไปนี้กับฐานข้อมูล Adventureworks ผ่าน SQL Server Management Studio (SSMS)

SET SHOWPLAN_XML ON
GO

SELECT
       E.BusinessEntityID
,      P.Title
,      P.FirstName
,      P.MiddleName
,      P.LastName
,      P.Suffix
,      E.JobTitle
,      D.Name AS Department
,      D.GroupName
,      EH.StartDate
FROM HumanResources.Employee as E
INNER JOIN Person.Person as P
ON P.BusinessEntityID = E.BusinessEntityID
INNER JOIN HumanResources.EmployeeDepartmentHistory as EH
ON E.BusinessEntityID = EH.BusinessEntityID
INNER JOIN HumanResources.Department as D
ON EH.DepartmentID = D.DepartmentID
WHERE EH.EndDate IS NULL;

GO

SET SHOWPLAN_XML OFF

จะสังเกตเห็นว่าผู้เขียนต้องใช้ประโยค GO เพื่อให้คำสั่ง SET SHOWPLAN_XML อยู่คนละ Scope (Batch) กับคำสั่งอื่น ๆ เพราะเป็นข้อจำกัดของคำสั่งนี้

ผลลัพธ์ที่ได้พบว่าคิวรี่ไม่ถูก Execute แต่จะปรากฏเอกสาร XML ในแท็ป Results ดังแสดง

แนะนำว่าเมื่อ SET SHOWPLAN_XML ให้มีค่าเป็น ON แล้ว ควร SET SHOWPLAN_XML ให้มีค่าเป็น OFF ทันทีหลังใช้งานเสร็จ

ข้อดีของการแสดงผลเป็นเอกสาร XML คือ แม้เราใช้ Client Tool อื่นๆ ที่ไม่ใช่ SSMS ก็สามารถเก็บ Plan ไปเปิดด้วย SSMS ในภายหลังได้

.แสดงผลเป็น Graphic ทันที ผ่าน SQL Server Management Studio (SSMS)

โดยพิมพ์ Query ที่ต้องการแสดง Compiled Plan เข้าไปจากนั้นกด Ctrl-L หรือ
กดไปที่ปุ่ม Display Estimated Execution Plan จะได้ผลลัพธ์เป็น Complied Plan ออกมาในแท็ป Execution Plan ดังแสดง

การแสดงผล Actual Execution Plan

สามารถแสดงผล Actual Execution Plan ได้ 2 แบบคือ

แสดงผลเป็นเอกสาร XML ผ่านคำสั่ง SET STATISTICS XML โดยมี Syntax ดังนี้

SET STATISTICS XML { ON | OFF }

เมื่อเราป้อนคำสั่ง T-SQL ต่อจากการกำหนด SET STATISTICS XML ให้มีค่าเป็น ON แล้วทำการ Execute
จะพบว่า Microsoft SQL Server ทำการประมวล Compiled Plan จนได้ Resultset ออกมา
หลังจากนั้นจึงแสดงผล Complied Plan พร้อมข้อมูลที่เกิดตอนประมวลผลจริงในรูปแบบเอกสาร XML

ทดสอบด้วยสคริปต์ต่อไปนี้กับฐานข้อมูล Adventureworks ผ่าน SQL Server Management Studio (SSMS)

SET STATISTICS XML ON
GO

SELECT
       E.BusinessEntityID
,      P.Title
,      P.FirstName
,      P.MiddleName
,      P.LastName
,      P.Suffix
,      E.JobTitle
,      D.Name AS Department
,      D.GroupName
,      EH.StartDate
FROM HumanResources.Employee as E
INNER JOIN Person.Person as P
ON P.BusinessEntityID = E.BusinessEntityID
INNER JOIN HumanResources.EmployeeDepartmentHistory as EH
ON E.BusinessEntityID = EH.BusinessEntityID
INNER JOIN HumanResources.Department as D
ON EH.DepartmentID = D.DepartmentID
WHERE EH.EndDate IS NULL;

GO

SET STATISTICS XML OFF

จะสังเกตเห็นว่าผู้เขียนต้องใช้ประโยค GO เพื่อให้คำสั่ง SET STATISTICS XML อยู่คนละ Scope (Batch) กับคำสั่งอื่น ๆ เพราะเป็นข้อจำกัดของคำสั่งนี้

ผลลัพธ์ที่ได้พบว่าคิวรี่จะถูก Execute และปรากฏเอกสาร XML ในแท็ป Results มาด้วย หลังจาก Execute จนได้ Resultset ดังแสดง

แสดงผลเป็นเอกสาร XML ผ่านคำสั่ง SET STATISTICS XML

แสดงผลเป็น Graphic หลังจาก Execute คำสั่งผ่าน SQL Server Management Studio (SSMS)

โดยจะต้องทำการ Enable โดยกด Ctrl-M หรือกดปุ่ม Include Actual Execution Plan ก่อนจะ Execute ดังแสดง

แสดงผลเป็น Graphic หลังจาก Execute คำสั่งผ่าน SQL Server Management Studio (SSMS) โดยจะต้องทำการ Enable โดยกด Ctrl-M หรือกดปุ่ม Include Actual Execution Plan ก่อนจะ Execute ดังแสดง

พบว่าหลังจาก Execute จนได้ Resultset เรียบร้อยแล้วจะปรากฎแท็ป Execution Plan ตามมา

เปรียบเทียบข้อมูลของการแสดงผล Query Execution Plan แต่ละแบบ

เมื่อนำเม้าส์ไปลอยอยู่เหนือตัวดำเนินการที่วงเอาไว้ จะปรากฎข้อมูลของตัวดำเนินการนั้นดังแสดง

จะมีความแตกต่างกันของข้อมูลอยู่บ้าง

ในส่วนของ Estimated Execution Plan นั้นแสดง Compiled Plan ที่ยังไม่ได้ Execute
ค่าต่างๆ ที่ได้มาเกิดจากการคำนวนของคอมโพเนนต์ในกลุ่ม Query Optimization ชื่อ Cardinality Estimator
โดยใช้ข้อมูลหลักจาก Statistics (ในรูปแบบของ Histogram) ที่สัมพันธ์กับแต่ละ Predicate (ในที่นี้คือเงื่อนไขหลังประโยค WHERE) เพื่อประเมินจำนวนแถวข้อมูล (Estimated Number of Rows)
จากนั้นจึงนำไปประเมิน Cost ต่างๆ ต่อไป (Compiled Plan ที่แสดงใน Estimated Execution Plan ถูกเลือกมาแล้ว จาก หลายๆ Plan แข่งขันกันด้วยค่า Cost นี่เอง)

แต่ในส่วนของ Actual Execution Plan นั้นเป็นการนำ Compiled Plan ไปประมวลผล
ผู้อ่านจะพบจำนวนแถวข้อมูลที่ได้จากการประมวลผลจริง (Actual Number of Rows) เพิ่มจากค่าประเมิน
หากจำนวนแถวข้อมูลจากการประมวลผล ต่างจากจำนวนแถวข้อมูลที่ได้จากการประเมินมาก เป็นเพราะ Statistics (Histogram) เริ่มไม่สะท้อนค่าปัจจุบัน
อาจจำเป็นต้องปรับปรุง Statistics แบบ Manual (ปกติแล้ว Statistics ถูกตั้งค่าให้ปรับปรุงอัตโนมัติ)

Estimated Execution Plan และ Actual Execution Plan

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

Property ของ Estimated Execution Plan และ Actual Execution Plan

พบว่าการเรียก Properties ขึ้นมาแสดงสามารถให้รายละเอียดที่เพิ่มขึ้น
โดยเฉพาะในส่วนของ Actual Execution Plan จะแสดง I/O Statistics และ Time Statistics ที่ใช้ในการประมวลผล
อีกทั้งเห็นการแตกเป็น Threads ย่อยในการใช้ I/O หรือ CPU อีกด้วย

นอกเหนือจะสามารถแสดงค่าข้อมูลของแต่ละตัวดำเนินการภายใน Compiled Plan แล้ว
เส้นเชื่อม (Edge) ระหว่างตัวดำเนินการยังแสดงถึงข้อมูลที่ไหลจากตัวดำเนินการหนึ่งไปยังอีกตัวดำเนินการหนึ่ง ดังแสดง

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

นอกจาก Microsoft SQL Server Management Studio แล้ว
อีกหนึ่งเครื่องมือจาก Microsoft ชื่อ Azure Data Studio ก็สามารถแสดง Compiled Plan ออกมาได้เช่นกัน
โดยกดไปที่ปุ่ม Explain ข้อมูลของ Estimated Execution Plan จะปรากฎออกมาดังแสดง

ปุ่ม Explain ข้อมูลของ Estimated Execution Plan

แต่เครื่องมือที่ผู้เขียนชอบมากเป็นพิเศษคือ Plan Explorer จาก SentryOne
ผู้อ่านสามารถหาดาวน์โหลดได้จาก https://www.sentryone.com/plan-explorer เป็นซอฟต์แวร์ฟรี มี Plugin สำหรับ SSMS หรือจะใช้อิสระก็สามารถใช้งานได้

แนะนำ SentryOne Plan Explorer

หลังจากดาวน์โหลด Plan Explorer มาติดตั้งเรียบร้อยแล้ว เมื่อเปิดเข้าไปจะพบกับ Start Page หน้าตาแบบนี้

จะมี Video สอนการใช้งาน และลิ้งก์ไปยังเอกสาร และบรรดา Blogs ที่นำ Plan Explorer ไปเขียนบทความ
ผู้อ่านสามารถทำความเข้าใจ โดยการทำตามตัวอย่างใน Blogs ต่างๆ ได้
(ทำตามนั้นไม่ยาก แต่การแปลความหมายนั้น ผู้อ่านจำเป็นต้องเข้าใจว่าแต่ละตัวดำเนินการนั้นกระทำบนโครงสร้างข้อมูลแบบใดอยู่ อันนี้อาจต้องเข้มข้นนิดหน่อย)

ทดสอบการใช้งาน

ก่อนเริ่มทดสอบการใช้งานผู้เขียนแนะนำให้ลบ Non-Clustered Index บนตาราง Sales.SalesOrderHeader ที่มีคอลัมน์ OrderDate เป็นองค์ประกอบออกก่อน ด้วยสคริปต์ต่อไปนี้

DECLARE
       @indexName sysname
,      @myStatement nvarchar(max)

DECLARE i_cursor CURSOR FOR
       SELECT
              I.name
       FROM sys.indexes AS I INNER JOIN sys.index_columns AS C
       ON I.object_id = C.object_id AND I.index_id = C.index_id
       WHERE I.object_id=OBJECT_ID('Sales.SalesOrderHeader')
              AND COL_NAME(C.object_id,C.column_id)='OrderDate'

OPEN i_cursor
FETCH NEXT FROM index_cursor INTO @indexName

WHILE @@FETCH_STATUS = 0
BEGIN
    SET @myStatement = N'DROP INDEX ' + QUOTENAME(@indexname)
                     + 'ON Sales.SalesOrderHeader'
    EXEC sp_executesql @myStatement

    FETCH NEXT FROM index_cursor INTO @indexname
END

CLOSE i_cursor
DEALLOCATE i_cursor

เริ่มสร้าง Session ขึ้นมาใช้งาน โดยกด New Session ใน Start Page หรือ Menu Bar ก็ได้ เลือกแท็บ Command Text แล้วนำคำสั่งต่อไปนี้ ใสลงไปเพื่อทดสอบ

SELECT
       O.SalesOrderID
,      O.OrderDate
,      O.Status
FROM Sales.SalesOrderHeader as O
WHERE OrderDate>='Jan 1,2012' AND OrderDate<'Jan 16,2012';

ผู้เขียนตั้งใช้ให้มี Predicate หลังประโยค WHERE โดยเป็นการสืบค้นบนคอลัมน์ OrderDate

จากนั้นกดไปที่ปุ่ม Get Estimated Plan เพื่อแสดง Estimated Execution Plan

หาก Session ยังไม่ได้เชื่อมต่อไปยังฐานข้อมูลจะปรากฎไดอะล็อก Connect ขึ้นมาให้สร้างการเชื่อมต่อในทำการเชื่อมต่อจนสำเร็จ (ต้องใช้ Login ที่มีสิทธิ์ SHOWPLAN บนฐานข้อมูลเป้าหมาย)

ปุ่ม Get Estimated Plan แสดง Estimated Execution Plan

จะได้ผลลัพธ์ออกมาเป็น Compiled Plan ในรูปแบบ Graphic
(หากไม่แสดงผลเป็น Plan ในรูปแบบ Graphic ให้เลือกไปที่แท็บ Plan Diagram)

จากรูปจะเห็นว่าตัวดำเนินการมีเพียงตัวเดียวคือ Clustered Index Scan และ Compiled Plan นี้ขาด Index ที่ช่วยเพิ่มประสิทธิภาพ

Clustered Index คือโครงสร้างตารางที่มีความเป็น Index รวมอยู่ในตารางเลย
คือข้อมูลแต่ละแถวจะจัดเรียงตามคอลัมน์ที่ถูกเลือกเป็น Clustered Key
ดังนั้นหากตัวดำเนินการเป็น Clustered Index Scan ก็ไม่ได้ต่างอะไรกับ Table Scan เลย
สำหรับตารางนี้ Clustered Key คือคอลัมน์ SalesOrderID
แต่ในประโยค WHERE เป็น Predicate ที่กระทำบนคอลัมน์ OrderDate
ดังนั้น Query Optimizer จึงเลือกที่จะ Scan เอา

และเมื่อนำเมาส์ไปลอยเหนือตัวดำเนินการ SELECT
(สังเกตว่ามีเครื่องหมาย Warning ปรากฎอยู่) จะแสดงข้อมูลดังนี้

พบการแจ้งเตือนว่า Cardinality Estimator ประเมินจำนวนแถวข้อมูลเอาไว้ 181 แถว
(ที่จริงแล้วคำนวนได้ 180.575 แถว หากดูใน SSMS แต่ SentryOne Plan Explorer มีการปัดขึ้น)
แต่เนื่องจากไม่มี Index ช่วยในการสืบค้นจึงจำเป็นต้อง Scan แถวข้อมูลทั้งสิ้น 31,465 แถวข้อมูล

จากนั้นเลือกไปที่แท็บ Top Operators เนื่องจาก Compiled Plan นี้มีเพียงตัวดำเนินการเดียว จึงมีรายการของตัวดำเนินการเพียงบรรทัดเดียว

โดยไฮไลท์สีเหลืองเอาไว้แสดงถึงการแจ้งเตือนเช่นกัน และยังคงเป็นเหตุผลเดิมคือเกิดการ Scan แถวข้อมูลมากเกิน
(31,465 เกินจากเกณฑ์ที่ตั้งไว้คือ 100 แถวข้อมูล เป็นข้อดีที่ทำให้เราทราบว่าเริ่มส่งผลกระทบต่อประสิทธิภาพ)
อีกทั้งยังแสดงข้อมูลการประเมินอื่นๆ ตามมาอีกด้วย แท็บนี้จะมีประโยชน์มากหากมีหลายตัวดำเนินการ
เพราะสามารถเรียงตามค่าที่เราต้องการจากมากไปหาน้อย
เช่น Estimated Subtree Cost, Estimated CPU Cost หรือ Estimated I/O Cost เป็นต้น

แท็บถัดมาเป็นแท็บ Plan Tree จะให้ข้อมูลคล้ายคลึงกับแท็บก่อนหน้า แต่จะแสดงในรูปแบบของลำดับชั้นของตัวดำเนินการ \\
1. แท็บถัดมาเป็นแท็บ Parameters เพื่อแสดงพารามิเตอร์ที่ใช้ในคำสั่งในที่นี้คือค่าที่ใช้เปรียบเทียบใน Predicate หลังประโยค WHERE ดังแสดง
  เนื่องจากเป็นการเรียกดู Estimated Execution Plan เลยมีเพียงค่าในคอลัมน์ Compiled Value
  แต่หากเป็นการเรียกดู Actual Execution Plan จะมีค่าที่ใช้ประมวลจริงปรากฎในคอลัมน์ Runtime Value ด้วย
  แท็บสุดท้ายที่จะแนะนำคือแท็บ Index Analysis ผู้เขียนขอใช้แท็บนี้ยกเป็นกรณีศึกษาในหัวข้อถัดไป
  1. แท็บถัดมาเป็นแท็บ Query Columns จะให้ข้อมูลคอลัมน์ที่จะปรากฎ (หรือคอลัมน์ที่อยู่หลังประโยค SELECT นั่นเอง)
  หากคอลัมน์ไหนถูกกรองโดย Predicate หลังประโยค WHERE ด้วยก็จะเห็นรายละเอียดการกรองอยู่ในคอลัมน์ Filters ดังแสดง
  1. แท็บสุดท้ายที่จะแนะนำคือแท็บ Index Analysis ผู้เขียนขอใช้แท็บนี้ยกเป็นกรณีศึกษาในหัวข้อถัดไป
    กรณีศึกษา: การสร้าง Index เพื่อเพิ่มประสิทธิภาพ Query ด้วย Plan Explorer
    ข้อมูลจากตัวดำเนินการ SELECT พบว่า Estimated Subtree Cost ทั้งสิ้นเท่ากับ 0.54456
    เราสามารถลด Cost ลงด้วยการปรับแต่ง Index รายละเอียดของแท็บ Index Analysis ที่พูดค้างเอาไว้ก่อนหน้ามีดังนี้

แท็บ Index Analysis จะให้รายละเอียด 3 เรื่องที่สำคัญคือ

Indexes ที่เกี่ยวข้องและมีโอกาสถูกนำมาใช้ภายใน Plan
รายละเอียดของ Statistics
- ข้อมูลในรูปแบบของฮีสโตแกรม
- วันที่ปรับปรุง Statistics ล่าสุดเพื่อดูความเป็นปัจจุบัน
พารามิเตอร์ที่เป็นตัวบอกว่า Cardinality Estimator จะหยิบฮีสโตแกรมแท่งไหนบ้างไปใช้ในการคำนวน

ผู้เขียนขอให้สังเกตว่ามีคอลัมน์ Missing Index ปรากฎอยู่ด้วย แสดงว่ายังไม่มี Index ตัวนี้อยู่
แต่ถ้ามีโอกาสที่ถูกเลือกใช้มากถึง 80% (ดูจาก Total Score)

จากรูปข้างบนบอกอะไรเราได้บ้าง

Missing Index ที่แนะนำเป็นชนิด Covering Index เป็นการสร้าง Index บนคอลัมน์เดียวคือ OrderDate (เลขแต่ละเลขหมายถึงลำดับคอลัมน์ใน Index ในรูปมีเพียงเลข 1 ดังนั้นจึงมีเพียงคอลัมน์เดียว) แต่จะเพิ่มคอลัมน์ Status ผ่านประโยค INCLUDE (Covering Index คือ Non-Clustered Index ที่มีการเติมคอลัมน์เพิ่มลงในระดับ Leaf ของโครงสร้าง Index ผ่านประโยค INCLUDE ประโยชน์เพื่อให้การประมวลผลสืบค้นจบที่ตัว Index เลยเพราะมีข้อมูลพร้อมสำหรับการแสดงผล)
พบว่ามี Index ชื่อ PK_SalesOrderHeader_SalesOrderID เป็นชนิด Clustered Index แสดงว่าตาราง Sales.SalesOrderHeader มีโครงสร้างแบบ Clustered และมี SalesOrderID เป็น Clustered Key ข้อมูลในตาราง (ใน Physical Storage) จะมีการเรียงตามคอลัมน์ที่มีเลขระบุอยู่ในที่นี้คือ SalesOrderID (Clustered Key สามารถเป็น Composite จากหลายคอลัมน์ได้ และ Clustered Key ของตารางจะถูกใส่ลงในระดับ Leaf ของโครงสร้าง Non-Clustered Indexes ทุกตัวที่อยู่ในตารางนี้)
มี Statistics บนคอลัมน์ OrderDate แม้ไม่มี Index ใดมีคอลัมน์ OrderDate เป็นองค์ประกอบเลยก็ตาม (ผู้เขียนรันสคริปต์เพื่อลบ Index ทุกตัวที่มี OrderDate เป็นองค์ประกอบไปก่อนหน้านี้แล้ว)

จากที่เคยเขียนในบทความหลายบทความก่อนหน้าไปแล้วว่า Statistics ถูกสร้างอัตโนมัติได้หลายกรณี

กรณีที่สร้าง Index จะสร้าง Statistics ชื่อเดียวกันขึ้นมาอัตโนมัติ
กรณีมีการใช้งานคอลัมน์ผ่านประโยค WHERE, GROUP BY หรือ ORDER BY โดยไม่มีคอลัมน์ดังกล่าวเป็นองค์ประกอบใน Index ตัวใดเลย ก็จะสร้าง Statistics ให้อัตโนมัติ โดยมีชื่อขึ้นต้นด้วย WASys

ผู้เขียนสืบค้นชื่อของ Statistics ผ่านสคริปต์ต่อไปนี้

SELECT
S.name as StatisticsName
FROM sys.stats as S INNER JOIN sys.stats_columns as SC
ON S.object_id=SC.object_id AND S.stats_id=SC.stats_id
INNER JOIN sys.columns as C
ON SC.object_id=C.object_id AND SC.column_id=C.column_id
WHERE C.name='OrderDate';

ได้ชื่อของ Statistics ออกมาเป็น WASys_00000003_72910220 ดังแสดง

ผลลัพธ์อาจแตกต่างไปในแต่ละเครื่อง เพราะตัวข้างหลังเป็นการ Random ขึ้นมา
ผู้เขียนได้ลองดึงข้อมูลของ Statistics ดังกล่าวผ่าน SSMS ได้ข้อมูลดังนี้

พบว่ามีคอลัมน์ OrderDate เป็นองค์ประกอบและปรับปรุงล่าสุดตรงกับที่แสดงผลในแท็บ Index Analysis ของ SentryOne Plan Explorer เราสามารถเรียกดูค่าฮิสโตแกรมของ Statistics ผ่านคำสั่ง DBCC SHOWSTATISTICS ได้ดังนี้

DBCC SHOW_STATISTICS (
'Sales.SalesOrderHeader'
, '_WA_Sys_00000003_72910220'
)
WITH HISTOGRAM;

ผลลัพธ์ที่ได้ดังแสดง

แต่การแสดงผลบน SentryOne Plan Explorer ดีกว่ามาก เพราะแสดงฮีสโตแกรมเป็นแผนภูมิจริงๆ เลยดังแสดง

อีกทั้งยังมีไฮไลต์ช่วงของข้อมูลที่คิวรี่ใช้งานเอาไว้ด้วย อีกทั้งเมื่อนำเมาส์ไปลอยอยู่เหนือแท่งฮิสโตแกรมจะได้รายละเอียดของแท่งนั้นๆ

ทดสอบสร้าง Indexes แนวทางที่ 1

ผู้เขียนทดสอบสร้าง Non-Clustered Index ขึ้นเองโดยมีเพียงคอลัมน์ OrderDate เป็นองค์ประกอบ ด้วยคำสั่งต่อไปนี้

CREATE NONCLUSTERED INDEX IX_SalesOrderHeader_OrderDate ON Sales.SalesOrderHeader
(
OrderDate ASC
);

หลังจากสร้าง Index เสร็จแล้วให้กดปุ่ม Get Estimated Plan ใน SentryOne Plan Explorer อีกครั้ง จะพบว่ามีการเลือก Compiled Plan ใหม่มาแทน Plan เดิม ดังแสดง

สิ่งแรกที่พบคือบรรดาเครื่องหมาย Warning หายไปเพราะไม่มีการ Scan แถวข้อมูลเกิดขึ้นเหมือนครั้งก่อน
และมีการใช้งาน Index ตัวที่สร้างขึ้น และภาระงานไปตกที่ตัวดำเนินการ Key Lookup

อย่างที่เคยบอกไว้ก่อนหน้าว่าหากตารางมีโครงสร้างแบบ Clustered จะนำเอา Clustered Key
ในที่นี้คือคอลัมน์ SalesOrderID ไปเติมไว้ในระดับ Leaf ของทุกๆ Non-Clustered Index

จากรูปเมื่อท่องไปใน Tree ของ Index ตาม Seek Predicates
ผลลัพธ์ที่ได้คือช่วงข้อมูลใน OrderDate ต้องการ พร้อมกับ SalesOrderID (Clustered Key ที่ถูกเติมเข้ามา) ผนวกมาด้วย

จากนั้นนำเอาบรรดา SalesOrderID ที่ได้มาไป Lookup ในตารางเพื่อหาคอลัมน์อื่นที่ต้องแสดงผล
คำสั่ง SELECT ของเราต้องการแสดงผลคอลัมน์ SalesOrderID, OrderDate และ Status
โดย SalesOrderID และ OrderDate พบแล้วใน Index
ขาดแต่คอลัมน์ Status ที่ต้องนำเอา SalesOrderID ไป Lookup มา

จากรูปจะเห็นว่า Seek Predicates เป็นการนำ SalesOrderID ไป Lookup ที่ตาราง Sales.SalesOrderHeader
ผลลัพธ์ที่ได้คือคอลัมน์ Status ของแต่ละ SalesOrderID

เมื่อนำเอาข้อมูลของตัวดำเนินการ SELECT ขึ้นมาดู
พบว่า Cost ลดลงจาก 0.54456 เป็น 0.526743 ซึ่งลดลงไม่มาก

ผู้เขียนยังคงหาหนทางลด Cost ลงไปอีกโดยลองสร้าง Non-Clustered Index เพิ่มอีก โดยมีเพียงคอลัมน์ Status เป็นองค์ประกอบ ด้วยคำสั่งต่อไปนี้

CREATE NONCLUSTERED INDEX IX_SalesOrderHeader_Status ON Sales.SalesOrderHeader
(
Status ASC
);

พบว่าตัวดำเนินการจับคู่ข้อมูลจากสองอินพุตเปลี่ยนเป็น Hash Match Join และมีภาระงานสูงสุดใน Plan
เพราะข้อมูลในการเข้าจับคู่ไม่เรียงอยู่ ทำให้ต้องสร้าง Hash Key ขึ้นมาจับคู่แทน

• อินพุตที่ 1 Index Seek บน IX_SalesOrderHeader_OrderDate
- ข้อมูลเรียงตาม OrderDate
- ข้อมูล SalesOrderID อาจเรียงหรือไม่เรียงอยู่
อินพุตที่ 2 Index Scan บน IX_SalesOrderHeader_Status
- ข้อมูลเรียงตาม Status
- ข้อมูล SalesOrderID กระจายตามการเรียงของ Status ทำให้ SalesOrderID ไม่เรียงอยู่

เมื่อนำเอาข้อมูลของตัวดำเนินการ SELECT ขึ้นมาดู
พบว่า Cost ลดลงไปพอสมควรจาก 0.54456 เป็น 0.236769 ซึ่งลดลงเกินครึ่งไปนิดหน่อย

DROP INDEX IX_SalesOrderHeader_OrderDate ON Sales.SalesOrderHeader;
DROP INDEX IX_SalesOrderHeader_Status ON Sales.SalesOrderHeader;

ทดสอบสร้าง Indexes แนวทางที่ 2

หลังจากลบ Indexes ที่ใช้ในการทดลองก่อนหน้าเรียบร้อยแล้ว
ให้กดปุ่ม Get Estimated Plan ใน SentryOne Plan Explorer อีกครั้ง
จะพบว่า Compiled Plan ที่ถูกเลือกเข้ามา มีรายละเอียดเหมือนก่อนการทดลองแรก

ให้เลือกแสดงแท็บ Index Analysis จากนั้นกดไปที่ปุ่ม <S> ใต้ Missing Index 1 จะปรากฎสคริปต์ตัวอย่างดังแสดง

DROP INDEX IX_SalesOrderHeader_OrderDate ON Sales.SalesOrderHeader; DROP INDEX IX_SalesOrderHeader_Status ON Sales.SalesOrderHeader; ทดสอบสร้าง Indexes แนวทางที่ 2 หลังจากลบ Indexes ที่ใช้ในการทดลองก่อนหน้าเรียบร้อยแล้ว ให้กดปุ่ม Get Estimated Plan ใน SentryOne Plan Explorer อีกครั้ง จะพบว่า Compiled Plan ที่ถูกเลือกเข้ามา มีรายละเอียดเหมือนก่อนการทดลองแรก ให้เลือกแสดงแท็บ Index Analysis จากนั้นกดไปที่ปุ่ม <S> ใต้ Missing Index 1 จะปรากฎสคริปต์ตัวอย่างดังแสดง

สคริปต์ดังกล่าวเป็นการสร้าง Covering Index โดยเติมคอลัมน์ Status ลงในระดับ Leaf ของโครงสร้าง Index ทำให้ Index ตัวนี้ประกอบด้วยคอลัมน์

OrderDate เป็นข้อมูลที่เรียงอยู่ในโครงสร้าง B+ Tree ตั้งแต่ระดับ Root, Intermediate และ Leaf
SalesOrderID เป็น Clustered Key ที่ถูกเติมเข้ามาในระดับ Leaf
Status ถูกเติมเข้ามาในระดับ Leaf ผ่านประโยค INCLUDE

ผู้เขียนขอนำเอาสคริปต์ไปดัดแปลงเติมชื่อให้เรียบร้อยดังนี้

CREATE INDEX IX_SalesOrderHeader_OrderDate_INC_Status ON Sales.SalesOrderHeader
(
OrderDate ASC
)
INCLUDE (Status);

หลังจากสร้าง Index เสร็จแล้วให้กดปุ่ม Get Estimated Plan ใน SentryOne Plan Explorer อีกครั้ง
จะพบว่ามีการเลือก Compiled Plan ใหม่มาแทน Plan เดิม ดังแสดง

พบว่าเหลือตัวดำเนินการเพียงตัวเดียว คือ Index Seek บน IX_SalesOrderHeader_OrderDate_INC_Status
เมื่อท่องไปใน Tree ตาม Seek Predicates (คอลัมน์ OrderDate ใน Index) จนได้ช่วงข้อมูลออกมาก็จะได้ค่าของคอลัมน์ SalesOrderID
และ Status ที่ถูกบรรจุไว้ในระดับ Leaf ออกมาด้วย ทำให้การสืบค้นจบลงที่ตัว Index เลย ไม่ต้องไป Lookup ต่อในตารางอีก

และเนื่องจากมี Index Seek เป็นตัวดำเนินการเพียงตัวเดียว
Subtree Cost ของตัวดำเนินการนี้จึงเป็นของทั้ง Plan ด้วย ซึ่งเท่ากับ 0.0034806
จากเดิม 0.54456 ถือว่าประสิทธิภาพสูงขึ้นมาก

หากสงสัยว่าจะใช้ Subtree Cost ของทั้ง Plan จริงหรือไม่
ก็สามารถดูข้อมูลของตัวดำเนินการ SELECT ได้

จะพบว่า Subtree Cost เป็นค่าเดียวกันกับของ Index Seek เลย

สรุป

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

ผู้เขียนไม่อยากชี้นำว่าเมื่อมีตัวดำเนินการ Lookup เกิดขึ้น จะต้องแก้ด้วย Covering Index ตลอด
เพราะ Covering Index ก็เป็น Non-Clustered Index แบบหนึ่ง มีได้และช่วยให้คิวรี่ได้เร็วขึ้นก็จริง
แต่มีเยอะเป็นภาระของ Storage และทำให้ Insert, Update และ Delete ข้อมูลในตารางช้าลง
ผู้อ่านควรหาจุดสมดุลย์ด้วยตัวเอง