Explicit vs implicit SQL joins

มีความแตกต่างของประสิทธิภาพในการรวมภายในอย่างชัดเจนกับนัยหรือไม่? ตัวอย่างเช่น:

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

เมื่อเทียบกับ

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

ประสิทธิภาพการทำงานที่ชาญฉลาดพวกเขาเหมือนกัน (อย่างน้อยใน SQL Server)

PS: โปรดทราบว่าIMPLICIT OUTER JOINไวยากรณ์เลิกใช้แล้วตั้งแต่ SQL Server 2005 ( IMPLICIT INNER JOINยังคงสนับสนุนไวยากรณ์ตามที่ใช้ในคำถาม)

การเลิกใช้งานไวยากรณ์ "แบบเก่า" ของ JOIN: เป็นเพียงบางส่วนเท่านั้น

ส่วนตัวฉันชอบไวยากรณ์การรวมที่ทำให้ชัดเจนว่าตารางจะเข้าร่วมและวิธีที่พวกเขาจะเข้าร่วม ลองเปรียบเทียบแบบสอบถาม SQL ขนาดใหญ่ที่คุณเลือกจาก 8 ตารางที่แตกต่างกันและคุณมีการกรองจำนวนมากในที่ โดยใช้ไวยากรณ์การเข้าร่วมคุณแยกส่วนที่ตารางเข้าร่วมไปยังส่วนที่คุณกำลังกรองแถว

ใน MySQL 5.1.51 แบบสอบถามทั้งสองมีแผนการดำเนินการเหมือนกัน:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1มี 166208 แถว table2มีประมาณ 1,000 แถว

นี่เป็นกรณีที่ง่ายมาก ไม่ได้เป็นการพิสูจน์ว่าเครื่องมือเพิ่มประสิทธิภาพการสืบค้นจะไม่สับสนและสร้างแผนการที่แตกต่างในกรณีที่ซับซ้อนมากขึ้น

ไวยากรณ์ที่สองมีความเป็นไปได้ที่ไม่พึงประสงค์ของการเข้าร่วมไขว้: คุณสามารถเพิ่มตารางลงในส่วน FROM โดยไม่ต้องมีคำสั่ง WHERE ที่เกี่ยวข้อง สิ่งนี้ถือว่าเป็นอันตราย

คำตอบแรกที่คุณให้ไว้จะใช้สิ่งที่เรียกว่าไวยากรณ์การเข้าร่วม ANSI คำอื่น ๆ นั้นใช้ได้และจะทำงานในฐานข้อมูลเชิงสัมพันธ์ใด ๆ

ฉันเห็นด้วยกับ grom ว่าคุณควรใช้ไวยากรณ์การเข้าร่วม ANSI ดังที่พวกเขาพูดเหตุผลหลักคือเพื่อความชัดเจน แทนที่จะมีส่วนคำสั่ง where ที่มีเพรดิเคตจำนวนมากซึ่งบางตารางเข้าร่วมและอื่น ๆ ที่ จำกัด แถวที่ส่งคืนด้วยไวยากรณ์การเข้าร่วม ANSI ที่คุณกำลังทำให้ชัดเจนว่าเงื่อนไขใดบ้างที่ถูกใช้เพื่อเข้าร่วมตารางของคุณ ผล.

ประสิทธิภาพการทำงานที่ชาญฉลาดพวกเขาเหมือนกัน (อย่างน้อยใน SQL Server) แต่โปรดระวังว่าพวกเขากำลังเลิกใช้ไวยากรณ์การเข้าร่วมนี้และไม่รองรับ sql server2005 นอกกรอบ

ฉันคิดว่าคุณกำลังคิดถึงตัวดำเนินการ * = และ = * ที่เทียบกับ "การรวมภายนอก"

ฉันเพิ่งทดสอบรูปแบบสองรูปแบบที่กำหนดและทำงานได้อย่างถูกต้องบนฐานข้อมูล SQL Server 2008 ในกรณีของฉันพวกเขาให้ผลแผนการดำเนินการที่เหมือนกัน แต่ฉันไม่สามารถพูดได้อย่างมั่นใจว่าสิ่งนี้จะเป็นจริงเสมอ

@ lomaxx: เพื่อชี้แจงฉันค่อนข้างมั่นใจว่าทั้งไวยากรณ์ข้างต้นได้รับการสนับสนุนโดย SQL Serv 2005 ไวยากรณ์ด้านล่างนี้ไม่ได้รับการสนับสนุน

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

ไม่สนับสนุนการรวมภายนอก (* =)

ในบางฐานข้อมูล (โดยเฉพาะ Oracle) ลำดับการรวมสามารถสร้างความแตกต่างอย่างมากต่อประสิทธิภาพการค้นหา (ถ้ามีมากกว่าสองตาราง) ในแอปพลิเคชันเดียวเรามีสองคำสั่งที่มีขนาดต่างกันในบางกรณี การใช้ไวยากรณ์การรวมภายในช่วยให้คุณควบคุมสิ่งนี้ได้ - หากคุณใช้ไวยากรณ์คำแนะนำที่ถูกต้อง

คุณไม่ได้ระบุว่าคุณใช้ฐานข้อมูลใดอยู่ แต่ความน่าจะเป็นแนะนำให้ SQL Server หรือ MySQL ที่ซึ่งมันทำให้ไม่แตกต่างกันจริง

ดังที่ Leigh Caldwell ได้กล่าวไว้เครื่องมือเพิ่มประสิทธิภาพการสืบค้นสามารถสร้างแผนการสืบค้นที่แตกต่างกันโดยขึ้นอยู่กับลักษณะการใช้งานที่ดูเหมือนคำสั่ง SQL เดียวกัน สำหรับการอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ให้ดูที่การโพสต์บล็อกสองรายการต่อไปนี้: -

การโพสต์เดียวจากทีม Oracle Optimizer Team

การโพสต์อื่นจากบล็อก "ข้อมูลที่มีโครงสร้าง"

ฉันหวังว่าคุณจะพบสิ่งที่น่าสนใจ

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

โดยพื้นฐานแล้วความแตกต่างระหว่างทั้งสองคือสิ่งที่เขียนในแบบเก่าในขณะที่อีกคนหนึ่งเขียนในแบบที่ทันสมัย โดยส่วนตัวแล้วฉันชอบสคริปต์ที่ทันสมัยโดยใช้คำจำกัดความด้านใน, ด้านนอก, ด้านนอก, ด้านขวาเนื่องจากมีคำอธิบายที่ชัดเจนกว่าและทำให้โค้ดอ่านง่ายขึ้น

เมื่อจัดการกับการรวมภายในไม่มีความแตกต่างในการอ่านอย่างแท้จริงอย่างไรก็ตามมันอาจมีความซับซ้อนเมื่อจัดการกับการรวมซ้ายและขวาเหมือนกับวิธีเก่าที่คุณจะได้รับดังนี้:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

ด้านบนเป็นวิธีการเขียนการรวมด้านซ้ายแบบเดิมซึ่งตรงข้ามกับสิ่งต่อไปนี้:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

ดังที่คุณเห็นด้วยตาวิธีการเขียนสคริปต์ที่ทันสมัยทำให้แบบสอบถามสามารถอ่านได้มากขึ้น (โดยวิธีเดียวกันไปสำหรับการรวมที่เหมาะสมและซับซ้อนเล็กน้อยสำหรับการรวมภายนอก)

การย้อนกลับไปยังแผ่นบอยเลอร์มันไม่ได้สร้างความแตกต่างให้กับคอมไพเลอร์ SQL ว่าวิธีการเขียนคิวรีนั้นเป็นอย่างไรในการจัดการแบบเดียวกัน ฉันได้เห็นทั้งสองอย่างในฐานข้อมูล Oracle ซึ่งมีหลายคนที่เขียนลงไปทั้งผู้อาวุโสและผู้ที่อายุน้อยกว่า อีกครั้งมันจะลดลงไปถึงวิธีการอ่านสคริปต์และทีมที่คุณกำลังพัฒนาด้วย

จากประสบการณ์ของฉันการใช้ cross-join-with-a-where-clause syntax มักจะสร้างแผนการดำเนินการที่สมองเสียหายโดยเฉพาะถ้าคุณใช้ผลิตภัณฑ์ Microsoft SQL วิธีที่ SQL Server พยายามประมาณจำนวนแถวของตารางนั้นน่ากลัวอย่างยิ่ง การใช้ไวยากรณ์การรวมภายในช่วยให้คุณสามารถควบคุมวิธีการดำเนินการค้นหา ดังนั้นจากมุมมองที่ใช้งานได้จริงเนื่องจากธรรมชาติของเทคโนโลยีฐานข้อมูลปัจจุบันคุณต้องไปกับการรวมภายใน