Membandingkan SQL collations untuk Windows collations

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 322112 - Melihat produk di mana artikel ini berlaku.
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

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.

INFORMASI LEBIH LANJUT

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:
270042INF: Deskripsi dari SQL Server kompatibilitas collations

Properti

ID Artikel: 322112 - Kajian Terakhir: 26 September 2011 - Revisi: 2.0
Berlaku bagi:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Kata kunci: 
kbhowto kbinfo kbmt KB322112 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini:322112

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com