mysql - MySQL 5.5:当我对BIT数据类型使用“CONV”时，为什么有任何基础工作

Question

为了理解MYSQL的BIT，我在MYSQL中创建了一个表名bit_demo，并在其中添加了几行，如下所示：

mysql> CREATE TABLE `bit_demo` (
    -> `mybit` bit(10) NOT NULL DEFAULT b'0'
   -> );
Query OK, 0 rows affected (0.05 sec)

mysql> insert into bit_demo values(b'1111111111');
Query OK, 1 row affected (0.00 sec)

mysql> insert into bit_demo values(b'0');
Query OK, 1 row affected (0.00 sec)

mysql> insert into bit_demo values(b'1');
Query OK, 1 row affected (0.00 sec)

但是当我使用普通查询时，它在屏幕上显示了一些奇怪的字符：

mysql> select mybit from bit_demo;
+-------+
| mybit |
+-------+
| ♥     |
|       |
|  ☺    |
+-------+
3 rows in set (0.00 sec)

所以我试着在MySQL中使用 SELECT来在输入时以位的形式查看它们。因为我不知道基础工程的价值，所以我尝试了不同的价值观。令我惊讶的是，在这种情况下 CONV(value,from_base,to_base)和 2之间的任何值都可以工作。
36或 from_base的成功结果是 from_base、 to_base或 2：

mysql> select conv(mybit,2,2) mybit from bit_demo;
+------------+
| mybit      |
+------------+
| 1111111111 |
| 0          |
| 1          |
+------------+
3 rows in set (0.00 sec)

mysql> select conv(mybit,2,36) mybit from bit_demo;
+-------+
| mybit |
+-------+
| SF    |
| 0     |
| 1     |
+-------+
3 rows in set (0.00 sec)

mysql> select conv(mybit,36,2) mybit from bit_demo;
+------------+
| mybit      |
+------------+
| 1111111111 |
| 0          |
| 1          |
+------------+
3 rows in set (0.00 sec)

mysql> select conv(mybit,10,2) mybit from bit_demo;
+------------+
| mybit      |
+------------+
| 1111111111 |
| 0          |
| 1          |
+------------+
3 rows in set (0.00 sec)

mysql> select conv(mybit,36,36) mybit from bit_demo;
+-------+
| mybit |
+-------+
| SF    |
| 0     |
| 1     |
+-------+
3 rows in set (0.00 sec)

mysql> select conv(mybit,10,10) mybit from bit_demo;
+-------+
| mybit |
+-------+
| 1023  |
| 0     |
| 1     |
+-------+
3 rows in set (0.00 sec)

如上所示，当 10在 36和 from_base之间变化时，结果不会改变。但当 2介于 36和 to_base之间时，它会发生变化。
我还使用了 2，它的工作原理如下：

 mysql> select cast(mybit as unsigned) mybit from bit_demo;
 +-------+
 | mybit |
 +-------+
 |  1023 |
 |     0 |
 |     1 |
 +-------+
3 rows in set (0.00 sec)

当 36中的任何值与 CAST(value AS UNSIGNED)over CONV(value, <2 to 36>, 10)一起工作时，有什么解释？

Answer 1

TL；博士
上面所有问题和疑问的答案是：因为它是BIT数据类型，所以它存储位。位正是任何存储器中的任何数据。因此，你不能仅仅把他们看作是他们的代表。位只是内容，它们是什么的“形状”取决于什么是上下文。
实际上是什么？
一些定义
如documentation所述，它将值存储为普通位。那是什么意思？这意味着：数据以位序列的形式存储，并且没有关于存储哪种数据的信息。DBMS根本不关心数据的类型—它没有定义，“BIT”不应该让您感到困惑BIT“并没有指向任何真正的数据类型，相反，它声称里面的数据只不过是位序列。
“位序列”是什么意思
存储位序列意味着该序列的真正意义将取决于上下文。如果不指出上下文，就不能真正说出某个序列的含义。例如，整数和字符串。什么是整数？好吧，它是一个以比特序列存储的数字。什么是字符串？是。。比特序列也是。那么如何区分它们呢？这就是为什么我们有数据类型。每种类型都是一个结构，它决定了如何处理某个值，而这个值总是一系列的位。
现在，“BIT数据类型”的命名非常糟糕，因为实际上根本没有“数据类型”。它只告诉我们它存储数据，而不绑定数据的含义。让我们用一些例子来说明。假设我们要存储字符串BIT。怎么解释呢？使用位序列，我们可以恢复它的“内部”视图：

mysql> SELECT ORD("s");
+----------+
| ORD("s") |
+----------+
|      115 |
+----------+
1 row in set (0.00 sec)

现在我们知道了“数值”表示。下一步：

mysql> SELECT CONV(115, 10, 2);
+------------------+
| CONV(115, 10, 2) |
+------------------+
| 1110011          |
+------------------+
1 row in set (0.01 sec)

好吧，这是我们想要的“点点滴滴”。我引用“位”是因为它只是可视化的，不是真实的数据。最后，我们可以将其作为一个文本插入：

mysql> INSERT INTO bit_demo (mybit) VALUES (b'1110011');
Query OK, 1 row affected (0.02 sec)

现在，一些“魔法”：

mysql> SELECT * FROM bit_demo;
+-------+
| mybit |
+-------+
|  s    |
+-------+
1 row in set (0.00 sec)

塔达！如您所见，我没有进行任何转换-但我可以在屏幕上看到有效的 "s"字符串。为什么？因为当你“选择”某个东西时，MySQL客户端会显示它，它会这样做，将传入的数据解释为字符串。所以这就是“它起作用”的原因——我们只是编写了可以解释为 "s"的位序列——而且，由于客户端正在尝试这样做（所以，将传入数据解释为字符串），所以一切顺利，我们看到了字符串。
更多字符串：编码
现在，字符串是很好的示例，因为它们也有如何解释符号的问题，因为 encodings。符号只不过是一系列的位，当符号显示出来时，你在屏幕上看到的只是所选编码对应的图形形状。举例说明：

mysql> insert into bit_demo values(b'0111111111');
Query OK, 1 row affected (0.02 sec)

让它成为我们的价值，现在，第一个案例：

mysql> SET NAMES UTF8;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from bit_demo;
+-------+
| mybit |
+-------+
| �    |
+-------+
1 row in set (0.00 sec)

第二种情况：

mysql> SET NAMES cp1251;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from bit_demo;
+-------+
| mybit |
+-------+
| я    |
+-------+
1 row in set (0.00 sec)

如你所见，某些“符号”的实际含义取决于我们使用的编码方式。位只是值，不知道这些值应该是什么意思。
整数运算
所以，现在，这和 "s"的问题差不多了。传递给该函数的值被解释为整数值。没有给出“基数”之类的信息，而且，更重要的是，它在这里不适用-你的位只存储值，对任何基数都是一样的，因此，你将从什么基数转换“从”并不重要-以位为单位的值不会改变。这就是为什么对于任意输入基数（所以， CONV()）如果目标基数相同，您将看到相同的转换结果。
以位表示的值，当用作整数时，立即成为“整数”类型，但它们也将成为由这些数据类型定义的值。同样，让我们举例说明（对于这个示例，我使用的是64位长度）：

mysql> INSERT INTO bit_demo VALUES (b'1111111111111111111111111111111111111111111111111111111111111101');
Query OK, 1 row affected (0.07 sec)

让我们看看是什么：

mysql> SELECT CAST(mybit AS SIGNED) FROM bit_demo;
+-----------------------+
| CAST(mybit AS SIGNED) |
+-----------------------+
|                    -3 |
+-----------------------+
1 row in set (0.00 sec)

以及：

mysql> SELECT CAST(mybit AS UNSIGNED) FROM bit_demo;
+-------------------------+
| CAST(mybit AS UNSIGNED) |
+-------------------------+
|    18446744073709551613 |
+-------------------------+
1 row in set (0.00 sec)

差别很大，对吧？同样，这是因为对于某些数据类型，我们已经为存储值定义了规则，但值本身并不知道如何使用和表示它。
结论
您可以将“ 2..36数据类型”视为“无类型”值。因为它实际上没有指定任何关于值的含义的信息，所以它只存储该值。如何处理和解释它只是另一回事。您应该记住，当使用这种类型以及任何值时，不管它是什么和在哪里，最后都是位序列。