ผลของการตั้งค่า varchar (8000) คืออะไร?

22

เนื่องจาก varchar ใช้พื้นที่ดิสก์ตามสัดส่วนกับขนาดของเขตข้อมูลมีเหตุผลใดที่เราไม่ควรกำหนด varchar เป็นค่าสูงสุดเสมอเช่นvarchar(8000)ใน SQL Server

บนโต๊ะสร้างถ้าฉันเห็นใครทำvarchar(100)ฉันควรบอกพวกเขาไม่ผิดคุณควรทำvarchar(8000)อย่างไร

sql-server varchar

— Aleksandr Levchuk
แหล่งที่มา

ฉันคิดว่าเราต้องแยกความแตกต่างระหว่างการใช้งานในการสร้างตารางและใช้ในการประกาศพารามิเตอร์ของกระบวนงานที่เก็บไว้ สำหรับการตีความครั้งที่สองโปรดดูคำถามของฉันdba.stackexchange.com/questions/1772/…

— bernd_k

18

ความยาวเป็นข้อ จำกัด ของข้อมูล (เช่น CHECK, FK, NULL เป็นต้น)
ประสิทธิภาพการทำงานเมื่อแถวเกิน 8060 ไบต์
ต้องไม่มีข้อ จำกัด หรือดัชนีที่ไม่ซ้ำกัน (ความกว้างคอลัมน์คีย์ต้อง <900)
ค่าเริ่มต้นคือ SET ANSI PADDING ON = เป็นไปได้สำหรับพื้นที่ต่อท้ายจำนวนมากที่จะถูกเก็บไว้
SQL Server จะถือว่าความยาวเฉลี่ยอยู่ที่ 4,000 สำหรับการดำเนินการเรียงลำดับการจัดสรรหน่วยความจำตามนี้ (จำเป็นต้องค้นหาลิงก์เพื่อสำรองข้อมูลนี้ แต่ทำให้เป็นสนิมในขณะที่ฉันทำ :-)

สรุป: อย่าทำมัน

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

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

— bernd_k

@bernd_k: 8060 = จำนวนข้อมูลมากที่สุดสำหรับหนึ่งแถวที่พอดีกับหน้า 8192 หน้าเดียว รวมถึงค่าใช้จ่ายในแถว ส่วนที่เหลือ (132 ไบต์) = ค่าใช้จ่ายในหน้า

— gbn

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

— bernd_k

@bernd_k: การลดลงของประสิทธิภาพใด ๆ เกิดขึ้นจาก 1. การจัดสรรหน่วยความจำสำหรับการเรียงลำดับ ฯลฯ 2. การโอเวอร์โฟลว์แถว (> 8060 ไบต์) ความเป็นจริงของการมี 10 ตัวอักษรในแต่ละ varchar (8000) ไม่เกี่ยวข้องจนกว่าจะตรงตามเงื่อนไขเหล่านี้ (SQL จะเตือนเกี่ยวกับข้อผิดพลาดที่อาจเกิดขึ้นในภายหลังสำหรับคีย์ดัชนี)

— gbn

การเรียงลำดับตารางด้วยคอลัมน์ varchar (100) เต็มไปด้วยเขตข้อมูลที่มีความยาว 100 ไบต์คุ้มค่ากับคำถามอื่นเนื่องจากการเรียงลำดับจะถือว่ามีค่าเฉลี่ย 50 อักขระหรือไม่

— bernd_k

7

สมมติว่าคุณกำลังอ้างถึง SQL Server ฉันสามารถคิดได้

มีการ จำกัด ขนาด (8K) ของแถวในตารางและ SQL ช่วยให้คุณกำหนดเขตข้อมูล varchar ที่ในทางทฤษฎีอาจเกินขีด จำกัด นั้น ดังนั้นผู้ใช้อาจได้รับข้อผิดพลาดหากพวกเขาใส่ข้อมูลมากเกินไปในฟิลด์ที่เกี่ยวข้อง

เริ่มต้นด้วย SQL 2K8 คุณสามารถเกินขีด จำกัด นี้ แต่มีผลกระทบต่อประสิทธิภาพการทำงาน

นอกจากนี้ยังมีการตรวจสอบความสมเหตุสมผลทั้งหมดของการ จำกัด ขนาดของสิ่งที่คุณคาดหวังว่าข้อมูลจะเป็นอย่างไร หากคุณต้องการฟิลด์ความยาวไม่ จำกัด ทำไมไม่ไปกับข้อความหรือ ntext?

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

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

— ชาด

ประเภทเหล่านั้นไม่ได้มีส่วนร่วมกับขีด จำกัด ขนาดแถวสูงสุด 8K ในตารางเนื่องจากข้อมูลจริงจะถูกเก็บไว้ในตารางแยกต่างหากภายใต้ฝาครอบแทนที่จะเป็นแบบอินไลน์กับคอลัมน์ที่เหลือ ยังคงมีผลกระทบต่อประสิทธิภาพ แต่ด้วยเหตุผลที่แตกต่างกัน นอกจากนี้ยังมีข้อ จำกัด ในการสนับสนุนคุณสมบัติในสาขาเหล่านี้เมื่อเทียบกับ varchar และ nvarchar

— JohnFx

ข้อความและ ntext ถูกคัดค้าน varchar (สูงสุด)

— ฟิลเฮลเมอ

3

แน่นอนมันขึ้นอยู่กับข้อมูลที่ถูกเก็บไว้ในเขต?

บางสิ่งจะมีความยาวสูงสุดด้วยเหตุผลหลายประการและหากจะต้องมีความยาวสูงสุดนั่นก็ควรจะเป็นความยาวของสนาม

หากในทางทฤษฎีไม่มีความยาวสูงสุดฉันจะถามว่าทำไมถึงใช้ varchar

— โทบี้
แหล่งที่มา

3

ฉันบริบทของฐานข้อมูล Oracle ฉันได้เรียนรู้ว่าการใช้ขนาดเขตข้อมูลที่เล็กที่สุดสำหรับคอลัมน์ฐานข้อมูลมักมีข้อผิดพลาดหนึ่งข้อ

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

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

มี 20% - 100% ฟิลด์ที่ไม่ได้ใช้ด้วยเป็นตัวเลือกที่อภิปรายได้ที่นี่

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