mysql - 为什么我必须在 mysql 子查询中将 bit(1) 转换为 unsigned？

Question

出于某种原因，如果我将该列作为子查询的一部分而不是作为“正常”查询包含在内，我必须将 BIT(1) MySQL 列显式转换为 UNSIGNED 才能返回 0 或 1。请允许我详细说明...

我有两个数据库表:比赛和投票

CONTESTS - id, ..., ...
VOTES - ..., over BIT(1), ..., ...

如果我运行这个查询，我会得到我期望的结果......

SELECT votes.over as vote_over FROM votes WHERE votes.contest_id = 38;

结果:

vote_over: 1    (ok, this makes sense)

但是，如果我尝试选择 votes.over 作为子查询，我会得到一个奇怪的结果...

SELECT contests.id as contest_id,
    (SELECT over FROM votes WHERE votes.contest_id = contests.id) as vote_over
FROM contests
where contests.id = 38;

结果:

contest_id: 38
vote_over: 49    (WHAT?)

为什么 vote_over(位列)如果是子查询则为 49，但如果它包含在上面的普通查询中则为 1？？! 49的意义是什么？为什么不是2377？ 49 是 110001，如果我将“over”列定义为 bit(6) 类型，这个问题会更有意义，但它是 bit(1)。这毫无意义!

经过一番摸索之后，我碰巧遇到了这个查询，它给了我想要的东西......

SELECT `contests`.id as contest_id,
    (SELECT cast(`votes`.over as unsigned) FROM (`votes`) WHERE votes.contest_id = contests.id)
FROM (`contests`) as vote_over
where contests.id = 38;

结果:

contest_id: 38
vote_over: 1

因此，虽然我找到了一种方法来从查询中获得我想要的结果，但我不明白为什么将 vote_over 结果强制转换为无符号仅在子查询中有所不同。

附加信息:我在笔记本电脑上的 MySQL 5.6.14 实例上运行这些查询。显然，这些查询只是假设，以说明我已经隔离的问题。它们本身没有多大意义，我在调试需要子查询的更大查询的过程中输入了它们。

似乎有一些我不理解的关于在这个问题暴露的子查询中签名位的基本知识。请帮忙!

Answer 1

这是因为 SELECT [bit_column] 一开始就不应该返回可打印的结果集。你很幸运，它有时会返回一些可以理解的东西。

http://dev.mysql.com/doc/refman/5.6/en/bit-field-literals.html :

Bit values are returned as binary values. To display them in printable form, add 0 or use a conversion function such as BIN().

在我的盒子上，SELECT [bit_column] 总是返回不可打印的字符。