sql >> Database teknologi >  >> RDS >> Mysql

Sammenligning af strenge med en med tomme mellemrum før, mens den anden ikke har

CHAR-typer udfylder strengen til længden af ​​feltet med null-bytes (mens VARCHAR tilføjer afgrænsningstegn for at angive slutningen af ​​strengen - og dermed ignorerer ekstra data i slutningen (Jeg mener tomme bytes )), og derfor vil sammenligninger, der har mellemrum i slutningen, ignorere disse. Førende rum er relevante, da de ændrer selve strengen. Se Christophers svar.

EDIT:Noget yderligere uddybning påkrævet

Se nogle praktiske prøver nedenfor. VARCHAR-typer tilføjer mellemrum til strengen, mens CHAR-felter, selvom de fylder strengen op til dens størrelse med mellemrum, ignorerer dem under sammenligninger. Se specifikt den anden linje med LENGTH funktionsforespørgsel:

mysql> create table test (a VARCHAR(10), b CHAR(10));
Query OK, 0 rows affected (0.17 sec)

mysql> insert into test values ('a', 'a'), ('a ', 'a '), (' a', ' a');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select a, LENGTH(a), b, LENGTH(b) FROM test;
+------+-----------+------+-----------+
| a    | LENGTH(a) | b    | LENGTH(b) |
+------+-----------+------+-----------+
| a    |         1 | a    |         1 | 
| a    |         2 | a    |         1 | 
|  a   |         2 |  a   |         2 | 
+------+-----------+------+-----------+
3 rows in set (0.00 sec)

hvor MySQL angiver CHAR-feltet, med værdien 'a', som det blev indsat, har kun 1 tegn i længden. Desuden, hvis vi sammenkæder lidt data:

mysql> select CONCAT(a, '.'), CONCAT(b, '.') FROM test;
+----------------+----------------+
| CONCAT(a, '.') | CONCAT(b, '.') |
+----------------+----------------+
| a.             | a.             | 
| a .            | a.             | 
|  a.            |  a.            | 
+----------------+----------------+
3 rows in set (0.00 sec)

mysql> select CONCAT(a, b), CONCAT(b, a) FROM test;
+--------------+--------------+
| CONCAT(a, b) | CONCAT(b, a) |
+--------------+--------------+
| aa           | aa           | 
| a a          | aa           | 
|  a a         |  a a         | 
+--------------+--------------+
3 rows in set (0.00 sec)

du kan se, at da VARCHAR gemmer, hvor strengen slutter, forbliver pladsen på sammenkædninger - hvilket ikke gælder for CHAR-typer. Husk nu den tidligere LENGTH Eksempel, hvor linje to har forskellige længder for felterne a og b, tester vi:

mysql> SELECT * FROM test WHERE a=b;
+------+------+
| a    | b    |
+------+------+
| a    | a    | 
| a    | a    | 
|  a   |  a   | 
+------+------+
3 rows in set (0.00 sec)

Derfor kan vi opsummere, at CHAR-datatypen ignorerer og trimmer ekstra plads i slutningen af ​​sin streng, mens VARCHAR ikke gør det - undtagen under sammenligninger :

mysql> select a from test where a = 'a ';
+------+
| a    |
+------+
| a    | 
| a    | 
+------+
2 rows in set (0.00 sec)

mysql> select a from test where a = 'a';
+------+
| a    |
+------+
| a    | 
| a    | 
+------+
2 rows in set (0.00 sec)

mysql> select a from test where a = ' a';
+------+
| a    |
+------+
|  a   | 
+------+
1 row in set (0.00 sec)

Så gælder det samme for CHAR-typen?

mysql> select a from test where b = 'a ';
+------+
| a    |
+------+
| a    | 
| a    | 
+------+
2 rows in set (0.00 sec)

mysql> select a from test where b = 'a';
+------+
| a    |
+------+
| a    | 
| a    | 
+------+
2 rows in set (0.00 sec)

mysql> select a from test where b = ' a';
+------+
| a    |
+------+
|  a   | 
+------+
1 row in set (0.00 sec)

Hvilket viser, at CHAR- og VARCHAR-typerne har forskellige lagringsmetoder, men følger de samme regler for ren streng-sammenligning . Efterfølgende mellemrum ignoreres; mens indledende mellemrum ændrer selve strengen.



  1. Falsk udenlandsk nøgle begrænsning mislykkes

  2. Generering af tidsserier mellem to datoer i PostgreSQL

  3. UNIK begrænsning vs kontrol før INSERT

  4. Databasedesign:ét stort bord eller separate tabeller?