你可以直接忽略掉这一条，直接 JOIN 就好了，没什么不行的
不过，你需要知道自己写的 SQL 到底做了什么；或者如果你不用 JOIN，你也需要知道自己的多次查询再合并到底做了什么

如果你用的数据库不是 SQLite 或者 MySQL 这一类的，那么 JOIN 通常会更快

这种事情只有测试过才能知道

优先级会影响内核在调度时的选择，操作系统当然会尽力把 CPU 分给优先级高的进程，但普通的操作系统不能精准地把 CPU 恰好分给优先级最高的进程

另外当然还存在各种各样其它的影响

把 PostgreSQL 的文档里关于 SQL 的部分全看一遍，然后去拿 SQL 写各种本来不该拿 SQL 写的东西

比如 https://github.com/crvv/sql/blob/master/brainfuck/interpreter.sql

如果一个数据库 instance 搞不定所有的读写请求，那么你可以使用多个 instance 来搞
有不同的方案来使用多个 instance，读写分离是其中的一个
或者说你也不一样要完全读写分离，只要把一部分读请求分走，也许就能好了

> 如果是异步同步，可以保证写主库成功之后返回，但保证不了延迟。比如写完马上读就会有问题

是会有问题，但有的业务可以接受有这个问题，或者用另外的手段处理这个问题。
或者你可以只把不需要强一致性的读请求分走。

> 如果等待同步从库成功后再返回，实际就是双写。那么故障几率就更大了，可用性就会降低

出故障的概率会变大，但是数据出错的概率会变小。某些情况下可以接受系统挂掉但是不能接受丢数据。

而且这么干的前提是你用一个 instance 搞不定，搞不定的事情就没有可用性，现在能搞定了才有了可用性。
这里不应该说可用性降低了。

你的需求不够清楚

你要算哪些数据的 sum? 是全表的 sum 还是用 WHERE 筛选过的一部分的 sum?
如果是筛选过的，筛选过后有多少条数据？

如果筛选过后的数据量小，那么问题在于你的查询没有利用好索引。
你的查询有可能本身不可能被 MySQL 的索引优化，那么解决方案是上更高级的索引（比如 PostgreSQL, Elasticsearch ），或者上 OLAP。

如果筛选过后的数据量大或者没有筛选，那么这个问题用符合范式的关系型数据库不可解。
你可以选择上 OLAP。
也可以选择在某个地方加上汇总过的数据，这个取决于具体的需求。

对一部分人来说 a 和 A 是两个字母，但是对另一部分人来说 a 和 A 是一个字母
同理，快速的火车 和 快速地跑步，对有的人来说，的 和 地 是同一个字

这太正常了，人和人之间的区别可以远比这大得多

@Sweden

“要手术的病不可能漏沴”
这句话显然是错的，比如早期的恶性肿瘤就是要手术且可能漏诊的病

可能我们去过的三甲医院没什么交集
我在三甲医院甚至是那种全国著名的医院见过不少不靠谱的医生，也在二级一级医院见过不少靠谱的医生

交流障碍和医疗水平本身没有关系

@Sweden

假设以当前的情况判断，得上某个大病的概率是 1%，做手术（或者类似的代价高的方法）才能确诊并治愈，你觉得医生要不要让你做手术，你自己愿不愿意做手术？

以我的见闻，中国的医生会直接忽略这个病。因为
1. 大概率被病人认为是白花钱受罪，出力不讨好，可能被怪罪（病人抱怨医生给做了一堆没用检查的例子太多了）
2. 如果最后的确是漏诊了，医生当时的判断也不能算错，该不该用代价高的手段去做治疗本来就不好说
3. 医院靠卖药挣钱，做手术没多少利润

我从来没听说过这个 KI，但如果是那么高端的医院，我认为医生会考虑这些概率比较小的情况，并且给病人讲清楚当时的情况。以回帖的描述来看，医生说的不可能是 “ 100 % 确诊就是这个病不做手术会死”。那么最后要怎么治，应该由病人自己选择。

我从来没在国外看过病，但稍微了解一下就能知道，国内的医疗状况很差，尤其是上面说的这个点。

中国和发达国家的医疗服务的价钱相差很多，根据每个人自己的想法，当然可以认为国内的性价比远高于国外，这是另外一回事了。

@Greenm
把单引号替换成两个单引号确实不是好方案，但是楼主说了用的是 SQLite，这个做法是对的
SQLite 和 PostgreSQL 里，字符串里只有单引号是特殊字符，反斜杠只是反斜杠

尽量提高实时性，可以运行在硬实时系统上

这句话前后矛盾
硬实时系统上没有尽量一说

感觉你们低估了 real time 这件事情，随意设定了一些自以为重要的标准

用 SQL 至少有两种写法吧

SELECT count(*) / 2 AS pairs
FROM user_relation a
INNER JOIN user_relation b ON a.friend_uid = b.user_id
WHERE a.user_id = b.friend_uid;

SELECT count(*) / 2 AS pairs FROM (
SELECT user_id, friend_uid FROM user_relation
INTERSECT
SELECT friend_uid, user_id FROM user_relation) AS subquery;

个人认为 JOIN 是 SQL 里最普通的写法

如果连 3 都不过写，这活就别干了，从头学一下 SQL 再说

如果要分表，也不是 1000 行就分的，你说 1000 万行分一个表好像还可以接受

直接搞两个表完事，肯定比你这么折腾出来的快

这里不是为什么要构建 FA 的问题

正则表达式不是专门为了做字符串匹配设计出来的东西，这玩意是从学术研究那边来的
Finite Automata 是某门课讲 Turing Machine 之前要讲的东西，这课要讲它和正则表达式是等价的，还有证明
从这个角度来考虑，用 Finite Automata 来实现正则表达式是最普通的做法，所以他们不给你解释为什么要用

至于能不能不用，当然可以。现代的正则表达式为了做字符串匹配加了其它功能，用 Finite Automata 已经不能实现了，其实通常都没用

https://math.stackexchange.com/questions/2705692/regular-expression-vs-finite-automata

https://swtch.com/~rsc/regexp/regexp1.html

@dychenyi

只考虑防拷贝，不考虑楼主其它的所有奇怪要求，即使是 Sony 这么大的公司，从硬件开始全都自己造，也一样没有实现

不同的方案只是在预算多少，好不好用，能防多牛的用户几个点之间权衡

楼主在回复里反复强调过要求用系统原本的播放器，前面有人说这个要求的预算得换成比特币

我提了一个似乎符合这个要求的方案，看起来也不需要 200000 BTC 来做，那我自认为已经很靠谱了

“客户要求是机子上面有什么播放器就用什么播放器。不用特制的播放器就能播”
如果这一条是硬性要求，那你的需求是一个 gfw
如果用户在做你不想让他做的事情，就把连接断掉；如果他在做你允许的事情，这个系统就不存在。

在 U 盘上加一个单片机之类的东西来检测文件的哪个部分在哪个时间被读过

播放器播放视频文件的读文件模式和操作系统复制文件的模式必然不一样
你们可以去把所有播放器读文件的模式测试一遍，如果像是在复制文件（以最大速度连续读文件）就把连接断掉

好像可以符合所有要求，如果你们有时间去做测试和优化，我估计结果可以很好