返回 func 可以链式调用？ func(list)(list1)(list2)

SQL 适合数据处理，清晰的业务处理，但不适合嵌入复杂的业务逻辑。比如考虑节假日，这明显就不适合纯 SQL 做。

我目前就在用 go 写业务，说实话，不合适。虽然是强类型，但是类型系统弱，需要写大量的代码去处理类型 /数据结构上的转换和封装，判断 err ，判断 nil ，语法糖基本没有。

select
class_id,
course_id
from (
-- 根据每个班级下的选课人数, 给课程确定顺序
select
class_id,
course_id,
stu_cnt,
-- 根据选课人数降序
row_number() over (partition by class_id order by stu_cnt desc) as r
from
(
-- 先统计每个班级, 每个课程的选课数量
select
class_id,
course_id,
count(1) as stu_cnt
from
t
group by
class_id,
course_id
) as t1
) as t2
-- 课程排第一的数据
where r = 1;

这种如何：

先拿到用户已使用的产品列表（数据规模较小 ）：

select * from 产品 as a
where exist (select 1 from 产品使用情况 as b where b.用户 ID = 目标用户 ID and a.产品 id = b.产品 id and status=已使用)

其中，产品使用情况表只存储用户有使用过的产品，没有使用过的不要存储。如果用户曾经使用过某个产品，但后来又不使用了，可以更新状态，或者删除记录。

然后在查询的时候排除掉已使用的产品：

select * from 产品
where 产品 NOT IN (用户已使用的产品列表)

我认为是对的。但是 python 是解释型语言，应该先从解释器角度去理解。

比如 https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe

描述到，python 解释器的执行单元是字节码指令。字节码指令背后的所有 C 语言代码执行也是“原子操作”。当一个字节码成功执行后，其他线程才有机会拿到 GIL 。

CPU 还有各种缓存和指令执行顺序问题，那就更加复杂了。

@jmqrock2020

总之，有多线程就要考虑并发读写变量的情况

python 不是有一个 GIL 锁吗，理论上是可以多线程同时操作同一个列表对象的。当然最好的方法还是用自带的 Queue (有多线程和多进程的版本).

为什么都搞小程序呢？写成博客或者 CMS 不是更好吗，并且也可以被搜索引擎收录，给中文互联网增加新内容

我的方法：将字符串解析成可处理的 HTML 对象, 找到标签 span, 检查内容是否符合条件，然后替换标签。替换结束，再序列化成字符串。

比如用 DOMParser 解析： https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

同建议定时任务，每次扫数据库就可以了。
等到数据量大，延时不能忍受的时候，再考虑其他优化方案。

docker-compose 输出带转义序列的编码(ANSI 颜色代码, ANSI escape sequences, ANSI color codes)的日志，最好的做法是除掉转义。

0. 关闭 compose 的 ansi 输出. 看文档似乎 --no-ansi 可以关闭
1. 输出管道中间加个可以去除转义的程序, ansi2txt 或者 sed 替换
2. 切换到 非 tty 模式(一般程序检测到 tty 才会输出颜色编码), 比如 ls -cl < /dev/null |& cat

搜索关键词：drop ANSI color codes,

search after 也可以啊.
确定一条消息的唯一性可用的属性有：发送时间，消息 ID ，消息来源。只要 "消息 ID"+"消息来源" 的组合你如果能保证唯一性就可以。

然后用 search after 搜索，排序用这三个字段，就能保证不重复获取

我是说，有没有可能，列表是一种特殊的树，树是一种特殊的图结构

这样写如何： https://go.dev/play/p/RhnThOFRJwt

当初就是考虑到固戍人多，选择了后瑞。

早上 8 点高峰期，人多可能会在安检的地方会堵着排队，但不会排到地铁站外面。

早上时间早或者运气好的话，有座位。没有座位的话，我就选择靠在车厢连接处，基本不会受到人流上下车的影响。

我只知道 struct 可以只 move 部分字段，在闭包里还没见过部分捕获。


论坛的话，https://rustcc.cn/ 也不错，rustdesk 也在这个论坛上活跃

我分析，编译器认为只有 p.x 被移动，然后 p.x 默认是 i32 类型, 自动实现了 Copy, 所以在 move 闭包下，创建了新的变量, 复制了 p.x 的值。

如果 p 里面有其它不可移动的字段，然后在 move 闭包里面 进行了操作，那么无法通过编译。


https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a93e02138c3df6841f402b0ccbb7d7be

myiasm => myisam

https://dev.mysql.com/doc/refman/5.7/en/internal-locking.html

myiasm 是表级锁，innodb 是行级锁

不管是写操作还是读操作，myiasm 只需要对表检查一次锁，开销小，范围大； innodb 读取写入每一行记录都要检查锁，开销大，范围小。

多个读锁可共享，写锁要独占，因此 myiasm 适合读，innodb 适合写