Home > SQL Performance Tuning > การทำ Performance Tuning SQL Query เบื้องต้น (part 2 – ขั้นตอนในการ Tuning)

การทำ Performance Tuning SQL Query เบื้องต้น (part 2 – ขั้นตอนในการ Tuning)


จากใจผู้เขียน :

“จากบทความต่างๆ ที่ผมได้ post ลงไปใน blog นี้ ผมได้พบว่ามี blogger บางท่าน ได้นำข้อมูลต่างๆ จาก blog ผมไป post ต่อ โดย copy ไป และวางใน blog ของท่าน ผมอยากจะบอกว่าเนื้อหาทั้งหมดนั้น บางอย่างผมก็ได้ copy link เค้ามาเพื่อให้เกียรติหรือเครดิตกับเจ้าของเนื้อหา บางเรื่องผมได้เขียนจากประสบการณ์ทำงานทั้งหมด

ดังนั้นผมจึงอยากจะขอ ความกรุณา blogger ทุกท่าน ถ้า copy เนื้อหาของผมไป โดยเฉพาะส่วนที่ผมเขียนขึ้นมาเอง กรุณาให้เครดิตผมด้วยครับ เช่นวาง link ว่ามาจาก blog ของผมด้วยครับ อย่างน้อย ก็เป็นกำลังใจที่จะให้ผมเขียนบทความดีๆ ต่อไป”


การ Tuning Query นั้น จากประสบการณ์ของผม ควรจะมีขั้นตอนในการ Tune ดังนี้ครับ

  1. Performance Baseline Measurement
  2. Database Design
  3. Optimizing Query Syntax
  4. Index Strategy
  5. Reduce Locking and Blocking
  6. Database Server Configuration
  7. Data Warehouse Strategy
  8. Hardware Upgrade Strategy

1) Performance Baseline Measurement

ก่อนที่จะลงมือทำการ Tuning ใดๆ ผมมีข้อแนะนำครับ เราควรจะทำการวัด baseline ทั้งหมดก่อน เช่น cpu percent processing, disk queue, query time, no. of page scan เป็นต้น

ถ้าถามว่าทำเพื่ออะไร ผมมีเหตุผลง่ายๆ โดยการสมมติครับ เหมือนกับว่าเราเป็นไข้ไปหาหมอ (หมออีกแล้ว!!!) ทางคุณหมอก็จะทำการวัดไข้แล้วบันทึกลงไปใช่ไหมครับ สมมติว่าเราวัดไข้ได้ 38 องศา ทีนี้พอเราได้ยามาทาน เราก็จะสามารถทราบได้ว่าไข้มันลดลงหรือยังโดยการวัดไข้อีกครั้งนึง เพื่อเปรียบเทียบว่าลดลงจาก 38 องศาหรือเปล่า แต่ถ้าเราไม่ได้วัดไข้ก่อนกินยา เราก็จะไม่สามารถทราบได้เลยว่า ยาที่เราทานนั้น ได้ผลหรือไม่ครับ

ก่อนที่จะเริ่มทำการ Tuning ก็เหมือนกันครับ เราควรจะวัด baseline ทั้งหมดก่อน แล้วหลังจากนั้นเราค่อยลงมือการทำการ Tuning แล้ววัดตัวเลขทั้งหมดอีกครั้ง เพื่อเปรียบเทียบว่ามันดีขึ้นหรือแย่ลงน่ะครับ

เครื่องมือที่ใช้ปกติก็จะมี Performance Monitor กับ SQL Profiler ส่วนวิธีการใช้งานจะกล่าวถึงในตอนต่อๆ ไปครับ

2) Database Design

จุดแรกที่ควรจะเริ่มลงมือ tuning ถ้าเป็นไปได้ ก็ควรจะเป็นที่ Database Design ครับ เพราะว่าเป็นจุดที่ใหญ่ที่สุดในเรื่อง performance ครับ ถ้า design ดีก็ถือว่ามีชัยไปกว่าครึ่งแล้ว

Database Architecture ที่นิยมที่สุดในโลกนี้ก็คือ Relational Database แต่รู้ไหมครับว่า Relational มีจุดเสียที่ใหญ่ที่สุดอยู่ข้อนึงก็คือ ถ้า Query ข้อมูลโดย join table หลายๆ table เข้าไปหล่ะก็ รับรองครับ ช้าแน่ๆ

วิธีแก้ง่ายๆ ก็คือ เราอาจจะพิจารณา Database Architecture แบบอื่นเข้าไปครับ ลองพิจารณา Database Architecture ดังรายการต่อไปนี้ดูสิครับว่า Architecture แบบไหน เหมาะกับการทำ Query มากที่สุด

  • Relational
  • Hierarchical
  • Object Oriented DB
  • Document DB
  • Network DB

คำตอบก็คือ Hierarchical ครับ ดังนั้นวิธีการออกแบบ Database ที่มีประสิทธิภาพที่สุด ก็ควรจะเป็นดังรูปถัดไปครับ

รูป 2-1 Data Warehouse Concept

จากรูป 2-1 จะเห็นว่าจะเป็นก้อน Relation เราจะใช้เป็น Data Entry อย่างเดียว ส่วนก้อนด้านล่าง เราจะใช้เพื่อ Query ในการออก Report ครับ

ทีนี้ในการออกแบบก็คือส่วนที่เป็น RDB เราก็พยายามใช้หลักการ Normalization ให้เต็มที่ หรือพยายามทำให้ RDB รับผิดชอบเฉพาะคำสั่ง Insert, Update, Delete ให้ดีก็พอครับ

ส่วนก้อน HDB ก็พยายามออกแบบให้รองรับ Query ให้ดีที่สุด เป็นการแบ่งหน้าที่รับผิดชอบอย่างชัดเจนครับ

ในทางปฏิบัติ เราจะมาถึง Data Warehouse ได้จริงๆ ก็คงจะต้องพยายาม tune rdb ให้เต็มที่ก่อนแหล่ะครับ สำหรับ database เล็กๆ ผมจะไม่แนะนำ แต่ถ้าเป็น database ใหญ่ๆ วิธีนี้ก็อาจจะเป็นวิธีที่ช่วยให้เราหลีกเลี่ยงการ upgrade hardware มาหลาย project แล้วครับ

สำหรับ database เล็กๆ เราก็มีวิธีการ Tuning ในหนทางของมันอยู่ เอาไว้ผมจะค่อยๆ เขียนในบทความต่อๆ ไปครับ

3) Optimizing Query Syntax

เป็นจุดที่ผมได้รับคำถามมากที่สุดเลยครับ ประมาณว่า “เขียน query แบบไหนจะเร็วกว่ากัน”

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

4) Index Strategy

เป็นวิธีที่นัก Tuning หลายๆ ท่านมันนิยมทำกันมากที่สุด และก็เป็นวิธีที่ผมนิยมทำเสียด้วย เหตุผลน่ะหรือครับ? เพราะว่าทำได้ง่ายและรวดเร็วไงครับ และที่สำคัญ เราไม่ได้ไปแก้ไข Query Syntax เลย

หลักการของ Index ก็คือ “ลดจำนวน disk scan” นั่นเองครับ เพราะว่า Bottle neck ที่ใหญ่ที่สุด ก็คือ disk ครับ ถ้าเราหาวิธีลดการ scan disk ลงได้ รับรองว่า เร็วขึ้นชัวร์

วิธีนี้ผมจะอธิบายในตอนถัดไปครับ (Part 3)

ขอจบตอนนี้ที่ขั้นตอนที่ 4 ก่อนนะครับ ส่วนที่เหลือจะขอต่อในตอนต่อไปครับ (post ทีละน้อย แต่จะพยายามขยัน post บ่อยๆ ครับ) ถ้ามี comment บ้าง ก็ขอขอบคุณครับ จะได้เป็นกำลังใจให้ผมเขียนต่อไปเรื่อยๆ ครับ🙂

หลักสูตรอบรม Tuning SQL Server (Click)

 

  1. prakarn
    August 19, 2010 at 14:01

    ติดตามอ่านอยู่ครับมีประโยชน์สำหรับโปรแกรมเมอร์อย่างผมที่อยากเป็น DBA

  2. ยงยุทธ
    August 20, 2010 at 22:53

    ยินดีครับ คุณ prakarn เดือนกันยายนนี้ ผมจะเขียนตอนใหม่อยู่พอดีขอบคุณนะครับ ที่ติดตามอ่าน ^_^

  3. prakarn
    August 23, 2010 at 09:44

    ตอนนี้ผมไล่อ่านทุกตอนละครับชอบมากครับได้มุมมองดีครับ ตามอ่านอยู่นะครับอาจารย์

  4. ยงยุทธ
    August 24, 2010 at 19:09

    ขอบคุณครับ ^_^

  5. mongkonwish
    May 3, 2011 at 14:43

    ชอบมากครับ ผมก็เป็นโปรแกรมเมอร์คนนึง กะลังมีปัญหากับการ query ข้อมูลเพียง 3000 record ก็รู้สึกมันหน่วงๆ ประมาณ 1-2 วินาทีอ่าครับ จะขอเข้ามาศึกษาหาความรู้ในเว็บของอาจารย์นะครับ

  6. Plugfai Pankaew
    June 12, 2013 at 15:05

    บอกตรงๆเลยครับ
    ผมทำ HDB ไปแบบไม่รู้ตัวมาก่อน
    (ทำเพราะคิดว่ามันดีกว่า โดยไม่รู้ด้วยซ้ำว่าที่ตัวเองทำมันเข้าท่า หรือเป็นสิ่งที่อยู่ในหลักการ)

    = =”

  7. gos
    October 19, 2014 at 00:07

    สวดยวด เจ้านายกำลังใช้เลย

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: