PHP ile MySQL için kullanılacak en iyi harmanlama nedir? [kapalı]

Ne girileceğini% 100 emin değilseniz genel bir web sitesi için MySQL harmanlama için "en iyi" bir seçim olup olmadığını merak ediyorum? MySQL, Apache, HTML ve PHP içindeki herhangi bir şey gibi tüm kodlamaların aynı olması gerektiğini anlıyorum.

Geçmişte PHP'yi "UTF-8" biçiminde çıktı olarak ayarladım, ancak bu MySQL'de hangi harmanlama ile eşleşiyor? Ben UTF-8 olanlardan biri düşünüyorum, ama ben kullandım utf8_unicode_ci, utf8_general_cive utf8_bindaha önce.

Temel fark sıralama doğruluğu (dildeki karakterleri karşılaştırırken) ve performanstır. Tek özel olan, karakterleri ikili biçimde karşılaştırmak için utf8_bin'dir.

utf8_general_ciutf8_unicode_ci(sıralama için) biraz daha hızlı , ancak daha az doğrudur. Belirli bir dil utf8 kodlama (gibi utf8_swedish_ci) onları en doğru diller için, sıralamak yapmak ek dil kurallarını içermektedir. utf8_unicode_ciBelirli bir dili tercih etmek için iyi bir nedenim olmadıkça çoğu zaman (küçük performans iyileştirmelerinde doğruluğu tercih ederim) kullanırım .

MySQL kılavuzunda belirli unicode karakter kümeleri hakkında daha fazla bilgi edinebilirsiniz - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Aslında, muhtemelen utf8_unicode_civeya kullanmak istersiniz utf8_general_ci.

• utf8_general_ci tüm aksanları sıyrılarak ve sanki ASCII gibi sıralayarak
• utf8_unicode_ci Unicode sıralama düzenini kullanır, bu nedenle daha fazla dilde doğru şekilde sıralanır

Ancak, bunu yalnızca İngilizce metin saklamak için kullanıyorsanız, bunlar farklı olmamalıdır.

Kullanırken ortaya çıkabilecek bu sorunun çok, çok farkında olun utf8_general_ci.

utf8_general_ciHarmanlama kullanılıyorsa , MySQL, select deyimlerindeki bazı karakterleri ayırt etmez . Bu çok kötü hatalara neden olabilir - özellikle kullanıcı adlarının söz konusu olduğu yerlerde. Veritabanı tablolarını kullanan uygulamaya bağlı olarak, bu sorun kötü niyetli kullanıcıların bir yönetici hesabıyla eşleşen bir kullanıcı adı oluşturmasına izin verebilir.

Bu sorun en azından 5.x sürümlerinde kendini ortaya çıkarır - Bu davranışın daha sonra değiştiğinden emin değilim.

Ben DBA değilim, ama bu sorunu önlemek için, her zaman büyük utf8-bin/ küçük harfe duyarsız bir sorun yerine giderim .

Aşağıdaki komut dosyası sorunu örnek olarak açıklamaktadır.

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

Karakter kümesini utf8mb4harmanlama ile kullanmak en iyisidir utf8mb4_unicode_ci.

Karakter seti, utf8sadece az miktarda UTF-8 kod noktasını, olası karakterlerin yaklaşık% 6'sını destekler. utf8sadece Temel Çok Dilli Düzlemi (BMP) destekler. 16 uçak daha var. Her uçak 65.536 karakter içeriyor. utf8mb417 uçağın hepsini destekler.

MySQL, 4 bayt UTF-8 karakterlerini keserek verilerin bozulmasına neden olur.

utf8mb4Karakter kümesi 2010-03-24 tarihinde MySQL 5.5.3 tanıtıldı.

Yeni karakter setini kullanmak için gerekli değişikliklerden bazıları önemsiz değildir:

• Uygulama veritabanı bağdaştırıcınızda değişiklik yapılması gerekebilir.
• Karakter kümesinin ayarlanması, harmanlama ve innodb_file_format öğesinin Barracuda olarak değiştirilmesi de dahil olmak üzere my.cnf dosyasında değişiklikler yapılması gerekecektir.
• SQL CREATE deyimlerinin şunları içermesi gerekebilir: ROW_FORMAT=DYNAMIC
  • DİNAMİK, VARCHAR (192) ve daha büyük dizinler için gereklidir.

NOT: geçiş Barracudadan Antelopekereden fazla MySQL hizmetini yeniden başlatmayı gerektirebilir. innodb_file_format_max: MySQL servisi için çalıştıktan sonra dek değişmez innodb_file_format = barracuda.

MySQL eski AntelopeInnoDB dosya biçimini kullanır . Barracudakarakter kümesine geçtikten sonra dizinler ve anahtarlar oluşturmak için SQL hatalarına çarpmak istemiyorsanız ihtiyaç duyacağınız dinamik satır biçimlerini destekler:utf8mb4

• # 1709 - Dizin sütunu boyutu çok büyük. Maksimum sütun boyutu 767 bayttır.
• # 1071 - Belirtilen anahtar çok uzundu; maksimum anahtar uzunluğu 767 bayttır

Aşağıdaki senaryo MySQL 5.6.17 üzerinde test edilmiştir: Varsayılan olarak, MySQL şu şekilde yapılandırılmıştır:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

MySQL hizmetinizi durdurun ve mevcut my.cnf'nize seçenekleri ekleyin:

[client]
default-character-set= utf8mb4

[mysqld]
explicit_defaults_for_timestamp = true
innodb_large_prefix = true
innodb_file_format = barracuda
innodb_file_format_max = barracuda
innodb_file_per_table = true

# Character collation
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

Örnek SQL CREATE ifadesi:

CREATE TABLE Contacts (
 id INT AUTO_INCREMENT NOT NULL,
 ownerId INT DEFAULT NULL,
 created timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 modified timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 contact VARCHAR(640) NOT NULL,
 prefix VARCHAR(128) NOT NULL,
 first VARCHAR(128) NOT NULL,
 middle VARCHAR(128) NOT NULL,
 last VARCHAR(128) NOT NULL,
 suffix VARCHAR(128) NOT NULL,
 notes MEDIUMTEXT NOT NULL,
 INDEX IDX_CA367725E05EFD25 (ownerId),
 INDEX created (created),
 INDEX modified_idx (modified),
 INDEX contact_idx (contact),
 PRIMARY KEY(id)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT=DYNAMIC;

• Sen için oluşturulan hata # 1709 görebilirsiniz INDEX contact_idx (contact)eğer ROW_FORMAT=DYNAMICCREATE deyimi kaldırılır.

NOT: Dizinin ilk 128 karakterle sınırlandırılması, contactBarracuda ile birlikte kullanılması gereksinimini ortadan kaldırırROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

Ayrıca not: alanın boyutu söylendiğinde VARCHAR(128), bu 128 bayt değildir. 128, 4 bayt karakter veya 128, 1 bayt karakter kullanabilirsiniz.

Bu INSERTifade, 2 satırda 4 baytlık 'poo' karakterini içermelidir:

INSERT INTO `Contacts` (`id`, `ownerId`, `created`, `modified`, `contact`, `prefix`, `first`, `middle`, `last`, `suffix`, `notes`) VALUES
(1, NULL, '0000-00-00 00:00:00', '2014-08-25 03:00:36', '1234567890', '12345678901234567890', '1234567890123456789012345678901234567890', '1234567890123456789012345678901234567890', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678', '', ''),
(2, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', ''),
(3, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '123💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

lastSütun tarafından kullanılan alan miktarını görebilirsiniz :

mysql> SELECT BIT_LENGTH(`last`), CHAR_LENGTH(`last`) FROM `Contacts`;
+--------------------+---------------------+
| BIT_LENGTH(`last`) | CHAR_LENGTH(`last`) |
+--------------------+---------------------+
|               1024 |                 128 | -- All characters are ASCII
|               4096 |                 128 | -- All characters are 4 bytes
|               4024 |                 128 | -- 3 characters are ASCII, 125 are 4 bytes
+--------------------+---------------------+

Veritabanı bağdaştırıcınızda, bağlantınız için karakter kümesini ve harmanlamayı ayarlamak isteyebilirsiniz:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

PHP'de bu, aşağıdakiler için ayarlanır: \PDO::MYSQL_ATTR_INIT_COMMAND

Referanslar:

• Mysql 5.6 Referans Kılavuzu: InnoDB Tablolarındaki Sınırlar
• MySQL veritabanlarında tam Unicode desteği

Harmanlamalar verilerin nasıl sıralanacağını ve dizelerin birbiriyle nasıl karşılaştırıldığını etkiler. Bu, kullanıcılarınızın çoğunun beklediği harmanlamayı kullanmanız gerektiği anlamına gelir.

Charset unicode belgelerinden bir örnek :

utf8_general_ciAlmanca ve Fransızca dillerinde de tatmin edicidir, ancak 'ß', 's' değerine eşittir, 'ss' değerine eşit değildir. Bu, uygulamanız için kabul edilebilir durumdaysa, daha utf8_general_cihızlı olduğu için kullanmalısınız . Aksi takdirde, utf8_unicode_cidaha doğru olduğu için kullanın .

Yani - beklenen kullanıcı tabanınıza ve ne kadar doğru sıralamaya ihtiyacınız olduğuna bağlıdır . İngilizce bir kullanıcı tabanı utf8_general_ciiçin, İsveççe gibi diğer diller için özel harmanlamalar oluşturulmuştur.

Esasen, bir ipi nasıl düşündüğünüze bağlıdır.

Guus tarafından vurgulanan sorun nedeniyle her zaman utf8_bin kullanıyorum. Bence, veritabanı söz konusu olduğunda, bir dize hala sadece bir dizedir. Dize, bir dizi UTF-8 karakteridir. Bir karakterin ikili temsili vardır, bu yüzden neden kullandığınız dili bilmesi gerekir? Genellikle, insanlar çok dilli siteler kapsamındaki sistemler için veritabanları inşa edeceklerdir. UTF-8'i karakter kümesi olarak kullanmanın tüm noktası budur. Biraz safkanım ama sanırım böcek riskleri, endekslemede elde edebileceğiniz hafif avantajdan ağır basar. Dille ilgili tüm kurallar DBMS'den çok daha yüksek bir düzeyde yapılmalıdır.

Kitaplarımda “değer” asla bir milyon yıl içinde “valúe” ye eşit olmamalı.

Bir metin alanı depolamak ve büyük / küçük harf duyarsız bir arama yapmak istiyorsanız, LOWER () ve php işlevi strtolower () gibi PHP işlevleriyle MYSQL dize işlevlerini kullanacağım.

UTF-8 metin bilgileri için şunu kullanmalısınız utf8_general_ciçünkü ...

• utf8_bin: dizeleri dizgideki her karakterin ikili değeri ile karşılaştırır

• utf8_general_ci: Genel dil kurallarını kullanarak ve büyük / küçük harfe duyarlı olmayan karşılaştırmaları kullanarak dizeleri karşılaştır

aka veri arama ve indeksleme daha hızlı / daha verimli / daha yararlı hale getirecektir.

Kabul edilen cevap oldukça kesin bir şekilde utf8_unicode_ci kullanmayı önermektedir ve harika olan yeni projeler için, kimseye biraz zaman kazandırması durumunda son ters deneyimimi anlatmak istedim.

Utf8_general_ci MySQL'de Unicode için varsayılan harmanlama olduğundan, utf8_unicode_ci kullanmak istiyorsanız, bunu birçok yerde belirtmeniz gerekir .

Örneğin, tüm istemci bağlantılarında yalnızca varsayılan bir karakter kümesi (benim için anlamlıdır) değil, aynı zamanda varsayılan bir harmanlama bulunur (yani, harmanlama her zaman unicode için utf8_general_ci olarak varsayılan olur).

Muhtemelen, alanlarınız için utf8_unicode_ci kullanırsanız, veritabanına bağlanan komut dosyalarınızın istenen harmanlamadan açıkça bahsetmek üzere güncellenmesi gerekir - aksi takdirde bağlantınız varsayılan harmanlamayı kullanırken metin dizelerini kullanan sorgular başarısız olabilir.

Sonuç olarak, herhangi bir boyuttaki mevcut bir sistemi Unicode / utf8'e dönüştürürken, MySQL'in varsayılanları işleme biçimi nedeniyle utf8_general_ci kullanmaya zorlanabilirsiniz.

Guus tarafından vurgulanan dava için, utf8_bin (katı eşleme, yanlış sipariş) yerine utf8_unicode_cs (büyük / küçük harfe duyarlı, katı eşleme, çoğunlukla doğru sipariş verme) kullanmanızı şiddetle öneririm.

Alanın bir kullanıcıyla eşleşmenin aksine aranması amaçlanıyorsa, utf8_general_ci veya utf8_unicode_ci kullanın. Her ikisi de büyük / küçük harfe duyarsızdır, biri yavaşça eşleşir ('ß', 's' değerine eşittir, 'ss' değerine eşit değildir). Kaybedilen eşleşmenin belirtilen dil için daha uygun olduğu utf8_german_ci gibi dile özgü sürümler de vardır.

[Düzenle - yaklaşık 6 yıl sonra]

Artık MySQL'de "utf8" karakter kümesini önermiyorum ve bunun yerine "utf8mb4" karakter kümesini öneriyorum. Neredeyse tamamen eşleşiyorlar, ancak biraz (çok) daha unicode karakterlere izin veriyorlar.

Gerçekçi olarak, MySQL "utf8" karakter setini ve ilgili harmanlamaları "utf8" spesifikasyonuna uyacak şekilde güncellemeli, bunun yerine, ayrı bir karakter seti ve zaten tamamlanmamış "utf8" karakter setini kullananlar için depolama atamasını etkilememelidir. .

Bu harmanlama grafiklerini yararlı buldum. http://collation-charts.org/mysql60/ . Hangi kullanılan utf8_general_ci olsa emin değilim.

Örneğin, utf8_swedish_ci için grafik. Hangi karakterleri aynı şekilde yorumladığını gösterir. http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

Veritabanı yükleme dosyanıza aşağıdaki satırı herhangi bir satırın önüne ekleyin:

SET NAMES utf8;

Ve sorunun çözülmeli.