ด้วย (NOLOCK) เทียบกับระดับการแยกการทำธุรกรรมที่ตั้งไว้อ่านโดยไม่ได้รับอนุญาต

118

ใครช่วยให้คำแนะนำฉันได้บ้างว่าเมื่อใดที่ฉันควรใช้WITH (NOLOCK)เมื่อเทียบกับSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

ข้อดี / ข้อเสียของแต่ละข้อคืออะไร? มีผลที่ไม่คาดคิดใด ๆ ที่คุณพบเมื่อใช้งานเมื่อเทียบกับผลกระทบอื่น ๆ หรือไม่?

sql sql-server sql-server-2005

— จิมบี
แหล่งที่มา

105

พวกเขาเป็นสิ่งเดียวกัน หากคุณใช้set transaction isolation levelคำสั่งจะใช้กับตารางทั้งหมดในการเชื่อมต่อดังนั้นหากคุณต้องการเพียงnolockหนึ่งหรือสองตารางให้ใช้สิ่งนั้น มิฉะนั้นใช้อื่น ๆ

ทั้งสองอย่างจะทำให้คุณอ่านสกปรก ถ้าคุณโอเคกับสิ่งนั้นก็ใช้มัน หากคุณไม่สามารถอ่านสกปรกได้ให้พิจารณาsnapshotหรือserializableบอกใบ้แทน

— HLGEM
แหล่งที่มา

พิจารณาREPEATABLE READแทนSERIALIZABLEว่าคุณไม่สนใจข้อมูลผี SERIALIZABLEมีข้อ จำกัด จริงๆและแทบไม่ควรใช้เลย (ยกเว้นตัวอย่างเช่นในแอปพลิเคชันทางการเงินที่สำคัญบางอย่าง)

— Kryptos

25

C (NOLOCK) เป็นคำใบ้ในระดับโต๊ะ การตั้งค่าระดับการแยกธุรกรรมเป็น READ_UNCOMMITTED โดยมีผลต่อการเชื่อมต่อ ความแตกต่างอยู่ในแง่ของขอบเขต ดู READUNCOMMITTED และ NOLOCK ในเอกสาร SQL Server ที่นี่:

http://technet.microsoft.com/en-us/library/ms187373.aspx

สำหรับระดับการแยกธุรกรรม: http://technet.microsoft.com/en-us/library/ms173763.aspx

— Anon246
แหล่งที่มา

10

NOLOCK อยู่ในพื้นที่ของตาราง (หรือมุมมอง ฯลฯ )
READ UNCOMMITTED เป็นต่อเซสชัน / การเชื่อมต่อ

สำหรับแนวทาง ... การค้นหาแบบสุ่มจาก StackOverflow และ interweb ไฟฟ้า ...

— GBN
แหล่งที่มา

ลิงค์สุดท้าย "ทำไมใช้ NOLOCK ไม่ดี .. " ไม่มีแล้ว

— Sangam

1

interweb ไฟฟ้าล้ำค่า ขอบคุณที่เพิ่มความสดใสให้กับวันของฉัน

— JJS

9

สำหรับความรู้ของฉันความแตกต่างเพียงอย่างเดียวคือขอบเขตของผลกระทบตามที่ Strommy กล่าว คำใบ้ NOLOCK บนโต๊ะและอ่าน UNCOMMITTED ในเซสชัน

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

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

นอกจากนี้ฉันเชื่อว่าวันนี้คุณควรพิจารณา Multi-version Concurrency Control ฉันเชื่อว่าพวกเขาเพิ่มเข้ามาในปี 2548 และช่วยหยุดนักเขียนจากการปิดกั้นผู้อ่านโดยให้ภาพรวมของฐานข้อมูลแก่ผู้อ่านเพื่อใช้ ฉันจะรวมลิงค์และให้การวิจัยเพิ่มเติมแก่ผู้อ่าน:

MVCC

ระดับการแยกฐานข้อมูล

— Sean Copenhaver
แหล่งที่มา

+1 แม้ว่าฉันจะไม่เข้าใจในแง่มุมของ READ_UNCOMMITTED แต่ Sean ก็ครอบคลุมเรื่องนี้อย่างดีนอกจากนี้ยังมีบางกรณีที่คุณสามารถอ่านแถวเดียวกันสองครั้งใน SQL Server (เนื่องจากการแบ่งหน้า)

— Anon246

6

คุณไม่สามารถใช้ Set Transaction Isolation Level Read Uncommitted in a View (ในความเป็นจริงคุณสามารถมีได้เพียงสคริปต์เดียวเท่านั้น) ดังนั้นคุณจะต้องใช้ (nolock) หากควรรวมแถวสกปรก

— Rez.Net
แหล่งที่มา

4

เนื่องจากคุณต้องใช้ด้วย (NOLOCK) สำหรับแต่ละตารางอาจเป็นเรื่องที่น่ารำคาญหากต้องเขียนในทุก ๆ ประโยค FROM หรือ JOIN อย่างไรก็ตามมันมีเหตุผลว่าทำไมจึงเรียกว่าการอ่าน "สกปรก" ดังนั้นคุณควรทราบเมื่อคุณทำอย่างใดอย่างหนึ่งและอย่าตั้งเป็นค่าเริ่มต้นสำหรับขอบเขตเซสชัน ทำไม?

การลืม C (NOLOCK) อาจไม่ส่งผลกระทบต่อโปรแกรมของคุณอย่างมาก แต่การอ่านสกปรกโดยที่คุณไม่ต้องการให้ใครสามารถสร้างความแตกต่างได้ในบางสถานการณ์

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

— อเล็กซ์
แหล่งที่มา