คอลัมน์ยาวส่งผลกระทบต่อประสิทธิภาพและการใช้งานดิสก์อย่างไร


26

ในโครงการปัจจุบันของเรามันเกิดขึ้นบ่อยเกินไปที่เราต้องขยายคอลัมน์ด้วยตัวละครสองสามตัว จากvarchar(20)ไปvarchar(30)เรื่อย ๆ

ในความเป็นจริงมันมีความสำคัญมากแค่ไหน? สิ่งนี้ดีเพียงใด ผลกระทบของการอนุญาตเพียงแค่ 100 หรือ 200 หรือแม้กระทั่ง 500 ตัวอักษรสำหรับช่อง "อินพุต" ปกติคืออะไร อีเมลสามารถมีได้เพียง 320 ตัวอักษรดังนั้นตกลง - มีข้อ จำกัด ที่ดี แต่สิ่งที่ฉันจะได้รับถ้าฉันตั้งไว้ที่ 200 เพราะฉันไม่ได้คาดหวังที่อยู่อีเมลนานกว่านั้น

โดยปกติตารางของเราจะไม่มีแถวมากกว่า 100,000 แถวและมีคอลัมน์มากถึง 20 หรือ 30 คอลัมน์

เราใช้ SQL Server 2008 ตอนนี้ แต่มันน่าสนใจที่จะทราบว่า DBs ต่างกันจัดการกับปัญหานี้อย่างไร

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

ในกรณีที่เป็นฉันอยู่ที่นี่เพื่อเรียนรู้ :-)

คำตอบ:


12

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

การจัดรูปแบบ เครื่องมือไคลเอ็นต์ใด ๆ ที่จัดรูปแบบข้อมูลตามขนาดของเขตข้อมูลจะต้องพิจารณาการจัดรูปแบบพิเศษ ตัวอย่าง SQL * Plus ของ Oracle โดยค่าเริ่มต้นจะแสดงขนาดสูงสุดของคอลัมน์ Varchar2 แม้ว่าข้อมูลจะมีความยาวเพียงหนึ่งอักขระเท่านั้น เปรียบเทียบ…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

ความยาวฟิลด์ข้อมูลไม่ถูกต้องเป็นกลไกเพิ่มเติมในการตรวจจับ / ป้องกันข้อมูลที่ไม่ดี อินเทอร์เฟซไม่ควรพยายามแทรก 3000 อักขระลงในเขตข้อมูล 100 ตัวอักษร แต่ถ้าเขตข้อมูลนั้นถูกกำหนดให้เป็น 4000 ตัวอักษรก็อาจจะ ข้อผิดพลาดจะไม่ถูกดักจับในขั้นตอนการป้อนข้อมูล แต่ระบบอาจมีปัญหามากขึ้นเมื่อแอปพลิเคชันอื่นพยายามประมวลผลข้อมูลและทำให้หายใจไม่ออก ตัวอย่างเช่นหากคุณตัดสินใจจัดทำดัชนีฟิลด์ใน Oracle ในภายหลังคุณจะเกินความยาวสูงสุดของคีย์สูงสุด (ขึ้นอยู่กับขนาดบล็อกและการต่อข้อมูล) ดู…

create index i1 on f1(a);

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

เอกสาร ขนาดของสนามให้จุดข้อมูลอื่นของเอกสารเกี่ยวกับข้อมูล เราสามารถเรียกตารางทั้งหมด t1, t2, t3, และฟิลด์ทั้งหมด f1, f2, f3 และอื่น ๆ ได้ แต่โดยการระบุชื่อที่มีความหมายเราจะเข้าใจข้อมูลได้ดีขึ้น ตัวอย่างเช่นหากตารางที่อยู่สำหรับ บริษัท ที่มีลูกค้าในสหรัฐอเมริกามีเขตข้อมูลที่เรียกว่าสถานะซึ่งเป็นอักขระสองตัวเราคาดว่าตัวย่อสถานะของอักขระสองตัวจะอยู่ในนั้น ในทางกลับกันถ้าเขตข้อมูลเป็นหนึ่งร้อยตัวอักษรเราอาจคาดหวังว่าชื่อรัฐเต็มไปในสนาม


ทุกอย่างที่กล่าวมาดูเหมือนจะรอบคอบเพื่อเตรียมพร้อมสำหรับการเปลี่ยนแปลง เพียงเพราะชื่อผลิตภัณฑ์ทั้งหมดของคุณในวันนี้พอดีกับ 20 ตัวอักษรไม่ได้หมายความว่าพวกเขาจะเสมอ อย่าไปลงน้ำและทำให้ครบ 1,000 แต่อย่าออกจากห้องเพื่อการขยายที่น่าเชื่อถือ


ดูยังstackoverflow.com/questions/1882073/...
Leigh Riffel

เอกสารเป็นสิ่งที่ดีที่คุณเพิ่มที่นี่ซึ่งฉันไม่ได้เห็นที่อื่น
jeteon

9

นี่คือจุดเริ่มต้นที่ดีสำหรับคุณ

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

ฉันอาจเข้าใจผิดคำถามเดิมของคุณ ให้ฉันดูว่าฉันจะหาลิงค์อื่นให้คุณอ้างอิงได้ไหม

นี่คือการอ้างอิงที่ดีเกี่ยวกับการเลือกประเภทข้อมูล: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

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

นี่คือลิงค์สำหรับโครงสร้างฐานข้อมูล: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

นี่คือส่วนหนึ่งสำหรับการแยกหน้าและการบันทึก trx: http://sqlskills.com/BLOGS/PAUL/post/How- ราคา -are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

ฉันคิดว่าฉันจะแบ่งปันประเด็นที่น่าสนใจซึ่งฉันพบในคำถาม SO ต่อไปนี้:

https://stackoverflow.com/questions/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

คำตอบเดิมโดย: Nick Kavadias

เหตุผลที่จะไม่ใช้เขตข้อมูลสูงสุดหรือเขตข้อมูลข้อความคือคุณไม่สามารถดำเนินการ [ดัชนีออนไลน์สร้างใหม่] [1] เช่นสร้างใหม่ด้วย ONLINE = ON แม้ใน SQL Server Enterprise Edition

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "ดัชนีออนไลน์สร้างใหม่"

ฉันจะถือว่านี่เป็นข้อเสียใหญ่เมื่อเพิ่มคอลัมน์ n / varchar (สูงสุด) โดยพลการและตามเว็บไซต์ MS ข้อ จำกัด นี้กับการทำดัชนีออนไลน์สร้างใหม่ยังคงอยู่ใน SQL Server 2008, 2008 R2 และ Denali; ดังนั้นจึงไม่เฉพาะกับ SQL Server 2005

ขอบคุณเจฟ


6

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

ฉันพบงานนำเสนอที่ SQLWorkshops.com คิดว่าเป็นการยั่วยุงานนำเสนอนี้พูดถึงกรณีที่มีการเรียงลำดับสำหรับการสั่งซื้อโดยกระจายลงใน tempdb เพราะหน่วยความจำไม่เพียงพอที่จะถูกจัดสรรสำหรับเขตข้อมูล char / varchar

http://webcasts2.sqlworkshops.com/webcasts.asp

เว็บคาสต์นี้ถูกนำเสนอเป็นบทความในเว็บไซต์ต่อไปนี้:

http://www.mssqltips.com/tip.asp?tip=1955

หมายเหตุในงานนำเสนอนี้ว่าคอลัมน์ที่เรียงลำดับนั้นไม่ใช่คอลัมน์ char / varchar แต่จำนวนพื้นที่ที่จัดสรรสำหรับคอลัมน์ varchar ในหน่วยความจำสร้างความแตกต่างในประสิทธิภาพการค้นหาในบางกรณี


4

ตั้งค่า ANSI_PADDING ON หรือไม่

คุณท้ายด้วยช่องว่างต่อท้ายจำนวนมาก ...


3

มันเกี่ยวข้องกับพื้นที่ดิสก์และความยาวอักขระเท่านั้น แน่นอนว่าการค้นหาชนิดข้อมูลถ่านและดัชนีของข้อมูลประเภทนี้จะทำงานช้ากว่าจำนวนเต็ม แต่นี่เป็นการอภิปรายอีกครั้ง

ชนิดข้อมูล Varchar เป็นชนิดข้อมูล "ตัวแปร" ดังนั้นหากคุณตั้งค่าขีด จำกัด ของ varchar (500) กว่านี้จะมีความยาวอักขระสูงสุดสำหรับฟิลด์นั้น ความยาวขั้นต่ำสามารถอยู่ระหว่าง 0 ถึง 500 ในทางกลับกันพื้นที่ดิสก์ที่อ้างสิทธิ์จะแตกต่างกันสำหรับฟิลด์อักขระ 10, 30 หรือ 500

บางครั้งฉันทำการทดสอบสำหรับประเภทข้อมูล varchar (800) และสำหรับค่า Null ฉันมีการใช้ 17 ไบต์และสำหรับอักขระแต่ละตัวที่ใส่เข้าไปก็เพิ่มอีกหนึ่งไบต์ ตัวอย่างเช่นสตริง 400 อักขระมี 417 ไบต์ที่ใช้บนดิสก์


3

ฉันไม่คิดว่ามีความแตกต่างระหว่างตารางที่สร้างด้วยคอลัมน์ของ varchar (20) หรือ varchar ((8000) ตราบใดที่ความยาวสูงสุดที่แท้จริงคือ <= 20

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.