สภาพภายใน JOIN หรือ WHERE

มีความแตกต่าง (ประสิทธิภาพการปฏิบัติที่ดีที่สุด ฯลฯ ... ) ระหว่างการวางเงื่อนไขในข้อเข้าร่วมกับข้อไหน?

ตัวอย่างเช่น...

-- Condition in JOIN
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND CUS.FirstName = 'John'

-- Condition in WHERE
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE CUS.FirstName = 'John'

คุณชอบแบบไหน (และอาจเป็นเพราะเหตุใด)

พีชคณิตเชิงสัมพันธ์ช่วยให้การเปลี่ยนค่าของเพรดิเคตในWHEREclause และ the INNER JOINดังนั้นแม้แต่INNER JOINเคียวรีที่มีWHEREclauses สามารถมีเพรดิเคตที่จัดเรียงใหม่โดย optimizer เพื่อให้พวกเขาอาจถูกแยกออกระหว่างJOINกระบวนการ

ฉันขอแนะนำให้คุณเขียนข้อความค้นหาในวิธีที่สามารถอ่านได้มากที่สุด

บางครั้งสิ่งนี้รวมถึงการทำให้INNER JOIN"ค่อนข้างไม่สมบูรณ์" และวางหลักเกณฑ์บางอย่างไว้ในWHEREเพียงเพื่อทำให้รายการของเกณฑ์การกรองง่ายขึ้น

ตัวอย่างเช่นแทนที่จะเป็น:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

เขียน:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

แต่แน่นอนว่าขึ้นอยู่กับ

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

อย่างไรก็ตามที่คุณใส่เงื่อนไขสร้างความแตกต่างอย่างมากถ้าคุณใช้การรวมซ้ายหรือขวา ยกตัวอย่างเช่นพิจารณาทั้งสองแบบสอบถาม:

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderDate >'20090515'

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND ORD.OrderDate >'20090515'

ครั้งแรกที่จะให้คุณบันทึกเฉพาะผู้ที่มีคำสั่งลงวันที่หลังจาก 15 พฤษภาคม 2009 จึงแปลงการเข้าร่วมด้านซ้ายเพื่อเข้าร่วมภายใน

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

ข้อยกเว้นนี้คือเมื่อคุณต้องการดูเฉพาะระเบียนในตารางหนึ่ง แต่ไม่ใช่ระเบียนอื่น จากนั้นคุณใช้ตำแหน่งข้อสำหรับเงื่อนไขไม่ใช่การเข้าร่วม

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderID is null

ผลิตภัณฑ์ RDBMS ส่วนใหญ่จะปรับทั้งข้อความค้นหาให้เหมือนกัน ใน "การปรับแต่งประสิทธิภาพของ SQL" โดย Peter Gulutzan และ Trudy Pelzer พวกเขาทดสอบ RDBMS หลายยี่ห้อและไม่พบความแตกต่างด้านประสิทธิภาพ

ฉันต้องการแยกเงื่อนไขการเข้าร่วมออกจากเงื่อนไขการ จำกัด การสืบค้น

หากคุณกำลังใช้OUTER JOINบางครั้งก็จำเป็นต้องใส่เงื่อนไขไว้ในข้อเข้าร่วม

ที่ใดจะกรองหลังจากเกิดการเข้าร่วม

กรองใน JOIN เพื่อป้องกันไม่ให้เพิ่มแถวในระหว่างกระบวนการเข้าร่วม

ฉันชอบ JOIN ที่จะเข้าร่วมตารางเต็ม / มุมมองแล้วใช้ WHERE เพื่อแนะนำภาคแสดงของชุดผลลัพธ์

มันรู้สึกสะอาดขึ้น

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

ฉันมักจะขบขันอย่างอ่อนโยนเมื่อมีคนแสดงการเปรียบเทียบ SQL ของพวกเขาและพวกเขาได้ดำเนินการทั้ง sproc 50,000 ครั้งในเวลาเที่ยงคืนบนเซิร์ฟเวอร์ dev และเปรียบเทียบเวลาเฉลี่ย

การใส่เงื่อนไขในการเข้าร่วมดูเหมือนว่า "ผิดเชิงความหมาย" สำหรับฉันเพราะนั่นไม่ใช่สิ่งที่ JOIN ทำเพื่อ "" แต่คุณภาพมาก

ปัญหาเพิ่มเติม: หากคุณตัดสินใจที่จะเปลี่ยนจากการเข้าร่วมภายในเป็นพูดเข้าร่วมที่ถูกต้องโดยมีเงื่อนไขอยู่ใน JOIN อาจนำไปสู่ผลลัพธ์ที่ไม่คาดคิด

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

มันจะดีกว่าที่จะเพิ่มเงื่อนไขในการเข้าร่วม ประสิทธิภาพมีความสำคัญมากกว่าความสามารถในการอ่าน สำหรับชุดข้อมูลขนาดใหญ่มันสำคัญ