都用上 oracle 这么高级的数据库了，请正经地设计一下表。不要用这种奇怪的方式来储存一对多或者多对多的数据。

一定要这么查的话，用 PostgreSQL 是这么写的
with a(id, v) as (values (1,'a'), (2,'b'), (3,'c')), b(id,ids) as (values (8, '1,3,4'), (9,'2,5,8'))
SELECT * from b
cross join regexp_split_to_table(ids, ',') as aids(aid)
inner join a on a.id = aids.aid::int
where b.id = 8;

因为有一些人非常喜欢用正则表达式
'a b c'.split(' ') 要用 (.*)\ (.*)\ (.*)
判断一个长度是 10 的 hex 字符串要用 [0-9a-f]{10}
凡是处理字符串的事情，他们都要上正则表达式。

从 html 或者 json 里提取数据也是处理字符串，他们当然要上正则表达式了。

至于这样做到底合不合适，有一个著名的 stackoverflow
https://stackoverflow.com/questions/1732348

read(2) 里有说，
On success, the number of bytes read is returned (zero indicates end of file)
On error, -1 is returned, and errno is set appropriately.
那么返回值必须是有符号的

另外，read 不保证把传进去的 buf 读满，给一个长度 200 的，只读取 127 字节或者只读取 1 字节都是可以的。

这个 API 也不是 Linux 设计的，这是 POSIX 里定义的 API，Linux 只能照着实现。

https://www.postgresql.org/docs/12/sql-insert.html

把不必要的部分去掉，insert 的语法是
INSERT INTO table_name { DEFAULT VALUES | VALUES ( { expression | DEFAULT } [, ...] ) [, ...] | query }

最常见的是 INSERT INTO table_name VALUES (1,2,3);
这个等价于 INSERT INTO table_name SELECT 1,2,3;
当然这个 SELECT 可以是任意的查询

其实 SQL 里 VALUES 就是一个直接给出结果的查询，比如子查询也可以写 VALUES
SELECT * FROM (VALUES (1, 2, 3)) as foo;
SELECT * FROM (SELECT 1, 2, 3) as foo;

@DOLLOR

发音的时候把 d 读成 t 其实没什么大问题，如果不是专门学语言的，几乎没有中国学生会去追究这种细微的声音差别。这种地方读错很正常，算不上投机取巧。

基本上吧，不论母语是什么语言，只要是学一门外语，都有这种念不出来，听不出来的声音。
把这些事情全都搞对，会把人累死的。

另外，这个东西也不完全是中国英语老师的锅。英语音标用 t 来代表 t 和 th，用 d 代表 d 。对于能区分 t 和 th 但是不能区分 t 和 d 的人来说，这个音标就很难用了。但我见过的英语词典全都是这样注音的。
https://en.wikipedia.org/wiki/International_Phonetic_Alphabet_chart_for_English_dialects

如果面试的问题就是太慢要怎么解决，那这个问题没什么意义，就跟问多么多么大的并发要怎么实现一样。
这种问题通常就是堆点什么名词，或者面试官也是在论坛博客随便看了点讨论拿来问的。

如果真要认真地问这个问题，
首先当前是怎么实现的，具体是个什么查询，慢是有多慢，预期要达到多快的速度，对数据的实时性要求有多高，这个报表有多高的查询频率，开发这个报表愿意付多少成本，运维这个报表愿意付多少成本。
这些都得先说清楚，根据不同的情况显然可以给出很多种不同的方案。

这个问题经常有人问，标准答案是不走。

至于到底走不走，必须要说清楚是哪个数据库，哪个版本，表里有多少行，每个字段是什么类型，每个字段的取值范围。基本上没人知道这些问题的答案，所以 PostgreSQL 的文档说的是

This index could in principle be used for queries that have constraints on b and/or c with no constraint on a — but the entire index would have to be scanned, so in most cases the planner would prefer a sequential table scan over using the index.

拿文档来回答这个问题，那就是可以走索引（ This index could in principle be used ）

具体来说，假设三个字段里，a 是性别，b 是年龄，c 是身高。
你可以把 select * from table where b = 18 and c = 170 拆开成 select * from table where a = '男' and b = 18 and c = 170 union all select * from table where a = '女' and b = 18 and c = 170
这样就可以走索引了，很有可能比不走索引要快。
数据库可以帮你这样优化，但到底会不会优化呢？ in most cases the planner would prefer a sequential table scan.

https://www.postgresql.org/docs/12/indexes-multicolumn.html

@felix021

客户端会用服务端的非对称加密算法的公钥进行加密。服务器要用什么来进行加密？

如果这里是说 handshake 阶段做 RSA Key Exchange，服务器发送不加密的公钥，客户端要用服务器的公钥加密 premaster key 再发过去。
如果这里说的不是 handshake 阶段，那么双方都用对称加密算法，对称算法的密钥是从 handshake 来的，和非对称算法根本没关系。

你的问题在 TLS 的框架下面本身就不成立。
看一下 wikipedia 只是为了知道相关的常识，不要问出来这种奇怪的问题。

> 大多数候选人知道非对称加密，了解客户端会用 RSA 公钥进行加密。
> 那么，服务器在返回响应报文之前，会用什么来进行加密呢？

1. "服务器在返回响应报文之前，会用什么来进行加密呢"
这句话有歧义，另一种理解方式是，服务器在返回之后，客户端要用什么来加密。
因为你的前一句话说客户端要用 RSA 公钥，那么必须让服务器先给一个公钥，那么很自然的问题就是在拿到公钥之前要怎么做。

2. 按照你想表达的含义，这个问题是要怎么加密服务器发送的报文。
你给的答案居然是用 AES，所以客户端用 RSA 加密，服务器用 AES 加密，你自己不觉得这里有问题么？为啥两边要用不同的算法？

3. 既然你要用这个来当面试题，至少把 wikipedia 的 TLS 浏览一下吧。

select a.user_id as a_id, b.user_id as b_id, a.room_id from 关系表 as a inner join 关系表 as b on a.room_id = b.room_id where a.user_id = 'a' and b.user_id = 'b'

在别的语言里，比如 C++ 和 Java，有的类型是 class 有的不是。
在 Python 里面，所有的类型都是 class，这两个词没有本质的区别。

但是当你用 class 这个词的时候，代表了不同的 class 之间有继承关系，比如 built-in function 里的 issubclass 和 isinstance。
isinstance(True, int) 是 True

用 type 的时候通常指单独的类型本身，比如 built-in functions 里的 type。
type(True) == int 是 False

楼主描述的问题和给出的 SQL 不是同一个问题

如果表里的数据是
a1 b1
a2 b2
a2 b3
a2 b4

SQL 返回的是
a1 b1
a2 b2
a2 b3
a2 b4

但是看描述应该返回
a1
a2

如果把 SQL 的开头改成 SELECT a FROM ......
结果是
a1
a2
a2
a2

还有一种你可能想要的结果是
a1
a2
a2

还有一种你可能想要的结果是
a1 b1
a2 b2
a2 b3

所以请问楼主，你到底要哪一种结果？

随便查了一下，如果是旋翼机，这个只能飞 3 小时
https://en.wikipedia.org/wiki/Robinson_R44

如果是电池驱动的固定翼，这个可以飞 4 小时
https://www.lockheedmartin.com/en-us/products/stalker.html

预算估计差了若干个数量级吧

显然是 XY problem，还没把 Y 问题说清楚

原本的问题是服务器不认 python 传过去的汉字，然后楼主拿 encode decode 和 iso-8859-1 折腾了一下就成功了，以为是服务器只支持 iso-8859-1。
但实际上显然不是这么回事，如果服务器只支持 iso-8859-1，那就不可能成功地把汉字传上去。
但是楼主又没说到底是怎么把字符串传给服务器的，如果是下面这样，说明服务器不支持 \u4e2d 这种编码 unicode 的方法。json.dumps 有一些带默认值的参数，改一改可能服务器就支持了。

>>> json.dumps('中'.encode('utf-8').decode('iso-8859-1'))
'"\\u00e4\\u00b8\\u00ad"'
>>> json.dumps('中')
'"\\u4e2d"'

至于后面的文件读不出来
'源代码' 这个字符串用 utf-8 编码过后的结果，再用 iso-8859-1 reinterpret 出来，就不是原来的字符串了，新的字符串是 'æº\x90代ç\xa0\x81'，如果你要读的文件是 '源代码'，那当然读不到

.encode('utf-8').decode('iso-8859-1') 是相当于 float x = 3.14159; int* y = (int*)&x; 这样的操作，正常情况下不会用到的。

@lihongjie0209

重点当然不是格式化的问题
举一个另外的例子

sync.Map 上没有 length 或者 size 方法，获取元素的数量要用 sync.Map.Range 遍历
https://github.com/golang/go/issues/20680
这个链接有解释说为什么不加这个方法，a Len method would either be misleading or inefficient

类似这样的例子应该还有一些，所以有人觉得拿 Go 写的代码质量会更高，因为一些 misleading 或者 inefficient 的功能直接被删掉了



> Python:
> 优秀的性能 -> 要性能的就是 C 来写

几乎所有的语言都能调用 C 代码，照你这个说法，任何一个语言都有优秀的性能

> JavaScript
> npm -> 强大的标准库

npm 不是标准库，而且我几乎没见过有人给 JavaScript 的标准库说过好话

> Java
> 我有 JVM -> 优秀的性能

性能指的不单是执行时间，内存占用量也是性能的一部分，而 JVM 在这方面的性能很渣
即使单说执行时间，JVM 可能也只是在吞吐量上有优势

Linux 5.1 - 5.1.5 的 btrfs 有个 bug，我就把一台机器的内核换成 LTS 了
Linux 的 5.2 的 Intel AX200 的驱动又有 bug 导致不能用，我的一台用这个网卡的机器被我换到了 5.1

个人观点是，mainline 显然不适合，stable 通常没什么问题但偶尔也会出点事，用 LTS 通常不会有问题
太新的硬件有可能所有版本的内核都出问题（ Intel AX200 的驱动在所有版本上都有 bug，只是有的影响小一点）

如果你的需求是 桌面操作系统、移动操作系统（ LiveCD ）
那根本没必要考虑这个问题，直接用你选的发行版给的内核就完事了，出了问题再说