可以加一个 json 格式输出，也许程序员会用到比较多

我猜测是你这个数据量太少了，mysql 优化器就没走索引，直接锁表了。所以 4 楼加上 force index(age)走了索引就可以了
网上的资料：
即使完全符合索引生效的场景，考虑到实际数据量等原因，最终是否使用索引还要看 MySQL 优化器的判断。当然你也可以在 sql 语句中写明强制走某个索引。

@lpts007 好的

@hakono 谢谢明白了

@kindjeff 编译确实会报错，我的意思是写代码的时候 IDE 不会识别出这个错误（没有爆红的波浪线），是不是有什么特别的用法

@kindjeff 编译确实会报错，我的意思是写代码的时候 IDE 不会识别出这个错误（没有爆红的波浪线），是不是用什么特别的用法

其实很有可能是因为你开始就接触的是静态语言，思维很难转变。我朋友一开始就是学 php 的，后来转 go 还是很费劲的

@icexin 谢谢，明白了

@johnkiller 谢谢，理解了

@t6attack 理解了，谢谢

@shawndev 那直接把这些字符变为二进制（ ASCII ）不就不会影响了吗

@xx6412223 也就是说 比如 应用层的数据如果要给传输层，不过不转换成 base64 编码，有些数据比如换行等没办法被正确识别。是这个意思吗？

@vk42 是的，教材上这么说的，我之前也尝试去看 CSAPP，只不过太难懂。现在不用二级页表，那用什么呢？

@kyonn 请指教一下，我看了很多资料也没看明白。

@heimeil 谢谢解答，完全理解了。

@silenzio 谢谢解答。我之前的运行状况是 produce 一直能抢到锁，我误以为其中有什么规则。看了你的解答后我加大了循环次数和管道容量，consumer 终于抢到 produce 释放的锁了。

@zhs227 是的，我完全理解你的解答，我的这个代码很有问题，但是我的疑惑是 consumer 永远抢不到 produce 释放的锁。我加锁的目的就是为了打印的顺序和多线程中实际执行的时间相关起来。

@silenzio 而且好像获取规则也不是完全随机，因为我发现 produce 先执行，produce 能够一直抢到锁