Werfen Sie einen Blick auf die erstaunlichen impliziten Konvertierungen von MySQL

In der Spalte „MySQL-Tutorial“ werden verwandte implizite Konvertierungen vorgestellt

一, Problembeschreibung

root@mysqldb 22:12:  [xucl]> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

root@mysqldb 22:19:  [xucl]> select * from t1;
+--------------------+
| id                 |
+--------------------+
| 204027026112927605 |
| 204027026112927603 |
| 2040270261129276   |
| 2040270261129275   |
| 100                |
| 101                |
+--------------------+
6 rows in set (0.00 sec)

Seltsames Phänomen:

root@mysqldb 22:19:  [xucl]> select * from t1 where id=204027026112927603;
+--------------------+
| id                 |
+--------------------+
| 204027026112927605 |
| 204027026112927603 |
+--------------------+
2 rows in set (0.00 sec)

Was zum Teufel? Es ist offensichtlich 204027026112927603, warum kam auch 204027026112927605 heraus? Zweitens: Erklärung des Quellcodes Die Anrufbeziehung ist wie folgt: Wo JOIN::exec() ist der Einstiegspunkt für die Ausführung, Arg_comparator::compare_real() ist eine Funktion zur Äquivalenzbeurteilung und ihre Definition lautet wie folgt

int Arg_comparator::compare_real()
{
  /*
    Fix yet another manifestation of Bug#2338. 'Volatile' will instruct
    gcc to flush double values out of 80-bit Intel FPU registers before
    performing the comparison.
  */
  volatile double val1, val2;
  val1= (*a)->val_real();
  if (!(*a)->null_value)
  {
    val2= (*b)->val_real();
    if (!(*b)->null_value)
    {
      if (set_null)
        owner->null_value= 0;
      if (val1 < val2)  return -1;
      if (val1 == val2) return 0;
      return 1;
    }
  }
  if (set_null)
    owner->null_value= 1;
  return -1;
}

The Die Vergleichsschritte lauten wie folgt: Wie in der Abbildung gezeigt, wird die ID-Spalte der T1-Tabelle Zeile für Zeile gelesen und in Val1 platziert. Die Konstante 204027026112927603 ist im Cache vorhanden und der Typ ist double (2.0402702611292762E+17), also danach Hier wird der Wert an val2 übergeben, val2=2.0402702611292762E+17 .

Wenn die erste Zeile gescannt wird, beträgt der in ein Double umgewandelte Wert 2,0402702611292762e17. Es wird festgestellt, dass es sich um eine qualifizierte Zeile handelt. Ebenso ist 204027026112927603 konsistent ="rich_pages" src="https://img.php.cn/upload/article/000/000/052/7c4b6d4d87941f0fc37f0c115a3cf15e-3.jpg" alt="Werfen Sie einen Blick auf die erstaunlichen impliziten Konvertierungen von MySQL"/>So erkennen Sie das Konvertierung von String-Typ-Zahlen in Überläuft der Double-Typ?
Wenn die Zahl hier 16 Ziffern überschreitet, ist die Konvertierung in den Double-Typ nicht mehr korrekt

20402702611292711 wird beispielsweise als 20402702611292712 (val1 im Bild) ausgedrückt )

Die Definition der Konvertierung einer MySQL-Zeichenfolge in eine Double-Funktion lautet wie folgt:

{
  char buf[DTOA_BUFF_SIZE];
  double res;
  DBUG_ASSERT(end != NULL && ((str != NULL && *end != NULL) ||
                              (str == NULL && *end == NULL)) &&
              error != NULL);

  res= my_strtod_int(str, end, error, buf, sizeof(buf));
  return (*error == 0) ? res : (res < 0 ? -DBL_MAX : DBL_MAX);
}

Die eigentliche Konvertierungsfunktion my_strtod_int befindet sich in dtoa.c (es ist zu kompliziert, posten Sie einfach eine Kommentar)

/*
  strtod for IEEE--arithmetic machines.
 
  This strtod returns a nearest machine number to the input decimal
  string (or sets errno to EOVERFLOW). Ties are broken by the IEEE round-even
  rule.
 
  Inspired loosely by William D. Clinger's paper "How to Read Floating
  Point Numbers Accurately" [Proc. ACM SIGPLAN '90, pp. 92-101].
 
  Modifications:
 
   1. We only require IEEE (not IEEE double-extended).
   2. We get by with floating-point arithmetic in a case that
     Clinger missed -- when we're computing d * 10^n
     for a small integer d and the integer n is not too
     much larger than 22 (the maximum integer k for which
     we can represent 10^k exactly), we may be able to
     compute (d*10^k) * 10^(e-k) with just one roundoff.
   3. Rather than a bit-at-a-time adjustment of the binary
     result in the hard case, we use floating-point
     arithmetic to determine the adjustment to within
     one bit; only in really hard cases do we need to
     compute a second residual.
   4. Because of 3., we don't need a large table of powers of 10
     for ten-to-e (just some small tables, e.g. of 10^k
     for 0 <= k <= 22).
*/

In diesem Fall gab es in unserem Test keinen Überlauf. Das Ergebnis von Fall

root@mysqldb 23:30:  [xucl]> select * from t1 where id=2040270261129276;
+------------------+
| id               |
+------------------+
| 2040270261129276 |
+------------------+
1 row in set (0.00 sec)

root@mysqldb 23:30:  [xucl]> select * from t1 where id=101;
+------+
| id   |
+------+
| 101  |
+------+
1 row in set (0.00 sec)

entspricht den Erwartungen, und in diesem Fall sollte die richtige Schreibweise

root@mysqldb 22:19:  [xucl]> select * from t1 where id='204027026112927603';
+--------------------+
| id                 |
+--------------------+
| 204027026112927603 |
+--------------------+
1 row in set (0.01 sec)

sein. 3. Fazit

JOIN::exec()是执行的入口，Arg_comparator::compare_real()是进行等值判断的函数，其定义如下

1、If one or both arguments are NULL, the result of the comparison is NULL, except for the NULL-safe
<=> equality comparison operator. For NULL <=> NULL, the result is true. No conversion is needed.
2、If both arguments in a comparison operation are strings, they are compared as strings.
3、If both arguments are integers, they are compared as integers.
4、Hexadecimal values are treated as binary strings if not compared to a number.
5、If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a
constant, the constant is converted to a timestamp before the comparison is performed. This is
done to be more ODBC-friendly. This is not done for the arguments to IN(). To be safe, always
use complete datetime, date, or time strings when doing comparisons. For example, to achieve best
results when using BETWEEN with date or time values, use CAST() to explicitly convert the values to
the desired data type.
A single-row subquery from a table or tables is not considered a constant. For example, if a subquery
returns an integer to be compared to a DATETIME value, the comparison is done as two integers.
The integer is not converted to a temporal value. To compare the operands as DATETIME values,
use CAST() to explicitly convert the subquery value to DATETIME.
6、If one of the arguments is a decimal value, comparison depends on the other argument. The
arguments are compared as decimal values if the other argument is a decimal or integer value, or as
floating-point values if the other argument is a floating-point value.
7、In all other cases, the arguments are compared as floating-point (real) numbers.

比较步骤如下图所示，逐行读取t1表的id列放入val1，而常量204027026112927603存在于cache中，类型为double类型（2.0402702611292762E+17），所以到这里传值给val2后val2=2.0402702611292762E+17。

当扫描到第一行时，204027026112927605转成doule的值为2.0402702611292762e17，等式成立，判定为符合条件的行，继续往下扫描，同理204027026112927603也同样符合

如何检测string类型的数字转成doule类型是否溢出呢?这里经过测试，当数字超过16位以后，转成double类型就已经不准确了，例如20402702611292711会表示成20402702611292712（如图中val1）

MySQL string转成double的定义函数如下：

rrreee

真正转换函数my_strtod_int Vermeiden Sie implizite Typkonvertierungen. Zu den Arten der impliziten Konvertierung gehören hauptsächlich inkonsistente Feldtypen. Der in-Parameter enthält mehrere Typen, Zeichensatztypen oder inkonsistente Sortierregeln usw.

Implizite Typkonvertierung kann dazu führen, dass sie nicht verwendet werden kann Indizes, ungenaue Abfrageergebnisse usw. müssen daher bei der Verwendung sorgfältig überprüft werden.

1. Es wird empfohlen, den numerischen Typ beim Definieren des Felds als int oder bigint zu definieren Es müssen die gleichen Typ-, Zeichensatz- und Sortierregeln beibehalten werden.

2. Bitte veröffentlichen Sie abschließend die Anweisungen zur impliziten Typkonvertierung von der offiziellen Website

Das obige ist der detaillierte Inhalt vonWerfen Sie einen Blick auf die erstaunlichen impliziten Konvertierungen von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!