SQL Server VARCHAR ความกว้างคอลัมน์

ฉันพบคำแนะนำที่ขัดแย้งกันว่ามีผลกระทบต่อประสิทธิภาพการทำงานหรือไม่เมื่อระบุคอลัมน์ VARCHAR กว้างเกินไปเช่น VARCHAR (255) เมื่อ VARCHAR (30) อาจทำ

ฉันเห็นข้อตกลงอย่างสม่ำเสมอว่ามีการดำเนินการอย่างต่อเนื่องหากทั้งแถวเกินกว่า 8060 ไบต์ นอกจากนั้นฉันเห็นความไม่ลงรอยกัน

การอ้างสิทธิ์เป็นจริงThe default is SET ANSI PADDING ON = potential for lots of trailing spacesหรือไม่ ตราบใดที่ความกว้างแถวรวมน้อยกว่า 8060 มีความกังวลเกี่ยวกับประสิทธิภาพที่แท้จริงในคอลัมน์ VARCHAR ที่มีขนาดใหญ่เกินไปหรือไม่?

หลักฐานที่แสดงความกว้างของคอลัมน์นั้นสำคัญ

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

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

หลักฐานที่แสดงว่าความกว้างของคอลัมน์ไม่สำคัญ

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

คำถามอาจระบุไว้ดีกว่าเป็น:

"ประโยชน์ของการระบุความยาวสูงสุดของคอลัมน์ที่มีความยาวมากเกินไปคืออะไร"

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

ในบางกรณีที่ความยาวเฉลี่ยของคอลัมน์นั้นสูงกว่า 50% ที่สันนิษฐานโดย SQL Server อย่างมีนัยสำคัญเมื่อคำนวณการจัดเรียง / แฮชหน่วยความจำให้สิทธิ์คุณอาจเห็นการปรับปรุงประสิทธิภาพโดยการระบุความยาวสูงสุด นี่เป็นวิธีแก้ปัญหาที่น่าสงสัยและควรใช้โดยชัดแจ้งCASTหรือCONVERT(พร้อมความคิดเห็น!) แทนการเปลี่ยนคำจำกัดความของคอลัมน์ฐาน บางครั้งมันจะดีกว่าที่จะเขียนแบบสอบถามเพื่อจัดเรียงคีย์แทนทั้งแถวต่อไป

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

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

ตามที่คุณระบุตราบใดที่ขนาดแถวไม่เกิน 8060 (หรือจำนวนสูงสุดที่ตั้งไว้) จะไม่มีความแตกต่างด้านประสิทธิภาพในการใช้ VARCHAR (30) หรือ VARCHAR (255) หรือใหญ่กว่า การเปรียบเทียบ CHAR to VARCHAR จากบทความที่เชื่อมโยงนั้นไม่เกี่ยวข้องกันจริงๆ แม้ว่าฉันเห็นด้วยคุณไม่ควรระบุพื้นที่มากกว่าที่คุณต้องการ แต่ในหลาย ๆ กรณีคุณไม่ทราบว่าต้องใช้พื้นที่เท่าใด ดังนั้นจงเสรีกับ VARCHAR space - ฉันค่อนข้างแน่ใจว่าการเพิ่มขนาดของฟิลด์ต้องมีการสร้างตารางใหม่ในขณะที่การลดลงเป็นคำสั่ง ALTER TABLE ง่ายๆ