Lebar Kolom SQL Server VARCHAR

Mencari di web, saya telah menemukan saran yang bertentangan tentang apakah ada dampak kinerja ketika menentukan kolom VARCHAR yang terlalu lebar, misalnya VARCHAR (255) ketika VARCHAR (30) mungkin akan melakukannya.

Saya secara konsisten melihat kesepakatan bahwa ada hit kinerja jika seluruh baris melebihi 8.060 byte. Selain itu, saya melihat ketidaksepakatan.

Apakah klaim itu benar The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Selama total lebar baris kurang dari 8060, apakah ada kekhawatiran kinerja nyata dalam ukuran kolom VARCHAR yang terlalu besar?

Bukti bahwa lebar kolom penting

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

Apa konsekuensi dari pengaturan varchar (8000)?

Bukti bahwa lebar kolom TIDAK masalah

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

Pertanyaannya mungkin lebih baik dinyatakan sebagai:

"Apa keuntungan dari menspesifikasikan secara berlebihan panjang maksimum kolom panjang variabel?"

Secara umum, ada sedikit keuntungan, dan beberapa kelemahan sebagai berbagai jawaban terkait menunjukkan. Selain dari keprihatinan lain, pertimbangkan bahwa SQL Server bukan open-source: ada banyak 'angka ajaib' dan heuristik yang diterapkan berdasarkan informasi yang disediakan untuk sistem. Tanpa akses kode sumber, kita tidak pernah bisa sepenuhnya yakin apa dampak dari praktik ini.

Dalam beberapa kasus , di mana panjang rata-rata kolom secara signifikan lebih tinggi dari 50% yang diasumsikan oleh SQL Server saat menghitung hibah memori sort / hash, Anda mungkin melihat peningkatan kinerja dengan menentukan panjang maksimum secara berlebihan. Ini adalah solusi yang meragukan , dan mungkin seharusnya hanya diterapkan secara eksplisit CASTatau CONVERT(dengan komentar!) Daripada mengubah definisi kolom dasar. Terkadang, akan lebih baik untuk menulis ulang kueri untuk mengurutkan kunci alih-alih seluruh baris.

Jika ukuran baris maksimum mungkin melebihi batas baris (bahkan jika tidak ada baris yang benar-benar melakukannya), menghapus baris dapat menyebabkan pemisahan halaman yang tidak terduga jika ada pemicu. Pembaruan juga dapat menyebabkan fragmentasi melalui mekanisme yang sama.

SQL Server melakukan pekerjaan yang cukup baik dalam banyak kasus di mana disediakan dengan informasi metadata yang baik dan akurat. Mengompromikan prinsip ini untuk 'kenyamanan' tampaknya tidak bijaksana bagi saya. Pendekatan yang masuk akal adalah memilih nilai panjang maksimum yang masuk akal sesuai dengan data aktual yang akan disimpan, dan segala perubahan yang dapat diperkirakan.

Seperti yang Anda sebutkan, selama ukuran baris tidak melebihi 8060 (atau berapa pun maksimum yang diatur ke), tidak ada perbedaan kinerja dalam menggunakan VARCHAR (30) atau VARCHAR (255) atau lebih besar. Perbandingan CHAR ke VARCHAR dari artikel yang ditautkan tidak benar-benar relevan. Meskipun saya setuju Anda tidak boleh menentukan lebih banyak ruang daripada yang Anda yakin perlu, dalam banyak kasus Anda tidak tahu seberapa banyak ruang yang sebenarnya Anda perlukan. Jadi bersikap liberal dengan ruang VARCHAR - Saya cukup yakin meningkatkan ukuran bidang memerlukan tabel membangun kembali, sementara penurunan adalah pernyataan ALTER TABLE sederhana.