从开发的角度来说，如果你见过光 bean 就有十几万个，连编译脚本都需要专人维护的大屎山，那微服务存在的必要性应该也不用解释了。

至少你一次吃的是一个小山包，而不是一次得吃一座山脉

楼上几位有些理解有点小问题

平时交的五险一金里的养老保险现在的本质现收现付制是 *保险* 而不是你的个人 *储蓄*

但是个人养老金是公积金的模式，和现在的 “住房公积金” 差不多，是你的个人 *储蓄*。当期个税减免，所有权归你；但是是定向储蓄，必须锁定到条件满足（退休、丧失劳动能力、死亡）时才能按条件取用。另外有个好处是可能以后 *可能* 会有比市场一般的理财更高的收益率，毕竟这个资金池很大

但是讲道理，按现在的收益率来看，不是个税高到不行的完全没必要。自己管的住不乱用钱，拿出去做点投资，比现在的个人养老金靠谱

1. chatgpt 说话信一半就行了
2. py 的 queue 本身都是多线程安全的，queue.Queue 用 mutex 实现，queue.SimpleQueue 用 semaphore 实现
3. 使用 semaphore>=2 的情况下，算是多个生产函数往 queue 添加数据，但是因为 queue 本身多线程安全，所以问题不大
4. semaphore 和 mutex 可以认为是对于一组资源的不同保护策略，针对一组资源一般只用一种策略

允许假阳性存在的话可以考虑布隆过滤器，线性时间能应该就能搞定了

*如果不是一道 SQL 题的话

@copper20 如果 a b c 都来自全体整数的话就可以先把整数集映射一一映射到自然数集然后再套康托尔那个函数

if z >= 0, f(z) = 2 * z
if z < 0, f(z) = 2 * -z - 1

假设你的 a b c 都是 int64 ，那么这个需求是不可能实现的。这个函数

f: int64 x int64 -> int64

定义域的基数远大于陪域的基数，就不可能是一个单射，是必然会发生碰撞的

如果 a b c 都来自全体自然数集，那按康托尔的那个配对函数来就行了

追求开源也不是追求国外程序员的生活吧

开源只是一个开放自由的社区而已，和国籍没啥关系

开源社区的精神某种程度上不是挺社会主义的嘛，每个人开源出去的产品都为开源社区所共有，每个人的生产工具（编译器、IDE 、中间件、……）又从社区中自由获取

@wxf666 把等于运算符换成 IN 运算符吧 比如就 county IN (1, 3)

如果单独考虑这个需求的话，或许可以把 city 和 county 挪到另外的表里存。设计 foo_city(id, city) 表和 foo_county(id, county) 表，id 和 city / id 和 county 都设为主键（就是说直接设计两个关系表），然后在这两个表上分别建 city 字段和 county 字段上的索引，另外在现在的 table1 的 province 上也建立索引

捞数据的时候可以直接：

(SELECT
table1.idtable1
FROM
table1
INNER JOIN
(SELECT
idtable1
FROM
foo_county
WHERE
county = <county code>) co
INNER JOIN
(SELECT
idtable1
FROM
foo_city
WHERE
city = <city code>) ci
WHERE
province = <procince code>)

不过话说回来，地区代码这种事情用 varchar 存国标的地区代码，检索的时候直接用 LIKE "110101%" 之类的，用得上索引，而且代码上会方便许多吧

简而言之，更帅，更优雅

q 轻度使用可以考虑用手柄

越过长城，
走向世界！

躺平不是*丧失*买房婚配和生育权的原因，而是*选择*不去买房婚配和生育的结果

百度网盘大概率不会授权阿里网盘 --> 阿里方只能通过类似于爬虫的技术获取文件 --> 商用爬虫大概率也需要授权 --> 百度网盘大概率不会授权阿里网盘

“xxxx 学前班”

看目的，看时间。以前为了赶作业，连回调函数是什么都不知道就开始用 vue 了。

“我在 xx 路上，南向北方向那边，靠近 xx 路口，这侧路边有个 kfc”