ทำไมผู้คนถึงเกลียดเคอร์เซอร์ SQL มาก? [ปิด]

"ค่าใช้จ่าย" ที่มีเคอร์เซอร์เป็นเพียงส่วนหนึ่งของ API เคอร์เซอร์คือการทำงานของส่วนต่างๆ ของ RDBMS ภายใต้ประทุน บ่อยครั้งที่ CREATE TABLE และ INSERT มีคำสั่ง SELECT และการนำไปใช้งานก็คือการใช้เคอร์เซอร์ภายในที่ชัดเจน

การใช้ "ตัวดำเนินการตามชุด" ระดับที่สูงกว่าจะรวมผลลัพธ์ของเคอร์เซอร์ไว้ในชุดผลลัพธ์ชุดเดียว ซึ่งหมายความว่า API ไปมาน้อยลง

เคอร์เซอร์เกิดขึ้นก่อนภาษาสมัยใหม่ซึ่งมีคอลเลกชันชั้นหนึ่ง Old C, COBOL, Fortran ฯลฯ ต้องประมวลผลแถวทีละแถว เนื่องจากไม่มีแนวคิดเรื่อง "การรวบรวม" ที่สามารถนำมาใช้กันอย่างแพร่หลาย Java, C#, Python ฯลฯ มีโครงสร้างรายการระดับเฟิร์สคลาสเพื่อเก็บชุดผลลัพธ์

ปัญหาที่ช้า

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

เขียน SQL อย่างง่ายเพื่อแทนที่ลูปเคอร์เซอร์ที่ซ้อนกันด้วยการรวม และเคอร์เซอร์แบบแบนเดี่ยวสามารถทำให้โปรแกรมรันในครั้งที่ 100 [พวกเขาคิดว่าฉันเป็นเทพแห่งการเพิ่มประสิทธิภาพ ทั้งหมดที่ฉันทำคือแทนที่ลูปที่ซ้อนกันด้วยการรวม ยังคงใช้เคอร์เซอร์อยู่]

ความสับสนนี้มักนำไปสู่การฟ้องร้องเคอร์เซอร์ อย่างไรก็ตาม ปัญหาไม่ใช่เคอร์เซอร์ แต่เป็นการใช้เคอร์เซอร์ในทางที่ผิดนั่นเอง

ปัญหาขนาด

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

ทางเลือก

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

เคอร์เซอร์ทำให้ผู้คนใช้กรอบความคิดแบบขั้นตอนมากเกินไปกับสภาพแวดล้อมที่ถูกกำหนดไว้

และพวกมันช้า!!!

จาก SQLTeam:

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

มีคำตอบด้านบนที่ระบุว่า "เคอร์เซอร์เป็นวิธีที่ช้าที่สุดในการเข้าถึงข้อมูลภายใน SQL Server ... เคอร์เซอร์ช้ากว่าทางเลือกอื่นที่ตั้งค่าไว้มากกว่าสามสิบเท่า"

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

ในกรณีที่ไม่มีกิจกรรมฐานข้อมูลอื่นๆ การดำเนินการตามการตั้งค่าจะเร็วขึ้นในระดับสากล ในระบบการผลิตก็ขึ้นอยู่กับ

เคอร์เซอร์มีแนวโน้มที่จะถูกใช้โดยผู้เริ่มต้นนักพัฒนา SQL ในตำแหน่งที่การดำเนินการตามการตั้งค่าจะดีกว่า โดยเฉพาะอย่างยิ่งเมื่อผู้คนเรียนรู้ SQL หลังจากเรียนรู้ภาษาการเขียนโปรแกรมแบบดั้งเดิม แนวคิด "วนซ้ำบันทึกเหล่านี้" มีแนวโน้มที่จะทำให้ผู้คนใช้เคอร์เซอร์อย่างไม่เหมาะสม

หนังสือ SQL ที่ร้ายแรงที่สุดมีบทที่ห้ามใช้เคอร์เซอร์ สิ่งที่เขียนอย่างดีทำให้ชัดเจนว่าเคอร์เซอร์มีตำแหน่ง แต่ไม่ควรใช้สำหรับการดำเนินการตามการตั้งค่า

มีบางสถานการณ์ที่เคอร์เซอร์เป็นตัวเลือกที่ถูกต้อง หรืออย่างน้อยก็เป็นทางเลือกที่ถูกต้อง

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

ใน Oracle PL/SQL เคอร์เซอร์จะไม่ส่งผลให้ตารางถูกล็อค และคุณสามารถใช้การเก็บรวบรวม/การดึงข้อมูลจำนวนมากได้

ใน Oracle 10 เคอร์เซอร์โดยนัยที่ใช้บ่อย

  for x in (select ....) loop
    --do something 
  end loop;

ดึงข้อมูลครั้งละ 100 แถวโดยปริยาย การรวบรวมจำนวนมาก/การดึงข้อมูลจำนวนมากอย่างชัดเจนก็เป็นไปได้เช่นกัน

อย่างไรก็ตาม เคอร์เซอร์ PL/SQL เป็นทางเลือกสุดท้าย ให้ใช้เคอร์เซอร์เหล่านี้เมื่อคุณไม่สามารถแก้ปัญหาด้วย SQL แบบ set-based ได้

อีกเหตุผลหนึ่งคือการทำให้ขนานกัน มันง่ายกว่าสำหรับฐานข้อมูลในการทำให้คำสั่งตามชุดใหญ่ขนานกันมากกว่าโค้ดที่จำเป็นแบบแถวต่อแถว นี่เป็นเหตุผลเดียวกับว่าทำไมการเขียนโปรแกรมเชิงฟังก์ชันจึงได้รับความนิยมมากขึ้นเรื่อยๆ (Haskell, F#, Lisp, C# LINQ, MapReduce ...) การเขียนโปรแกรมเชิงฟังก์ชันทำให้การทำงานแบบขนานง่ายขึ้น จำนวน CPU ต่อคอมพิวเตอร์เพิ่มขึ้น ดังนั้นการทำงานแบบขนานจึงกลายเป็นปัญหามากขึ้นเรื่อยๆ

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

คำตอบข้างต้นไม่ได้เน้นย้ำถึงความสำคัญของการล็อคมากพอ ฉันไม่ใช่แฟนตัวยงของเคอร์เซอร์เพราะมันมักจะส่งผลให้ระดับตารางล็อค

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

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

คุณสามารถโพสต์ตัวอย่างเคอร์เซอร์นั้นหรือลิงก์ไปยังคำถามได้หรือไม่ อาจมีวิธีที่ดีกว่า CTE แบบเรียกซ้ำ

นอกเหนือจากความคิดเห็นอื่นๆ แล้ว เคอร์เซอร์เมื่อใช้อย่างไม่เหมาะสม (ซึ่งบ่อยครั้ง) จะทำให้เกิดการล็อกหน้า/แถวโดยไม่จำเป็น

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

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

โดยพื้นฐานแล้วโค้ด 2 บล็อกที่ทำสิ่งเดียวกัน อาจเป็นตัวอย่างที่แปลกนิดหน่อย แต่ก็พิสูจน์ประเด็นนี้ได้ เซิร์ฟเวอร์ SQL 2005:

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

การอัปเดตครั้งเดียวใช้เวลา 156 มิลลิวินาที ในขณะที่เคอร์เซอร์ใช้เวลา 2016 มิลลิวินาที