ApsaraDB RDS:Compatibility of DuckDB-based analytical instances

Règles de conversion implicite de type dans les fonctions

Règles de conversion implicite de type dans les comparaisons

Les instances analytiques basées sur DuckDB appliquent des règles plus strictes et plus cohérentes en matière de conversion de type et de comparaison. Toutefois, ce comportement peut différer de celui de MySQL dans certains scénarios :

• Conversion implicite d'une chaîne vers une date : lors de la conversion implicite d'une chaîne vers une date, si le format de la chaîne ne peut pas être analysé correctement pour produire une valeur de date valide, la requête SQL échoue et renvoie une erreur.

• Règles de comparaison entre types entiers : lorsque différents types entiers sont comparés, les instances analytiques basées sur DuckDB les convertissent vers le type entier disposant de la plage de valeurs la plus large.

• Ordre de conversion de type pour les expressions à plusieurs opérandes : pour les expressions à plusieurs opérandes telles que col1 in (col2, col3, col4, ...), col1 between col2 and col3, coalesce(col1, col2, col3, ...), la conversion de type est effectuée séquentiellement.

• Différence de compatibilité pour le type YEAR : dans les instances analytiques basées sur DuckDB, le type YEAR est converti en type INTEGER pour la comparaison, ce qui peut entraîner une incompatibilité avec MySQL. Exemple :

  CREATE TABLE t1 (id YEAR PRIMARY KEY);
  INSERT INTO t1 VALUES (1980);
  SELECT * FROM t1 WHERE id BETWEEN 70 AND 90;
  
  # MySQL query result
  +------+
  | id   |
  +------+
  | 1980 |
  +------+
  
  # DuckDB-based analytical instance query result
  Empty set.

• Règles de conversion de chaîne pour le type Boolean : les instances analytiques basées sur DuckDB prennent en charge la conversion de six chaînes ('1', '0', 'yes', 'no', 'true' et 'false') vers le type BOOLEAN. Toute tentative de conversion d'une autre chaîne génère une erreur. MySQL convertit '1' en true et toutes les autres chaînes en false. Par conséquent, l'instruction SQL suivante peut renvoyer des résultats incohérents :

  CREATE TABLE t1 (id INT PRIMARY KEY);
  INSERT INTO t1 VALUES (1);
  SELECT id FROM t1 WHERE 'true';
  
  # MySQL query result
  Empty set
  
  # DuckDB-based analytical instance query result
  +------+
  | id   |
  +------+
  |    1 |
  +------+

Opérations numériques

• Les comparaisons de nombres à virgule flottante peuvent être incompatibles. Exemple :

  CREATE TABLE t1 (id FLOAT PRIMARY KEY);
  INSERT INTO t1 VALUES (1.22), (1.23), (1.24);
  SELECT * FROM t1 WHERE t1.id > 1.23;
  
  # MySQL query result
  +------+
  | id   |
  +------+
  | 1.23 |
  | 1.24 |
  +------+
  
  # DuckDB-based analytical instance query result
  +------+
  | id   |
  +------+
  | 1.24 |
  +------+

• Les résultats d'opérations complexes sur les nombres à virgule flottante peuvent varier en raison d'erreurs d'arrondi propres à ce type de données.

• Lorsqu'une opération est effectuée entre des types INTEGER et DECIMAL, le résultat ne doit pas dépasser la plage de valeurs du type. Dans le cas contraire, une erreur de dépassement de capacité peut entraîner l'échec de l'exécution.

  CREATE TABLE t1 (id TINYINT PRIMARY KEY);
  INSERT INTO t1 VALUES (100);
  SELECT id * 2 FROM t1;
  
  # MySQL query result
  +--------+
  | id * 2 |
  +--------+
  |    200 |
  +--------+
  
  # DuckDB-based analytical instance query result
  ERROR 7577 (HY000): [DuckDB] Out of Range Error: Overflow in multiplication of INT8 (100 * 2)!.

Résultats incohérents dus aux règles de collation

Les collations de la série utf8mb4_0900_xx sont incompatibles lors de la comparaison de certains caractères symboliques. Par exemple :

CREATE TABLE t1 ( id varchar(20) COLLATE utf8mb4_0900_ai_ci PRIMARY KEY );
INSERT INTO t1 VALUES ('!'), ('_');
SELECT * FROM t1 ORDER BY id;

# MySQL query result
+----+
| id |
+----+
| _  |
| !  |
+----+

# DuckDB-based analytical instance query result
+----+
| id |
+----+
| !  |
| _  |
+----+

Gestion des valeurs NULL dans les sous-requêtes vectorielles avec IN

Dans les instances analytiques basées sur DuckDB, la gestion des valeurs NULL dans les sous-requêtes vectorielles utilisant l'opérateur IN peut être incompatible avec MySQL. Exemple :

CREATE TABLE t1 (id INT PRIMARY KEY, col1 INT);
INSERT INTO t1 VALUES (1, 1), (2, 2);
CREATE TABLE t2 (id INT PRIMARY KEY, col1 INT);
INSERT INTO t2 VALUES (1, NULL);

select (id, col1) in (select id, col1 from t2) from t1;

# MySQL query result
+-----------------------------------------+
| (id, col1) in (select id, col1 from t2) |
+-----------------------------------------+
|                                    NULL |
|                                       0 |
+-----------------------------------------+

# DuckDB-based analytical instance query result
+-----------------------------------------+
| (id, col1) in (select id, col1 from t2) |
+-----------------------------------------+
|                                    NULL |
|                                    NULL |
+-----------------------------------------+

Pour les données (2, 2), aucun élément correspondant au préfixe vectoriel n'existe dans la clause IN. Dans ce cas, MySQL renvoie 0, tandis que l'instance analytique basée sur DuckDB renvoie NULL.

Fonctions d'agrégation

Fonctions numériques

Les fonctions numériques ne prennent pas en charge le type BOOLEAN.

Fonctions de chaîne

MySQL DuckDB fait une distinction stricte entre les chaînes binaires (telles que BLOB et VARBINARY) et les chaînes de caractères (telles que VARCHAR, TEXT et JSON). Par conséquent, les limites d'utilisation suivantes pour les fonctions de chaîne s'appliquent uniquement aux entrées de type chaîne, et non aux entrées de type chaîne binaire. Certaines fonctions acceptant des chaînes binaires en entrée incluent : CONCAT(), CONCAT_WS(), LENGTH(), MID(), OCTET_LENGTH(), REPEAT() et TO_BASE64(). Sauf indication contraire, ces fonctions n'ont aucune restriction d'utilisation.

Fonctions de date

Fonctions JSON

Fonctions de fenêtrage