https://www.v2ex.com/t/655096

原来是同一个人发的，怪不得又是这种奇怪的面试题。我再来喷一次。

1. 在 Linux 下，如何删除一个目录下的所有 log 文件？

你需要给定什么叫做 log 文件，如果是文件名以 log 结尾的文件，那当然是 rm *log
删子目录是 rm **/*log

日志文件是日志文件，文件名随便是什么都可以；文件名以 log 结尾的文件是文件名以 log 结尾的文件；文件名以 .log 结尾的文件是文件名以 .log 结尾的文件，这都不一样的。真不知道你的 “log 文件” 到底是啥。

2. find 是一个不常用的命令，原因是这个命令的功能通常能被 shell 的 * 或者 ** 代替。
另外 find 功能很强，用法也很复杂，有几十个参数，参数之间有逻辑关系而且还可以套别的命令，如果不是有很特殊的需求，不会来用 find 。而且 GNU find 和 BSD find 的用法还不完全一样。
你给出的那一行 find 命令是错的，少了一个 .
find . -name \*.log -exec rm -f {} \;
这一行也可以写成
IFS=$'\n'; for f in **/*.log; do rm "$f"; done
这个可能是更常见的用法

3. 删了文件磁盘空间不释放这很正常，还有可能是 btrfs 或者 zfs 上给 dedup 了。
有这么多种可能性，我不知道为什么来面试的人就必须要想到是文件还在被占用。

4. 把日志文件删掉了，因为那个文件还在被使用，所以磁盘空间没释放。
我就想问一句，贵司真是这么删日志的么？
正在被打开的日志文件，意思是还有进程在往里面写日志，我想不到有正常的运维会删一个正在被写入的日志文件。
在我的认知里，删日志都是删若干时间之前，肯定不会再用到的老日志。这全新的还在写的日志文件你这么都随便地删掉了，那当初为啥要记这个日志呢？
能被这种神操作理直气壮地出到面试题里面，贵司确实蛮厉害的。

@594duck
1. 一台电脑，算你满载，算一个 200W 的 CPU 加一个 300 W 的显卡，两小时 1 度电。一天额外 8 度电，总共不到 20 块钱。算你这台满载的电脑没有给公司带来收益，假设工资是一小时 100 块钱，20 块钱已经是 10 分钟的工资了。每天开机关机多花十分钟有点多但也不过分。

2. 如果没关机的电脑能引起火灾，这办公设施的问题已经非常严重了。

3. 工作电脑当然要强制设密码，这是常识吧。另外这个问题和关机不相关，如果不设密码，开机的时候也不用输入密码。

Java 的 finally 也不保证能执行到
https://stackoverflow.com/questions/1410951/how-does-javas-system-exit-work-with-try-catch-finally-blocks

但是 Python 在这个情况下会执行 finally

defer 和其它语言里的 finally 基本上是等价的，直接用就是了

我觉得 panic 和 os.Exit 在正常运行的程序里不多见，出现了就需要改 bug 了，这个问题也没多大影响

这个拆开查就简单了，查一次所有一级代理下面有多少二级代理，再查一次一级代理下面有多少用户，再查一次一级代理下面的二级代理有多少用户，分三次查应该也没什么不好的。

合到一起的话，在第三个查询里面用 count(distinct) 把前面两次查询的结果算出来应该就可以了。

这种事情要看文档的


在 C++ 里，容器上的 const member function 是线程安全的。
然后在这里面 https://en.cppreference.com/w/cpp/container/map

const T& at( const Key& key ) const; 是线程安全的
T& operator[]( Key&& key ); 不是线程安全的，所以从 specification 的角度来说，有两个线程都在 m[key] 也是错的。
insert 当然不是线程安全的，明显不可能

必须所有线程上都只使用 const member function 才没有 data race，所以实际情况通常是这些操作全都要加锁。


Java 的 HashMap，https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html

If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.)

添加删除都需要加锁，修改一个已经存在的 entry 不需要。

@zhangysh1995
如果他发的 SQL 是对的，那个 cte 等价于

SELECT id
FROM A
LEFT JOIN B ON A. id = B. id
LEFT JOIN A AS parent ON B.parent_id = parent. id
WHERE A. uid = 41 AND (A.type = 2 OR (A.type = 3 AND parent. id IS NOT NULL))

然后这个 cte 也不用写 cte，直接和下面的 JOIN 写在一起就好了


另外这个 EXPLAIN 明显不是 PostgreSQL，我也没看出来这是什么数据库

```
创建新回复过程中遇到一些问题：
请不要在每一个回复中都包括外链，这看起来像是在 spamming
```
@Livid 这个外链的检查也太敏感了吧

> D 表的（ DELETE_FLAG,ID,aid ）也加了联合索引

D.ID 在这个查询里就没被用到


这个 SQL 里面，E 就是 A，t 也是 A，最外层写了一个 A INNER JOIN A ON A.id = A.id ，确定是这样的么？


这个 SQL 写得有点奇怪，比如还有一个问题是 cte 里面不用写 UNION，一次 SELECT 就可以了。
先把它整理清楚了再优化吧。

> 客户端 app 的代码是安全的，没有被反编译查看

如果这个假设成立，只要在客户端代码里判断一下服务器的证书是不是你的证书，问题就解决了。

密码学的一个常识是不要自己写代码做加密，不要做额外的加密，没有用。

@dawniii
不让用 JOIN 的话，只能这么拆着查。
而且我也说了用 JOIN 应该更快。

重点其实是不用 JOIN 就不这么建表了。

用不用 JOIN 只是不同的观点，并没有什么优劣之分，如果 JOIN 那么不堪，这些个数据库还做这个功能干啥。
如果表是按照关系型数据库范式设计的，在上面做查询当然要用 JOIN 。不用 JOIN 有不用的玩法，从一开始就不一样。
PostgreSQL 在 2008 年加的 hstore，2012 年加的 JSON，都是反范式的功能。在反范式的表上不用 JOIN 来查询就很正常了。

@dawniii

这种情况不叫一对多，叫多对多。
一对多应该把表做成这样，不需要中间表。
article(id, ...)
tag(id, name, article_id)
author(id, name, article_id)

这种全用中间表不带冗余字段的设计，是符合关系型数据库范式的表结构，在这种表结构上当然要用 JOIN 。
不用 JOIN 的话表就不这么设计了，比如用 PostgreSQL 的 JSONB 数组来存 tag，直接放在 article 表里面，建一个 GIN 索引。

即使是这样的表结构，不用 JOIN 当然是可以查的，只不过比用 JOIN 慢。
SELECT id FROM tag WHERE name = XXX 取出 tag_id
SELECT article_id FROM article_tag WHERE tag_id = xxx 取出 article_tag_ids

SELECT id FROM user WHERE name = XXX 取出 user_id
SELECT article_id FROM article_author WHERE author_id = xxx 取出 article_author_ids

SELECT * FROM article WHERE id IN(article_ids1) AND id IN (article_ids2)

但是，
前两个 SQL 合并成 SELECT article_id FROM tag INNER JOIN article_tag ON tag_id = id WHERE name = xxx 当然会比查两次要快。因为这个 JOIN 没有带来额外的开销。我觉得即使是 MySQL 也能正确地执行这句 SQL
后面两条也一样。

如果全都合在一起，
SELECT article.* FROM article
INNER JOIN article_tag ON article.id = article_tag.article_id
INNER JOIN tag ON tag.id = article_tag.tag_id
INNER JOIN article_author ON article.id = article_author.article_id
INNER JOIN author ON author.id = article_author.author_id
WHERE tag.name = xxx AND author.name = yyy
GROUP BY article.id

这个 SQL 也没什么问题，JOIN 仍然没有引入额外的开销，而且还比上面那 5 句好懂。
但如果用的数据库是 MySQL，这个 SQL 很有可能被用奇怪的方式来执行，那当然就慢了。
这就是很多人说不能用 JOIN 的理由。

@5200
请假天数当然没有限制，只要开得出来医院证明，就能一直请假。
不然真需要长期病假了难道推着病床去上班么。
如果有限制，那是公司自己随便定的，不管用。
病假期间的工资会减少，政*府*有规定下限。

政*府 居然不能发?

@zhongjun96
ORDER BY IF (age=24, id, 2147483647) ASC, id DESC

如果是别的数据库可以用 null 然后 asc nulls last，MySQL 不支持这么写，只能放一个大数字了

不过，有 100 多万行的话，这样也许会比较慢。
查一个 WHERE age = 24 再另查一个 age <> 24 可能快一些

ORDER BY IF (age=24,-id,1),id DESC

都用上 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 只能照着实现。