SQL ไม่รู้จบ
posted on 24 Nov 2005 17:11 by kaze in Technologyอุอุ.. ไม่ได้อัพบลอกค่อนข้างนานมากเลยช่วงนี้
เพราะไม่มีอะไรจะให้อัพ (จริงๆก็พอมีแหละแต่ค่อนข้างขี้เกียจ)
เอาเป็นว่าวันนี้ขออัพเรื่อง technical สักหน่อย
เนื่องจากช่วงที่ผ่านมาทำหลายๆอย่างเกี่ยวกับ SQL ค่อนข้างเยอะ
โดยเน้นไปที่ oracle และ sybase ซึ่งเป็น database 2 เจ้าที่มีคนใช้ค่อนข้างเยอะมากๆ
sybase ส่วนใหญ่จะใช้กับระบบเก่าหน่อยในงานพวก financial เพราะมันยืดหยุ่นสูง
ขณะที่ในระยะหลัง oracle ได้รับความนิยมสูงขึ้นเนื่องจากประสิทธิภาพในการทำงานที่ดีกว่า
แต่ถ้าเป็นของ free เห็นทีจะไม่พ้น MySQL ซึ่งหลังๆ PostgreSQL ดูนิยมมากขึ้น
เพราะ performance ที่ว่ากันว่าดีกว่า
ถ้าดึงข้อมูลไม่กี่หมื่น record มันอาจจะไม่เห็นความแตกต่างมากนัก
แต่ข้อมูลขนาดแสน record join กันหลายๆ table อาจจะเห็นได้ชัดมากขึ้น
หากคนที่ลอง database มาหลายๆเจ้าแล้วจะพบว่า จริงๆแล้ว MS SQL server
กับ sybase จะคล้ายกันมากๆทั้ง table ที่เก็บข้อมูลของระบบ และหลักการทำงานต่างๆ
นั่นก็เป็นเพราะมันมาจากบรรพบุรุษเดียวกัน (ไม่ต้องบอกก็คงจะพอเดากันได้ว่าใครซื้อใคร)
สัปดาห์ที่ผ่านมาต้องทำเรื่อง performance tunning ใน sybase
สิ่งที่ต้องทำก็คือ ถ้าเรา join หลายๆ table ต้องพยายามใน index ในการ search ข้อมูล
ของ table ใหญ่ๆ ให้มากที่สุด ลดหรือให้มีการอ่านแบบ full scan table ให้น้อยที่สุด
อย่างแรกที่คุณควรจะทำเวลา tunning SQL ใน sybase และน่าจะรวมถึง MS SQL server
ก็คือพยายามดูที่ where clause ว่าเรียงกันดีหรือยัง ขอบอกว่ามันมีผลต่อการเลือกใช้ index
สิ่งที่ควรกระทำคือ
1. ถ้ามี where clause ที่ filter ค่าควรทำก่อน (where clause ที่มี condition
เทียบกับค่าคงที่ เช่น account.acctid > 3 )
2. ถ้าเป็น table 2 table เป็น condition ใน where clause ให้เอา table หลัก
อยู่ทางด้านขวา เช่น detail.id = main.id
3. ถ้า table มี index ที่ใช้หลายๆ field ให้เรียงลำดับ field ด้วย เช่น
index on account (acctid, effdate, enddate) ก็ต้อง where clause เรียงเป็น
where
account.acctid > 3 AND
account.effdate <= '2005-01-01 00:00:00' AND
account.enddate > '2005-01-01 00:00:00'
เป็นต้น
4. ทำ transitive closure หมายถึง ถ้ามี table 3 table แล้วทำ 3 table link กันด้วย id
บางคนอาจจะใส่แค่ tab1.id = tab2.id AND tab2.id = tab3.id
ถ้าเรียง where clause ดีอาจจะไม่มีผล แต่ถ้าเรียงไม่ดีจะให้การเลือก index ของ
optimizer ไม่ถูกต้อง เพราะฉะนั้นให้ทำเป็น
tab1.id = tab2.id AND
tab2.id = tab3.id AND
tab1.id = tab3.id
จะช่วยในการเลือก index ได้ถูกต้อง เพราะ optimizer มีเส้นทางให้เลือกมากขึ้น
แต่สุดท้าย SQL ก็คงมีเรื่องให้วุ่นๆไม่รู้จักจบสิ้นตราบใดที่ มาตรฐานที่ใช้ไม่ใช่มาตรฐานเดียวกัน