Was ist die beste Zusammenstellung für MySQL mit PHP? [geschlossen]

Ich frage mich, ob es in MySQL eine "beste" Auswahl für die Sortierung für eine allgemeine Website gibt, bei der Sie nicht 100% sicher sind, was eingegeben wird. Ich verstehe, dass alle Codierungen gleich sein sollten, wie MySQL, Apache, HTML und alles in PHP.

In der Vergangenheit habe ich PHP so eingestellt, dass es in "UTF-8" ausgegeben wird. Aber welche Sortierung stimmt mit dieser in MySQL überein? Ich denke , es ist eine der UTF-8 ist, aber ich verwendet habe utf8_unicode_ci, utf8_general_ciund utf8_binvor.

Der Hauptunterschied besteht in der Sortiergenauigkeit (beim Vergleichen von Zeichen in der Sprache) und der Leistung. Die einzige Besonderheit ist utf8_bin, mit der Zeichen im Binärformat verglichen werden können.

utf8_general_ciist etwas schneller als utf8_unicode_ci, aber weniger genau (zum Sortieren). Die spezifische utf8-Sprachcodierung (z. B. utf8_swedish_ci) enthält zusätzliche Sprachregeln, mit denen sie für diese Sprachen am genauesten sortiert werden können. Die meiste Zeit benutze ich utf8_unicode_ci(ich bevorzuge Genauigkeit gegenüber kleinen Leistungsverbesserungen), es sei denn, ich habe einen guten Grund, eine bestimmte Sprache zu bevorzugen.

Weitere Informationen zu bestimmten Unicode-Zeichensätzen finden Sie im MySQL-Handbuch - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Eigentlich möchten Sie wahrscheinlich utf8_unicode_cioder verwenden utf8_general_ci.

• utf8_general_ci sortiert, indem alle Akzente entfernt und sortiert werden, als wäre es ASCII
• utf8_unicode_ci Verwendet die Unicode-Sortierreihenfolge, sodass die Sortierung in mehreren Sprachen korrekt ist

Wenn Sie dies jedoch nur zum Speichern von englischem Text verwenden, sollten sich diese nicht unterscheiden.

Seien Sie sich dieses Problems sehr, sehr bewusst, das bei der Verwendung auftreten kann utf8_general_ci.

MySQL unterscheidet einige Zeichen in ausgewählten Anweisungen nicht, wenn die utf8_general_ciSortierung verwendet wird. Dies kann zu sehr bösen Fehlern führen - insbesondere bei Benutzernamen. Abhängig von der Implementierung, die die Datenbanktabellen verwendet, kann dieses Problem böswilligen Benutzern ermöglichen, einen Benutzernamen zu erstellen, der mit einem Administratorkonto übereinstimmt.

Dieses Problem tritt zumindest in frühen 5.x-Versionen auf - ich bin mir nicht sicher, ob sich dieses Verhalten später geändert hat.

Ich bin kein DBA, aber um dieses Problem zu vermeiden, gehe ich immer mit utf8-bineinem, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird.

Das folgende Skript beschreibt das Problem anhand eines Beispiels.

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

Verwenden Sie am besten einen Zeichensatz für utf8mb4die Sortierung utf8mb4_unicode_ci.

Der Zeichensatz utf8unterstützt nur eine kleine Anzahl von UTF-8-Codepunkten, etwa 6% der möglichen Zeichen. utf8unterstützt nur das Basic Multilingual Plane (BMP). Es gibt 16 andere Flugzeuge. Jede Ebene enthält 65.536 Zeichen. utf8mb4unterstützt alle 17 Flugzeuge.

MySQL schneidet 4-Byte-UTF-8-Zeichen ab, was zu beschädigten Daten führt.

Der utf8mb4Zeichensatz wurde am 24.03.2010 in MySQL 5.5.3 eingeführt.

Einige der erforderlichen Änderungen zur Verwendung des neuen Zeichensatzes sind nicht trivial:

• Möglicherweise müssen Änderungen an Ihrem Anwendungsdatenbankadapter vorgenommen werden.
• An my.cnf müssen Änderungen vorgenommen werden, einschließlich des Festlegens des Zeichensatzes, der Sortierung und des Umschaltens von innodb_file_format auf Barracuda
• SQL CREATE-Anweisungen müssen möglicherweise Folgendes enthalten: ROW_FORMAT=DYNAMIC
  • DYNAMISCH ist für Indizes für VARCHAR (192) und höher erforderlich.

HINWEIS: Beim Umschalten auf Barracudavon Antelopemuss der MySQL-Dienst möglicherweise mehrmals neu gestartet werden. innodb_file_format_maxändert sich erst, nachdem der MySQL-Dienst neu gestartet wurde auf : innodb_file_format = barracuda.

MySQL verwendet das alte AntelopeInnoDB-Dateiformat. Barracudaunterstützt dynamische Zeilenformate, die Sie benötigen, wenn Sie die SQL-Fehler zum Erstellen von Indizes und Schlüsseln nach dem Wechsel zum Zeichensatz nicht feststellen möchten:utf8mb4

• # 1709 - Indexspaltengröße zu groß. Die maximale Spaltengröße beträgt 767 Byte.
• # 1071 - Der angegebene Schlüssel war zu lang. Die maximale Schlüssellänge beträgt 767 Byte

Das folgende Szenario wurde unter MySQL 5.6.17 getestet: Standardmäßig ist MySQL folgendermaßen konfiguriert:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

Beenden Sie Ihren MySQL-Dienst und fügen Sie die Optionen zu Ihrer vorhandenen my.cnf hinzu:

[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

Beispiel einer SQL CREATE-Anweisung:

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;

• Sie können den Fehler # 1709 sehen, der generiert wurde, INDEX contact_idx (contact)wenn ROW_FORMAT=DYNAMICer aus der CREATE-Anweisung entfernt wurde.

HINWEIS: Durch Ändern des Index auf maximal 128 Zeichen contactentfällt die Verwendung von Barracuda mitROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

Beachten Sie auch: Wenn die Größe des Felds angegeben ist VARCHAR(128), sind dies nicht 128 Byte. Sie können 128, 4-Byte-Zeichen oder 128, 1-Byte-Zeichen verwenden.

Diese INSERTAnweisung sollte das 4-Byte-Zeichen 'poo' in der 2-Zeile enthalten:

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

Sie können den von der lastSpalte verwendeten Speicherplatz anzeigen:

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

In Ihrem Datenbankadapter möchten Sie möglicherweise den Zeichensatz und die Sortierung für Ihre Verbindung festlegen:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

In PHP wäre dies eingestellt für: \PDO::MYSQL_ATTR_INIT_COMMAND

Verweise:

• MySQL 5.6 Referenzhandbuch: Grenzwerte für InnoDB-Tabellen
• So unterstützen Sie vollständigen Unicode in MySQL-Datenbanken

Kollatierungen beeinflussen, wie Daten sortiert werden und wie Zeichenfolgen miteinander verglichen werden. Das heißt, Sie sollten die Sortierung verwenden, die die meisten Ihrer Benutzer erwarten.

Beispiel aus der Dokumentation zum Zeichensatz-Unicode :

utf8_general_ciist auch für Deutsch und Französisch zufriedenstellend, außer dass 'ß' gleich 's' und nicht 'ss' ist. Wenn dies für Ihre Anwendung akzeptabel ist, sollten Sie es verwenden, utf8_general_cida es schneller ist. Andernfalls verwenden utf8_unicode_ciSie , weil es genauer ist.

Also - es hängt von Ihrer erwarteten Benutzerbasis ab und davon, wie viel Sie korrekt sortieren müssen. Für eine englische Benutzerbasis utf8_general_cisollte ausreichen, für andere Sprachen wie Schwedisch wurden spezielle Kollatierungen erstellt.

Im Wesentlichen hängt es davon ab, wie Sie über eine Zeichenfolge denken.

Ich benutze immer utf8_bin wegen des von Guus hervorgehobenen Problems. Meiner Meinung nach ist eine Zeichenfolge in Bezug auf die Datenbank immer noch nur eine Zeichenfolge. Eine Zeichenfolge besteht aus mehreren UTF-8-Zeichen. Ein Zeichen hat eine binäre Darstellung. Warum muss es die Sprache kennen, die Sie verwenden? Normalerweise erstellen Benutzer Datenbanken für Systeme mit dem Umfang für mehrsprachige Websites. Dies ist der springende Punkt bei der Verwendung von UTF-8 als Zeichensatz. Ich bin ein bisschen puristisch, aber ich denke, das Fehlerrisiko überwiegt stark den leichten Vorteil, den Sie bei der Indizierung erhalten können. Alle sprachbezogenen Regeln sollten auf einer viel höheren Ebene als das DBMS durchgeführt werden.

In meinen Büchern sollte "Wert" in einer Million Jahren niemals gleich "Wert" sein.

Wenn ich ein Textfeld speichern und eine Suche ohne Berücksichtigung der Groß- und Kleinschreibung durchführen möchte, verwende ich MYSQL-Zeichenfolgenfunktionen mit PHP-Funktionen wie LOWER () und der PHP-Funktion strtolower ().

Für UTF-8-Textinformationen sollten Sie verwenden, utf8_general_ciweil ...

• utf8_bin: Vergleichen Sie Zeichenfolgen mit dem Binärwert jedes Zeichens in der Zeichenfolge

• utf8_general_ci: Vergleichen Sie Zeichenfolgen mit allgemeinen Sprachregeln und mit Vergleichen ohne Berücksichtigung der Groß- und Kleinschreibung

aka es wird das Suchen und Indizieren der Daten schneller / effizienter / nützlicher machen.

Die akzeptierte Antwort schlägt ziemlich definitiv vor, utf8_unicode_ci zu verwenden, und während das für neue Projekte großartig ist, wollte ich meine jüngsten gegenteiligen Erfahrungen nur für den Fall erzählen, dass es jemandem Zeit spart.

Da utf8_general_ci die Standardkollatierung für Unicode in MySQL ist, müssen Sie utf8_unicode_ci an vielen Stellen angeben, wenn Sie utf8_unicode_ci verwenden möchten .

Beispielsweise haben alle Clientverbindungen nicht nur einen Standardzeichensatz (für mich sinnvoll), sondern auch eine Standardkollatierung (dh die Kollatierung wird für Unicode immer standardmäßig utf8_general_ci verwendet).

Wenn Sie utf8_unicode_ci für Ihre Felder verwenden, müssen Ihre Skripts, die eine Verbindung zur Datenbank herstellen, wahrscheinlich aktualisiert werden, um die gewünschte Sortierung explizit zu erwähnen. Andernfalls können Abfragen mit Textzeichenfolgen fehlschlagen, wenn Ihre Verbindung die Standardkollatierung verwendet.

Das Ergebnis ist, dass Sie beim Konvertieren eines vorhandenen Systems beliebiger Größe in Unicode / utf8 möglicherweise gezwungen sind, utf8_general_ci zu verwenden, da MySQL die Standardeinstellungen behandelt.

Für den von Guus hervorgehobenen Fall würde ich dringend empfehlen, entweder utf8_unicode_cs (Groß- und Kleinschreibung beachten, strikte Übereinstimmung, größtenteils korrekte Reihenfolge) anstelle von utf8_bin (strikte Übereinstimmung, falsche Reihenfolge) zu verwenden.

Wenn das Feld durchsucht werden soll, anstatt für einen Benutzer abgeglichen zu werden, verwenden Sie utf8_general_ci oder utf8_unicode_ci. Bei beiden wird die Groß- und Kleinschreibung nicht berücksichtigt, man wird verlieren ('ß' ist gleich 's' und nicht 'ss'). Es gibt auch sprachspezifische Versionen wie utf8_german_ci, bei denen der Lose Matching besser für die angegebene Sprache geeignet ist.

[Bearbeiten - fast 6 Jahre später]

Ich empfehle den Zeichensatz "utf8" unter MySQL nicht mehr und empfehle stattdessen den Zeichensatz "utf8mb4". Sie stimmen fast vollständig überein, erlauben jedoch ein wenig (viel) mehr Unicode-Zeichen.

Realistisch gesehen hätte MySQL den Zeichensatz "utf8" und die entsprechenden Kollatierungen so aktualisieren müssen, dass sie mit der Spezifikation "utf8" übereinstimmen. Stattdessen sollte ein separater Zeichensatz und entsprechende Kollatierungen die Speicherbezeichnung für diejenigen nicht beeinflussen, die bereits ihren unvollständigen Zeichensatz "utf8" verwenden .

Ich fand diese Kollatierungsdiagramme hilfreich. http://collation-charts.org/mysql60/ . Ich bin mir nicht sicher, welches das verwendete utf8_general_ci ist.

Hier ist zum Beispiel das Diagramm für utf8_swedish_ci. Es zeigt, welche Zeichen als gleich interpretiert werden. http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

Fügen Sie in Ihrer Datenbank-Upload-Datei vor jeder Zeile die folgende Zeile ein:

SET NAMES utf8;

Und dein Problem sollte gelöst sein.