MySQL 5.5 förlorar efterföljande utrymmen i fråga

Detta beteende är designat, inte bara i MySQL.

Du kan kringgå det i jämförelser genom att använda BINARY :

mysql> select version(), 'a' = 'a ', BINARY 'a' = BINARY 'a ';
+-------------+------------+--------------------------+
| version()   | 'a' = 'a ' | BINARY 'a' = BINARY 'a ' |
+-------------+------------+--------------------------+
| 5.5.25a-log |          1 |                        0 |
+-------------+------------+--------------------------+
1 row in set (0.00 sec)

men inte mycket mer. Detta hjälper dig med SELECT s om blanksteg visas t.ex. i användarinmatning till en sökning; men om du faktiskt vill mata in blankstegsspårad information kommer det att vara ett problem (du kan inte ha ett index med både 'a' och 'a ').

Se även

Trailing whitespace i varchar-behov att betraktas i jämförelse

Du kan tänkas vända strängarna i den kolumnen och vänd tillbaka dem när du visar dem. Naturligtvis kommer detta att förstöra alla beställningar baserat på den kolumnen, men om du bara testar likhet eller delsträngs existens, kan det bara fungera. Ledande blanksteg räknas.

För likhetssökningar kan du också lagra base64-kodningen för strängen, som borde bibehålla den lexikografiska ordningen (dvs ordningen mellan a och b bör bibehållas mellan base64(a) och base64(b)). Eller så kan du lägga till en terminator på strängen ("\n" kan fungera bra och inte visas i sökningar).

Slutligen, men det är riskabelt eftersom människor inte kan se skillnad, du kan ersätta mellanslag med UTF8 char(49824):

mysql> select concat ('\'a', char(49824),'\'') AS tricked,
              concat ('\'a', ' '        ,'\'') as honest,
              concat ('\'a', char(49824),'\'') =
              concat ('\'a', ' '        ,'\'') as equals;

+---------+--------+--------+
| tricked | honest | equals |
+---------+--------+--------+
| 'a '    | 'a '   |      0 |
+---------+--------+--------+
1 row in set (0.00 sec)

Raderna verkar att vara lika, men de är inte det. Observera att i HTML är utrymmet ett mellanslag och 49824 är   (icke-brytande utrymme). Detta påverkar funktioner som konverterar till och från HTML, och att nbsp faktiskt är en UTF8-kodpunkt betyder att ärlig sträng är två byte, men längden på tricked strängen är faktiskt tre .

Slutligen kan du deklarera kolumnen VARBINARY istället för VARCHAR , och döljer alltså helt vad som händer. Det ser ut som den enklaste lösningen, men jag fruktar att det kan bita dig några veckor eller månader senare.