การเปรียบเทียบที่ดีที่สุดที่จะใช้สำหรับ MySQL กับ PHP คืออะไร? [ปิด]

ฉันสงสัยว่ามีตัวเลือก "ดีที่สุด" สำหรับการเปรียบเทียบใน MySQL สำหรับเว็บไซต์ทั่วไปที่คุณไม่แน่ใจ 100% ว่าจะป้อนอะไร? ฉันเข้าใจว่าการเข้ารหัสทั้งหมดควรเหมือนกันเช่น MySQL, Apache, HTML และทุกอย่างใน PHP

ในอดีตที่ผ่านมาฉันได้ตั้งค่า PHP ให้แสดงผลใน "UTF-8" แต่การเปรียบเทียบนี้เปรียบเทียบใน MySQL ที่ไหน? ฉันคิดว่ามันเป็นหนึ่งในคนที่ UTF-8 แต่ฉันได้ใช้utf8_unicode_ci, utf8_general_ciและutf8_binก่อนที่จะ

ความแตกต่างที่สำคัญคือการเรียงลำดับความถูกต้อง (เมื่อเปรียบเทียบอักขระในภาษา) และประสิทธิภาพ สิ่งที่พิเศษเพียงอย่างเดียวคือ utf8_bin ซึ่งใช้สำหรับการเปรียบเทียบอักขระในรูปแบบไบนารี

utf8_general_ciค่อนข้างเร็วกว่าutf8_unicode_ciแต่มีความแม่นยำน้อยกว่า (สำหรับการจัดเรียง) การเข้ารหัสภาษา utf8 เฉพาะ (เช่นutf8_swedish_ci) มีกฎภาษาเพิ่มเติมที่ทำให้พวกเขาถูกต้องที่สุดในการเรียงลำดับสำหรับภาษาเหล่านั้น เวลาส่วนใหญ่ที่ฉันใช้utf8_unicode_ci(ฉันชอบความแม่นยำในการปรับปรุงประสิทธิภาพเล็กน้อย) เว้นแต่ว่าฉันมีเหตุผลที่ดีที่จะชอบภาษาที่เฉพาะเจาะจง

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับชุดอักขระ Unicode ที่ระบุในคู่มือ MySQL - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

ที่จริงแล้วคุณอาจต้องการที่จะใช้หรือutf8_unicode_ciutf8_general_ci

• utf8_general_ci เรียงลำดับโดยการกำจัดสำเนียงทั้งหมดและเรียงลำดับราวกับว่าเป็น ASCII
• utf8_unicode_ci ใช้ลำดับการเรียง Unicode ดังนั้นจึงเรียงลำดับอย่างถูกต้องในภาษาอื่น ๆ

อย่างไรก็ตามหากคุณใช้สิ่งนี้เพื่อจัดเก็บข้อความภาษาอังกฤษเท่านั้นสิ่งเหล่านี้ไม่ควรแตกต่างกัน

utf8_general_ciจะมากมากตระหนักถึงปัญหานี้ที่สามารถเกิดขึ้นเมื่อใช้

MySQL จะไม่แยกความแตกต่างระหว่างอักขระบางตัวในข้อความสั่งที่เลือกหากใช้การutf8_general_ciเปรียบเทียบ สิ่งนี้สามารถนำไปสู่ข้อผิดพลาดที่น่ารังเกียจมาก - โดยเฉพาะอย่างยิ่งตัวอย่างเช่นที่มีชื่อผู้ใช้ที่เกี่ยวข้อง ปัญหานี้อาจทำให้ผู้ใช้ที่เป็นอันตรายสามารถสร้างชื่อผู้ใช้ที่ตรงกับบัญชีผู้ดูแลทั้งนี้ขึ้นอยู่กับการใช้งานที่ใช้ตารางฐานข้อมูล

ปัญหานี้จะเปิดเผยตัวเองอย่างน้อยที่สุดในช่วงต้นของเวอร์ชัน 5.x - ฉันไม่แน่ใจว่าพฤติกรรมนี้จะเปลี่ยนไปในภายหลัง

ฉันไม่ใช่ DBA แต่เพื่อหลีกเลี่ยงปัญหานี้ฉันจะไปด้วยเสมอutf8-binแทนที่จะใช้ตัวพิมพ์เล็กและใหญ่

สคริปต์ด้านล่างอธิบายปัญหาด้วยตัวอย่าง

-- 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;

ที่ดีที่สุดคือการใช้ชุดตัวอักษรที่มีการเปรียบเทียบutf8mb4utf8mb4_unicode_ci

ชุดอักขระutf8รองรับเฉพาะจุดโค้ด UTF-8 เพียงเล็กน้อยเท่านั้นประมาณ 6% ของอักขระที่เป็นไปได้ utf8รองรับ Basic Multilingual Plane (BMP) เท่านั้น มีเครื่องบินอีก 16 ลำ เครื่องบินแต่ละลำมี 65,536 ตัวอักษร utf8mb4รองรับเครื่องบินทั้ง 17 ลำ

MySQL จะตัดทอนอักขระ UTF-8 ขนาด 4 ไบต์ทำให้ข้อมูลเสียหาย

utf8mb4ชุดอักขระเป็นที่รู้จักใน MySQL 5.5.3 บน 2010-03-24

การเปลี่ยนแปลงที่จำเป็นบางอย่างเพื่อใช้ชุดอักขระใหม่นั้นไม่สำคัญ:

• อาจจำเป็นต้องทำการเปลี่ยนแปลงในอะแดปเตอร์ฐานข้อมูลแอปพลิเคชันของคุณ
• จะต้องทำการเปลี่ยนแปลงใน my.cnf รวมถึงการตั้งค่าชุดอักขระการเรียงและการสลับ innodb_file_format เป็น Barracuda
• คำสั่ง SQL CREATE อาจต้องมี: ROW_FORMAT=DYNAMIC
  • จำเป็นต้องใช้ DYNAMIC สำหรับดัชนีใน VARCHAR (192) ขึ้นไป

หมายเหตุ: การเปลี่ยนBarracudaจากAntelopeอาจต้องเริ่มบริการ MySQL ใหม่มากกว่าหนึ่งครั้ง innodb_file_format_maxไม่เปลี่ยนแปลงจนกว่าจะได้รับบริการ MySQL innodb_file_format = barracudaได้รับการเริ่มต้นใหม่ไปที่:

MySQL ใช้Antelopeรูปแบบไฟล์ InnoDB แบบเก่า Barracudaสนับสนุนรูปแบบแถวแบบไดนามิกซึ่งคุณจะต้องถ้าคุณไม่ต้องการที่จะตีข้อผิดพลาด SQL สำหรับการสร้างดัชนีและคีย์หลังจากที่คุณเปลี่ยนเป็นชุดอักขระ:utf8mb4

• # 1709 - ขนาดคอลัมน์ดัชนีใหญ่เกินไป ขนาดคอลัมน์สูงสุดคือ 767 ไบต์
• # 1071 - รหัสที่ระบุยาวเกินไป ความยาวสูงสุดของคีย์คือ 767 ไบต์

สถานการณ์จำลองต่อไปนี้ได้รับการทดสอบบน MySQL 5.6.17: ตามค่าเริ่มต้น MySQL ได้รับการกำหนดค่าดังนี้:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

หยุดบริการ MySQL ของคุณและเพิ่มตัวเลือกใน my.cnf ที่มีอยู่ของคุณ:

[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

ตัวอย่างคำสั่ง SQL CREATE:

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;

• คุณสามารถดูข้อผิดพลาด # 1709 ที่สร้างขึ้นINDEX contact_idx (contact)หากROW_FORMAT=DYNAMICถูกลบออกจากคำสั่ง CREATE

หมายเหตุ: การเปลี่ยนดัชนีเพื่อ จำกัด จำนวนอักขระสูงสุด 128 ตัวบนcontactจะกำจัดข้อกำหนดสำหรับการใช้ Barracuda ด้วยROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

หมายเหตุ: เมื่อมีข้อความระบุขนาดของเขตข้อมูลVARCHAR(128)นั่นคือไม่ใช่ 128 ไบต์ คุณสามารถใช้มี 128, 4 ไบต์อักขระหรือ 128, 1 ไบต์อักขระ

INSERTคำสั่งนี้ควรมีอักขระ 'poo' ขนาด 4 ไบต์ในแถวที่ 2:

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💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

คุณสามารถดูจำนวนพื้นที่ที่lastคอลัมน์ใช้:

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
+--------------------+---------------------+

ในอะแดปเตอร์ฐานข้อมูลของคุณคุณอาจต้องการตั้ง charset และ collation สำหรับการเชื่อมต่อของคุณ:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

ใน PHP สิ่งนี้จะถูกตั้งค่าสำหรับ: \PDO::MYSQL_ATTR_INIT_COMMAND

อ้างอิง:

• คู่มืออ้างอิง Mysql 5.6: ข้อ จำกัด ในตาราง InnoDB
• วิธีการรองรับ Unicode แบบเต็มในฐานข้อมูล MySQL

การเรียงลำดับจะมีผลต่อการเรียงลำดับข้อมูลและเปรียบเทียบสตริงอย่างไร นั่นหมายความว่าคุณควรใช้การเปรียบเทียบที่ผู้ใช้ส่วนใหญ่คาดหวัง

ตัวอย่างจากเอกสารประกอบสำหรับชุดอักขระ Unicode :

utf8_general_ciก็เป็นที่น่าพอใจสำหรับทั้งเยอรมันและฝรั่งเศสยกเว้นว่า 'ß' เท่ากับ 's' และไม่ใช่ 'ss' หากสิ่งนี้ยอมรับได้สำหรับแอปพลิเคชันของคุณคุณควรใช้ utf8_general_ciเพราะมันเร็วกว่า มิฉะนั้นให้ใช้utf8_unicode_ciเพราะแม่นยำกว่า

ดังนั้น - ขึ้นอยู่กับฐานผู้ใช้ที่คาดหวังและจำนวนที่คุณต้องการในการเรียงลำดับที่ถูกต้อง สำหรับฐานผู้ใช้ภาษาอังกฤษutf8_general_ciควรพอเพียงสำหรับภาษาอื่น ๆ เช่นภาษาสวีเดนได้มีการสร้างการเปรียบเทียบพิเศษ

โดยพื้นฐานแล้วมันขึ้นอยู่กับว่าคุณคิดอย่างไรกับสตริง

ฉันมักจะใช้ utf8_bin เพราะปัญหาที่เน้นโดย Guus ในความคิดของฉันเท่าที่ฐานข้อมูลควรกังวลสตริงยังคงเป็นเพียงสตริง สตริงคือจำนวน UTF-8 อักขระ อักขระมีการนำเสนอแบบไบนารีดังนั้นทำไมจึงจำเป็นต้องรู้ภาษาที่คุณใช้ โดยปกติผู้คนจะสร้างฐานข้อมูลสำหรับระบบที่มีขอบเขตสำหรับไซต์หลายภาษา นี่คือจุดรวมของการใช้ UTF-8 เป็นชุดอักขระ ฉันเป็นคนเจ้าระเบียบนิดหน่อย แต่ฉันคิดว่าข้อผิดพลาดนั้นมีค่ามากกว่าความได้เปรียบเล็กน้อยที่คุณอาจได้รับจากการทำดัชนี กฎใด ๆ ที่เกี่ยวข้องกับภาษาควรทำในระดับที่สูงกว่า DBMS

ใน "คุณค่า" ในหนังสือของฉันไม่ควรเท่ากับหนึ่งล้านปีในการเท่ากับ "valúe"

ถ้าฉันต้องการเก็บฟิลด์ข้อความและค้นหาแบบตัวพิมพ์เล็กและตัวพิมพ์เล็กฉันจะใช้ฟังก์ชันสตริง MYSQL กับฟังก์ชัน PHP เช่น LOWER () และฟังก์ชัน PHP strtolower ()

สำหรับข้อมูลที่เป็นข้อความ UTF-8 คุณควรใช้utf8_general_ciเพราะ ...

• utf8_bin: เปรียบเทียบสตริงด้วยค่าไบนารีของแต่ละอักขระในสตริง

• utf8_general_ci: เปรียบเทียบสตริงโดยใช้กฎภาษาทั่วไปและใช้การเปรียบเทียบแบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

อาคามันจะทำให้การค้นหาและการจัดทำดัชนีข้อมูลเร็วขึ้น / มีประสิทธิภาพมากขึ้น / มีประโยชน์มากขึ้น

คำตอบที่ได้รับการยอมรับแนะนำอย่างชัดเจนโดยใช้ utf8_unicode_ci และสำหรับโครงการใหม่ที่ยอดเยี่ยมฉันต้องการเชื่อมโยงประสบการณ์ที่ตรงกันข้ามของฉันเมื่อไม่นานมานี้ในกรณีที่ช่วยให้ทุกคนประหยัดเวลา

เนื่องจาก utf8_general_ci คือการเรียงหน้าเริ่มต้นสำหรับ Unicode ใน MySQL ถ้าคุณต้องการใช้ utf8_unicode_ci คุณจะต้องระบุมันในหลายๆ ที่

ตัวอย่างเช่นการเชื่อมต่อไคลเอนต์ไม่เพียง แต่จะมีชุดอักขระเริ่มต้น (สมเหตุสมผลกับฉัน) แต่ยังมีการเปรียบเทียบค่าเริ่มต้น (เช่นการเปรียบเทียบจะเริ่มต้นเป็น utf8_general_ci สำหรับ Unicode เสมอ)

หากคุณใช้ utf8_unicode_ci สำหรับฟิลด์ของคุณสคริปต์ของคุณที่เชื่อมต่อกับฐานข้อมูลจะต้องได้รับการอัปเดตเพื่อกล่าวถึงการจัดเรียงที่ต้องการอย่างชัดเจนมิฉะนั้นการสืบค้นที่ใช้สตริงข้อความอาจล้มเหลวเมื่อการเชื่อมต่อของคุณใช้การเปรียบเทียบเริ่มต้น

ผลที่สุดคือเมื่อทำการแปลงระบบที่มีอยู่ทุกขนาดให้เป็น Unicode / utf8 คุณอาจถูกบังคับให้ใช้ utf8_general_ci เนื่องจากวิธีที่ MySQL จัดการกับค่าเริ่มต้น

สำหรับกรณีที่ไฮไลต์โดย Guus ฉันขอแนะนำอย่างยิ่งให้ใช้ utf8_unicode_cs (ตัวพิมพ์เล็กและตัวพิมพ์ใหญ่การจับคู่ที่เข้มงวดการสั่งซื้ออย่างถูกต้องสำหรับส่วนใหญ่) แทน utf8_bin (การจับคู่ที่เข้มงวดการสั่งที่ไม่ถูกต้อง)

หากฟิลด์นั้นมีวัตถุประสงค์ที่จะค้นหาแทนที่จะตรงกับผู้ใช้ให้ใช้ utf8_general_ci หรือ utf8_unicode_ci ทั้งสองตัวพิมพ์เล็กและตัวพิมพ์ใหญ่หนึ่งตัวจะไม่ตรงกัน ('ß' เท่ากับ 's' และไม่ใช่ 'ss') นอกจากนี้ยังมีรุ่นภาษาเฉพาะเช่น utf8_german_ci ซึ่งการจับคู่การสูญเสียเหมาะกว่าสำหรับภาษาที่ระบุ

[แก้ไข - เกือบ 6 ปีต่อมา]

ฉันไม่แนะนำชุดอักขระ "utf8" บน MySQL และแนะนำชุดอักขระ "utf8mb4" แทน ตรงกับเกือบทั้งหมด แต่อนุญาตให้มีอักขระ Unicode น้อยมาก (มาก)

ในความเป็นจริง MySQL ควรมีการปรับปรุงชุดอักขระ "utf8" และการเรียงตามลำดับเพื่อให้ตรงกับข้อกำหนด "utf8" แต่แทนที่จะเป็นชุดอักขระแยกต่างหากและการเรียงตามลำดับเพื่อไม่ส่งผลกระทบต่อการกำหนดหน่วยเก็บข้อมูล .

ฉันพบว่าแผนภูมิการเปรียบเทียบเหล่านี้มีประโยชน์ http://collation-charts.org/mysql60/ ฉันไม่แน่ใจว่าจะใช้ utf8_general_ci อย่างไร

ตัวอย่างเช่นที่นี่เป็นแผนภูมิสำหรับ utf8_swedish_ci มันแสดงให้เห็นว่าตัวละครที่มันตีความเหมือนกัน http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

ในไฟล์อัพโหลดฐานข้อมูลของคุณเพิ่มบรรทัด followin ก่อนบรรทัดใด ๆ :

SET NAMES utf8;

และปัญหาของคุณควรได้รับการแก้ไข