mikewang

不关机，似乎说的大多数是 MacBook 。并且 MacBook 插电源和不插电源差距也挺大的。
插电源的话，合盖还能 ping 通，还能 ssh 进去。跑什么命令都没问题。
不插电源，过一段时间就掉线了，ssh 也不行。应该是进入了更深层次的睡眠。

Mac Mini 应该是一直插电的，可能就没有那种体验了(?)

@xiangyuecn #20
你确实发现了一个令很多人困惑的地方：SQL 中的“相等”，其实是概念上的等价，不是完全的相同。

排序规则（ collation ），规定了 order by 的顺序，也规定了哪些字符串是“相等”的，等号运算会返回真，group by 会被分到一组。
如果对排序规则了解不深，我推荐阅读一些相关的资料，这样奇奇怪怪的问题就能迎刃而解了。

以 MySQL 为例吧，设置 set collation_connection=utf8mb4_general_ci;
select 'abc' = 'ABC'; -- 你会发现它们是相等的，结果为 1 。
select hex('abc') = hex('ABC'); -- 你会发现结果为 0 ，不等。

select 'abc' = 'abc '; -- 相等
select length('abc') = length('abc '); -- 不等

其实也没什么问题。因为“排序规则”规定了它们等价。但是它们又不是同一个东西，所以套一层函数就不等了。
当然你也可以选一个 NO PAD 的规则，让它们自身不等。

set collation_connection=utf8mb4_0900_ai_ci;
select 'abc' = 'abc '; -- 不等
select length('abc') = length('abc '); -- 不等

这些都是可以配置的，并且不同数据库上的默认配置可能有所不同。

希望对你有所帮助。

@lance6716 #18 优秀 d(^_^o)

@lepig #5
如果是全新的业务，那么用默认的排序规则 utf8mb4_0900_ai_ci ，或者它的哥们（大小写敏感/不敏感）都是 OK 的。
这里考虑到一些已有的老库，比如它们的排序规则已经定在 utf8mb4_bin 了，那么除非重新进行完整的测试，那最好还是别动它，一般还按原来的用。

@wuyiccc #6
因为其实问题不在这（虽然有一定逻辑关系在里面），问题在于查询优化。

可以看一下 my_like_range_mb() 的实现，它的注释里面有：

> "a" is the smallest possible string for NO PAD.
> "a\0\0..." is the smallest possible string for PAD SPACE.
> "a\xff\xff..." is the biggest possible string.

其实 MySQL 是意识到这个问题的。但是后面的 if 条件是 (cs->state & MY_CS_BINSORT) || cs->pad_attribute == NO_PAD
单独把 MY_CS_BINSORT 加入判断，我觉得这个是没有理由的，且造成了 bug 。我的 patch 就是把它去掉了，测试用例可以通过。

@wqtacc #2 你说的对，但是不能否认 utf8mb4_bin 它确实有 bug 。其实不止这一个有问题，可以试试 gbk_bin 、gb18030_bin 等，也是一样的。

@Nasei #3 字符集排序规则行为是不能改变。但是如果改变 like 转化为范围查询的内部逻辑呢？那就是可行的了。其实是能修的。