Astaga, Anda punya banyak pertanyaan di sini. Mari kita hancurkan ini.
T: Apakah SQL "memindahkan" baris yang ada untuk mempertahankan pengelompokan, atau akan membiarkan tabel menjadi "terfragmentasi"?
Pikirkan sebuah basis data sebagai kumpulan halaman - potongan kertas literal yang diletakkan di meja Anda. Pikirkan kamus untuk saat ini. Jika Anda ingin menambahkan lebih banyak kata ke kamus, Anda dapat menambahkannya di tempat jika halaman memiliki ruang kosong.
Saat pertama kali memulai dengan kamus kosong, ini relatif mudah. Tetapi pikirkan kamus dewasa dengan ribuan halaman kertas di dalamnya, semuanya penuh.
Saat Anda ingin menambahkan lebih banyak kata ke kamus dewasa itu, kemungkinan besar tidak akan ada ruang tersisa di halaman. SQL Server akan "merobek" halaman - ia akan membawa halaman baru di tempat lain, dan memindahkan beberapa kata ke halaman baru itu. Halaman baru akan berada di akhir kamus. Berita baiknya adalah segera setelah tindakan itu, sekarang ada halaman yang setengah kosong di akhir kamus Anda, dan juga di tengah, keduanya dengan ruang untuk menambahkan kata-kata.
Jika Anda menambahkannya dalam urutan itu, itu adalah. (Inilah mengapa cara Anda memuat data menjadi semakin penting.)
Apakah ini dapat menyebabkan kinerja yang besar jika impor dilakukan satu per satu?
Lupakan indeks selama satu detik - menambahkan data satu baris pada satu waktu sama sekali tidak efisien terlepas dari struktur indeks. SQL Server adalah sistem berbasis set - kapan pun Anda dapat bekerja dalam set, Anda mungkin harus melakukannya.
Apa yang terjadi ketika saya meminta data?
Anda tidak menanyakan ini, tapi saya memintanya untuk Anda, hahaha.
Pikirkan kembali tentang akibat dari sisipan kita. Sekarang kita punya kamus yang sebagian besar dipesan, tetapi ketika Anda sampai ke beberapa titik kamus, Anda harus melompat ke belakang untuk membaca dari beberapa halaman lain. Jika semua halaman ini di-cache dalam memori Anda (RAM, buffer pool, dll) maka overhead tidak akan sebesar itu. Sebagian besar akses memori adalah acak - tidak seperti SQL Server menyimpan kamus Anda dalam memori secara berurutan.
Di sisi lain, jika Anda perlu mengambil data dari hard drive magnetik konvensional (karat berputar), maka Anda bisa mendapatkan sedikit manfaat kinerja jika data tersebut disimpan secara berurutan. Tujuan desain sebenarnya di sini, adalah untuk mendapatkan data dari RAM alih-alih mendapatkannya dari drive. Perbedaan antara defragmented data pada disk versus data terfragmentasi pada disk sama sekali tidak sepenting perbedaan antara mendapatkannya dari disk versus mendapatkannya dari RAM .
Haruskah saya lebih suka tidak repot dengan pemesanan baris dan hanya menambahkan kolom identitas sebagai kunci utama dan indeks pada kolom Tanggal untuk membantu dengan pertanyaan saya?
Bingo: ini adalah perbedaan antara desain database fisik dan desain database logis. Programmer harus khawatir banyak tentang desain database fisik pada awalnya, tetapi selama database Anda di bawah, katakanlah, ukuran 100GB, Anda dapat memperbaiki desain logis dalam posting, sehingga untuk berbicara. Letakkan bidang identitas di sana sebagai permulaan, klaster di atasnya, dan kemudian setelah ditayangkan selama beberapa bulan, kunjungi kembali desain indeks untuk memaksimalkan kinerja.
Sekarang, setelah mengatakan itu, setelah Anda berpengalaman dengan jenis pengambilan keputusan ini, maka Anda akan lebih siap untuk menebak indeks angka sejak awal. Meski begitu, saya bahkan tidak terlalu memikirkan desain indeks pada awalnya. Pengguna sepertinya tidak pernah menanyakan data seperti yang saya harapkan.
