Menggunakan ukuran kolom jauh lebih besar dari yang diperlukan


16

Saya membuat database SQL Server dengan orang lain. Salah satu tabel adalah kecil (6 baris) dengan data yang mungkin akan tetap konstan. Ada kemungkinan jarak jauh bahwa baris baru akan ditambahkan. Tabelnya terlihat seperti ini:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Saya melihat panjang karakter namekolom itu, dan saya pikir nilainya mungkin tidak akan pernah lebih besar dari, katakanlah, 32 karakter, bahkan mungkin tidak lebih besar dari 24. Apakah ada keuntungan untuk mengubah kolom ini menjadi, misalnya varchar(32),?

Juga, apakah ada keuntungan menjaga ukuran kolom default menjadi kelipatan 4, 8, 32, dll?

Jawaban:


15

SQL Server menggunakan panjang kolom ketika mengalokasikan memori untuk pemrosesan permintaan. Jadi, ya, singkatnya, Anda harus selalu mengukur kolom dengan tepat untuk data.

Alokasi memori didasarkan pada jumlah baris yang dikembalikan oleh kueri dikalikan setengah dari panjang kolom yang dinyatakan.

Karena itu, dalam hal ini di mana Anda memiliki 6 baris Anda mungkin tidak ingin lebih mengoptimalkan secara prematur. Kecuali Anda GABUNG tabel ini ke yang lain dengan jutaan baris, tidak akan ada perbedaan besar antara varchar (24) dan varchar (32), atau bahkan varchar (128).

Pertanyaan kedua Anda bertanya tentang menyelaraskan panjang kolom pada kelipatan biner. Itu tidak diperlukan sama sekali karena SQL Server menyimpan semua data di halaman 8KB, terlepas dari panjang setiap kolom.


14

Dengan 6 baris, tidak, tidak akan ada manfaat yang bisa diamati. Seluruh tabel itu akan muat pada satu halaman sehingga menurunkan ruang potensial maksimum yang akan Anda gunakan pada halaman itu sementara masih menempati seluruh halaman itu benar-benar tidak berbeda dalam semua arti praktisnya.

Namun, pada tabel yang lebih besar, ukuran kanan sangat penting. Alasannya adalah bahwa estimasi memori akan didasarkan pada asumsi bahwa setiap nilai akan diisi 50%. Jadi jika Anda memiliki varchar (128), setiap nilai akan diharapkan untuk menempati 64 byte, terlepas dari data aktual, oleh karena itu memori yang diberikan adalah 64b * jumlah baris. Jika semua nilai akan 32 karakter atau kurang, menjadikannya varchar (64) atau bahkan varchar (32) mungkin merupakan pilihan yang lebih baik. Jika sebagian besar nilai mendekati atau mendekati batas, Anda bahkan bisa berdebat agar char mengeluarkan volatilitas darinya.

Adapun manfaat memiliki panjang tali dibatasi pada kekuatan 2, saya tidak berpikir pada perangkat keras hari ini siapa pun dapat menunjukkan keunggulan yang jelas.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.