บทความ IT เจ๋งๆ

หากคุณต้องเขียน SQL และทำงานเกี่ยวข้องกับ Database เมื่อคุณ Run Queries แล้วมันทำงานช้าขึ้นมา แน่นอนว่าคุณต้องกลับเข้าไปดู Queries ที่คุณเขียนว่าจะสามารถแก้ไขจุดที่เป็นต้นเหตุ วันนี้เรามาดู 10 วิธีปรับแต่ง Queries ที่ทำงานช้าให้เร็วยิ่งขึ้นกัน (ในบทความนี้ จะใช้ตัวอย่างของ PostgreSQL แต่คุณสามารถนำหลักการเหล่านี้ไปประยุกต์ใช้กับ Database อื่นได้เช่นกัน)

1. ความรวดเร็วเป็นสิ่งสำคัญ

Database ของคุณต้องทำงานหนักมากแค่ไหน? คุณกำลัง Run Query ที่มีความซับซ้อนในช่วงเวลาที่มี User หลายคนกำลังแย่งกันใช้งาน Memory หรือไม่? 

Strategy:

คุณสามารถทำสิ่งนี้ได้โดยถามหรือสืบข้อมูลเอาจาก Database ... ไม่ใช่โดยการไล่ถามทุกคนในบริษัท

สิ่งนี้อาจถูกควบคุมเพื่อป้องกันความปลอดภัยโดย DBA ทำให้ผลลัพธ์ที่ได้อาจแตกต่างกันไป

2. การ Locked out

Table กำลังมีการ Update อยู่หรือไม่? หากคุณพบข้อผิดพลาดใน Table ที่ Update จาก ETL Process คุณอาจถูก Block จากการ Update และไม่สามารถ Run Query ของคุณได้

Strategy:

พูดคุยกับทีมที่ทำ ETL เพื่อที่คุณจะได้ตรวจสอบให้แน่ใจว่า Windows จะถูก Update เมื่อใด

3. คุณไม่จำเป็นต้องใช้ทุกอย่าง

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

เริ่มต้นอย่างแรกกันที่ ... คุณจำเป็นต้องใช้ SELECT * หรือไม่?

Strategy:

• หากคุณกำลังมองหาแนวคิดที่ว่ามีอะไรที่อยู่ใน Table บ้าง ลองขยาย Column List ใน Schema Tree ดู
• ดึงชื่อเฉพาะ Column ที่คุณต้องการเพื่อให้ได้ผลที่รวดเร็วขึ้น แทนที่จะใช้ SELECT * เพื่อดึงข้อมูลทั้งหมดออกมา
• หากคุณมี Table ที่มีขนาดใหญ่หรือมีข้อมูลปริมาณมากใน Table มีแนวโน้มที่จะทำให้ Query Engine ต้องทำงานหนักในการดึงข้อมูลทุกอย่างไปสู่ Client Side เว้นเสียแต่ว่าถ้าคุณต้องการดูข้อมูลในทุก ๆ Row ก็อย่าลืมที่จะใช้ LIMIT เพื่อจำกัดจำนวนของผลลัพธ์
• หากคุณต้องการใช้ COUNT (แทนที่จะเรียกใช้ Query เพื่อนับจำนวนของ Row ที่ด้านล่างของหน้าจอ) ขอแนะนำให้คุณใช้ Subqueries เพื่อนับ Row ให้คุณ

4. Uppers และ Lowers

ใน PostgreSQL จะมีการคำนึงถึงเรื่อง Case Sensitive ซึ่งบางคนอาจรู้สึกคุ้นเคยกับมันมากขึ้น หากคุณเคยใช้ SQL Server

Strategy:

• หากคุณกำลังพยายามทำ 'Lowering' หรือ 'Uppering' ข้อมูลอยู่ คุณอาจต้องใช้ความพยายามอย่างมาก คุณควรทำเฉพาะในกรณีที่จำเป็นจริง ๆ ควรตรวจสอบว่าข้อมูลของคุณเป็นอย่างไรก่อนที่จะเพิ่มอะไรลงใน Query ของคุณแบบไม่มีหลักการ
• หากมีความจำเป็นที่ต้องใช้การ Join แนะนำให้ใช้การ Join เพียงด้านเดียวเท่านั้น หรือลองใช้ ILIKE สำหรับการ Match แบบ Insensitive

5. ระวังการใช้ NOT IN

พยายามหลีกเลี่ยงการใช้ 'IN' หรือ 'NOT IN' เพราะการทำเช่นนี้ หมายถึง คุณกำลัง Scan ทั้ง Table อยู่ เพราะ Query Engine จะไล่ดูไปที่ทุก Row เพื่อตรวจสอบว่า ตรงตามเงื่อนไขหรือไม่

Strategy:

ลองใช้ 'EXCEPT' หรือ 'NOT EXISTS' ดู เพราะมันจะส่งผลกระทบต่อ Query Plan น้อยกว่าการใช้ 'NOT IN'

6. จะใช้ CTE หรือไม่ใช้ CTE ดี

ในขณะที่ CTEs (Common Table Expressions) นั้นอ่านง่ายกว่า Subquery แต่ใน PostgreSQL มันจะป้องกัน Query Optimizer จากการ Rewrite Query โดยการย้าย Constraints เข้าหรือออกจาก CTE

Strategy:

ทั้ง CTEs และ Subquery นั้นต่างก็มีประโยชน์ ส่วนแบบไหนจะดีกว่าแบบไหน ก็ขึ้นอยู่กับแต่ละกรณีไป เวลาเขียน CTE ให้นำขนาดของ Table, จำนวนของ Row ที่ Return กลับมา, และ Action ที่จะทำกับ Row เหล่านั้นมาร่วมพิจารณาด้วย

7. ใช้ Wildcards เท่าที่จำเป็น

การใช้ Wildcards ที่จุดเริ่มต้นและจุดสิ้นสุดของ LIKE จะทำให้การ Query ช้าลง และอาจจะทำให้คุณผลลัพธ์ที่มากเกินกว่าที่คุณต้องการ

Strategy:

ใช้ Wildcards เฉพาะเมื่อคุณต้องการใช้งานจริง ๆ เท่านั้น โดยทั่วไปจะใช้กันเพียงแค่จุดเดียวเท่านั้น ดังนั้น จึงควรคำนึงถึงสิ่งที่คุณต้องการจะให้ Query Engine ทำ

8. ระวัง Nested Queries

การ Run หลาย ๆ Queries ซ้อนกันไปเรื่อย ๆ (Nested Queries) เหมือนอย่าง Function ถือเป็นสิ่งที่ไม่แนะนำให้ทำ และมันจะเร็วกว่าหากคุณเขียนลงใน Table

Strategy:

ลองพิจารณาการสร้าง Staging Tables หากคุณมีหลายขั้นตอนสำหรับ Process ของคุณ ซึ่งนั่นหมายถึง คุณกำลัง Join Subset ของข้อมูลที่เล็กลง ทำให้การ Query เร็วขึ้น

9. ระวังการใช้ Views ซ้อน ๆ กัน

Views เป็น Queries ที่จะ Run เมื่อคุณเข้าถึงมุมมองที่มองเห็น หากคุณกำลังเรียกหลาย ๆ View หรือในกรณีที่แย่ที่สุด คือ การเรียก Views ซ้อน Views ซ้อน Views ไปเรื่อย ๆ นั่นคือ คุณกำลังบอกให้ Query Engine ทำการ Run หลาย ๆ Queries เพื่อ Return Column ของคุณ

Strategy:

• แนะนำให้เขียนมันลงไปใน Table หากคุณต้องการดูข้อมูลในแต่ละ วัน/สัปดาห์/เดือน แทนที่จะใช้ Views เพื่อ Filter มัน
• หากคุณใช้ Nested Views อยู่ อยากให้ลองพิจารณาดูว่า ยังมีวิธีอื่นอีกหรือไม่ ที่สามารถทำได้ตรงกว่านี้ในการเข้าถึง Column ที่คุณต้องการด้วยการเขียน Queries แทนการ Run หลาย Queries เพื่อไปยัง Column ที่ต้องการจาก Nested Views ตัวสุดท้าย

10. Indexes

Indexes จะช่วยเพิ่มความเร็วให้ Queries ของคุณ โดยการจัดลำดับข้อมูลเพื่อให้ Database Engine ทราบว่าจะหาข้อมูลที่ต้องการได้จากที่ไหน หรือมี Lookup Table เพื่อที่มันจะสามารถทราบตำแหน่งที่จะค้นหาได้ ประเภทของ Indexes ที่คุณใช้จะเป็นตัวกำหนดวิธีการทำงานของ Indexes

Strategy:

• ใช้ Indexes สำหรับ Column ที่คุณจะใช้งานมันบ่อย ๆ ใน Queries ของคุณซึ่งมี High Cardinality หรือ Rates of Change
• อย่าลืมสำรวจ Indexes เพื่อให้แน่ใจว่าคุณคุณจะไม่มีจำนวนของ Table ที่มากเกินไป

หวังว่าเคล็ดลับเหล่านี้จะช่วยในการปรับแต่ง Query ของคุณ ให้เกิดประสิทธิภาพและรวดเร็วมากยิ่งขึ้น

ที่มา:  https://dev.to/