Membandingkan SQL collations untuk Windows collations

Microsoft SQL Server 2000 dan Microsoft SQL Server 2005, "pemeriksaan" menentukan bagaimana string yang dibandingkan dan diurutkan, dan karakter set yang digunakan untuk non-Unicode data. SQL Server 2000 mendukung dua jenis collations:

• SQL collations
• Windows collations

Untuk keterangan setiap jenis pemeriksaan dan yang baik Ikhtisar bagaimana memutuskan pemeriksaan yang digunakan, lihat topik "Memilih Collations" dalam SQL Server 2000 buku Online, atau baca topik "Pemeriksaan jenis" dalam SQL Server 2005 buku Online.

Artikel ini membahas pertimbangan tambahan yang dapat mempengaruhi Anda keputusan tentang apakah akan memilih pemeriksaan Windows atau pemeriksaan SQL ketika Anda menginstal SQL Server 2000 atau SQL Server 2005.

Pemeriksaan semantik

Untuk pemeriksaan Windows, perbandingan data non-Unicode adalah dilaksanakan dengan menggunakan algoritma yang sama sebagai Unicode data. Kedua Unicode dan non-Unicode menyortir kompatibel dengan string perbandingan aturan khususnya Versi Windows. Ini menyediakan konsistensi di seluruh tipe data dalam SQL Server. Hal ini juga memungkinkan pengembang yang menggunakan CompareString Win32 API fungsi untuk menyortir string dalam aplikasi mereka dengan menggunakan aturan yang sama yang menggunakan SQL Server.

Dalam pemeriksaan SQL, SQL Server mendefinisikan berbeda perbandingan semantik non-Unicode data. SQL Server basis ini perbandingan semantik pada SQL "sort order." Untuk pemetaan Urutkan pesanan untuk SQL collations, lihat topik "SQL pemeriksaan nama" dalam SQL Server buku Online.

Pemeriksaan SQL aturan untuk menyortir data non-Unicode tidak kompatibel dengan semacam rutinitas yang disediakan oleh Microsoft Windows sistem operasi; Namun, menyortir Unicode data kompatibel dengan Versi tertentu dari Windows menyortir aturan. Karena aturan perbandingan untuk non-Unicode dan Unicode data berbeda, ketika Anda menggunakan SQL pemeriksaan Anda mungkin akan melihat hasil yang berbeda untuk perbandingan karakter yang sama, tergantung pada jenis data yang mendasarinya. Sebagai contoh, jika Anda menggunakan SQL pemeriksaan "SQL_Latin1_General_CP1_CI_AS", non-Unicode string 'a-c' adalah kurang daripada string 'ab' karena tanda hubung ("-") yang diurutkan sebagai karakter tambahan yang datang sebelum "b". Namun, jika Anda mengkonversi string ini untuk Unicode dan Anda melakukan perbandingan sama, string Unicode N'a-c' dianggap lebih dari N'ab' karena Unicode menyortir aturan menggunakan "kata semacam" yang mengabaikan tanda hubung.

String membandingkan kinerja

Unicode menyortir aturan jauh lebih kompleks daripada aturan untuk urutan non - Unicode SQL. Ketika SQL Server membandingkan Unicode data, karakter ditugaskan berat yang secara dinamis diubah berdasarkan pemeriksaan 's lokal. Data yang juga diubah dengan perbandingan gaya pengaturan seperti lebar, aksen, atau Kana-kepekaan. Unicode semacam rutinitas mendukung lebih cerdas semacam perilaku seperti kata penyortiran.

Selain itu, karena rutinitas harus menangani Unicode data, mereka sudah cukup fleksibel untuk menangani penyortiran dan perbandingan dari beberapa ribu karakter yang berbeda, bukan dari maksimal 255 karakter yang paling SQL Server semacam perintah dapat menangani. Untuk alasan ini, perbandingan string mentah pekerjaan yang menggunakan Unicode menyortir aturan ini biasanya lebih mahal dalam istilah waktu dan siklus CPU daripada perbandingan string serupa yang menggunakan urutan non - Unicode SQL.

Apa artinya ini untuk kemungkinan kombinasi dari tipe data dan pemeriksaan jenis dalam SQL Server:

• Jika Anda menyimpan dan penanganan data Anda dengan menggunakan non-Unicode data jenis)char, varchar, teks), dan Anda menggunakan SQL pemeriksaan, perbandingan string akan dilakukan dengan urutan non - Unicode SQL.
• Jika Anda menyimpan dan penanganan data Anda dengan menggunakan non-Unicode data jenis)char, varchar, teks), dan Anda menggunakan Windows pemeriksaan, perbandingan string akan dilakukan dengan Unicode menyortir aturan. Ini dapat menyebabkan operasi tertentu sangat bergantung pada string sorting kinerja lebih lama dan untuk menggunakan CPU lebih daripada operasi serupa yang dilakukan dengan SQL pemeriksaan.
• Jika Anda menggunakan Unicode data jenis)nchar, nvarchar, ntext), tidak ada perbedaan dalam perilaku pengurutan SQL dan Windows collations. Keduanya akan menggunakan Unicode menyortir aturan.

Umumnya, tingkat perbedaan kinerja antara Windows dan SQL collations tidak akan signifikan. Perbedaan hanya muncul jika beban kerja yang terikat CPU, daripada dibatasi oleh I/O atau oleh kecepatan jaringan, dan sebagian besar ini CPU beban disebabkan oleh overhead manipulasi string atau perbandingan dilakukan dalam SQL Server. An contoh dari aplikasi di mana mungkin diucapkan perbedaan kinerja adalah sebuah sistem di mana aplikasi melewati nilai string panjang ke SQL Server prosedur yang tersimpan. Prosedur yang tersimpan kemudian mem-parsing string melalui luas penggunaan fungsi manipulasi string Transact-SQL seperti CHARINDEX atau PATINDEX. Jika beban kerja cukup satu-dimensi dan didominasi oleh eksekusi string ini disimpan prosedur, perbedaan kinerja antara parsing SQL pemeriksaan dan pemeriksaan Windows mungkin terlihat. Namun, desain sebagian besar aplikasi tidak mengarah ke sebuah situasi di mana kinerja perbedaan signifikan.

Rekomendasi

1. SQL collations disediakan untuk kompatibilitas dengan Versi sebelumnya dari SQL Server. Windows collations menyediakan konsisten string perbandingan untuk kedua Unicode dan non-Unicode teks dalam SQL Server yang juga konsisten dengan perbandingan string dalam sistem operasi Windows. Untuk semua alasan ini, Windows collations pilihan kecuali ada mundur masalah kompatibilitas atau masalah kinerja spesifik yang memerlukan SQL pemeriksaan.
2. Jika Anda mempertimbangkan pemeriksaan SQL yang didasarkan hanya pada karakteristik kinerja SQL pemeriksaan, menyadari bahwa kinerja aplikasi yang paling tidak menguntungkan secara signifikan dari perubahan dalam pemeriksaan. Pastikan bahwa Anda telah terisolasi pertanyaan yang menunjukkan manfaat dari pemeriksaan SQL. Segera setelah Anda mengidentifikasi permintaan terpengaruh, mempertimbangkan Berikut alternatif untuk perubahan dalam pemeriksaan. Kedua alternatif ini dapat memberikan keuntungan performa yang lebih besar daripada apa yang akan Anda lihat jika Anda mengubah pemeriksaan contoh untuk pemeriksaan SQL:
   1. Jika overhead untuk Windows collations yang dijiplak untuk Transact-SQL rutinitas yang melakukan manipulasi string eksplisit atau parsing, dan jika Anda menggunakan tipe data non-Unicode, Anda mungkin ingin menentukan pemeriksaan SQL atau ganda Pemeriksaan Windows untuk operasi yang sering dijalankan dan itulah paling mahal. Misalkan Anda menggunakan fungsi PATINDEX untuk menentukan apakah teks kolom dalam tabel berisi karakter "x". Jika Anda memaksa pemeriksaan SQL untuk perbandingan tertentu bahwa operasi, dan Anda terus menggunakan Windows pemeriksaan untuk seluruh database dan aplikasi, Anda tidak perlu mengubah pemeriksaan untuk seluruh sistem:

      SELECT PATINDEX ('%x%', MemoFld COLLATE SQL_Latin1_General_Cp1_CI_AS) FROM ...

   2. Jika overhead untuk Windows collations yang dijiplak untuk lebih biasa query yang tidak menggunakan string kompleks manipulasi fungsi, peningkatan indeks atau permintaan desain mungkin menyediakan perbaikan yang kerdil orang yang Anda akan melihat dengan mengubah pemeriksaan SQL. Permintaan yang dapat puas dengan sangat selektif berusaha pada sesuai indeks tidak akan peka terhadap kecil perubahan dalam string perbandingan biaya. Sebaliknya, sejumlah kecil overhead per perbandingan string dapat bertambah dengan cepat dalam permintaan yang harus melakukan sebuah tabel scan dan membandingkan nilai tertentu untuk masing-masing jutaan baris. Jika Anda mencegah meja besar atau indeks scan dari rencana permintaan dengan mengubah pengindeksan atau permintaan itu sendiri, permintaan Anda akan melakukan jauh lebih cepat daripada itu akan jika Anda mengubah untuk pemeriksaan SQL.

Catatan Ada ketiga jenis pemeriksaan yang adalah variasi dari SQL pemeriksaan. Pemeriksaan ketiga ini dikenal sebagai "pemeriksaan Kompatibilitas" atau "lapuk pemeriksaan." Pemeriksaan kompatibilitas adalah seperangkat menyortir dan Perbandingan peraturan yang tidak memiliki nama standar pemeriksaan di SQL Server 2000. Sebagai contoh, jika Anda mengkonfigurasi SQL Server 7.0 dengan tidak konsisten kasus pengaturan untuk Unicode dan non-Unicode data, Anda akan memiliki Kompatibilitas pemeriksaan ketika Anda meng-upgrade ini contoh SQL Server 7.0 ke SQL Server 2000. Dalam diskusi sebelumnya dalam artikel ini, informasi tentang SQL collations juga berlaku untuk kompatibilitas collations.

Untuk informasi selengkapnya tentang kompatibilitas collations, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: