如果一个数据库 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 盘上加一个单片机之类的东西来检测文件的哪个部分在哪个时间被读过

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

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

1. 先查一下符合这个条件的记录有多少，你这个查询的总开销就取决于这部分有多少条记录
where device_code= device_code and created_at>= start and created_at <= end
这个过滤条件全都可以用索引，应该可以很快

2. GROUP BY DATE_FORMAT(a.created_at, "%H")
这个写法显然比必需的开销大

@geelaw
> RSA 这个名字既可以指代使用 RSA trapdoor 的加密方案，也可以指代使用 RSA trapdoor 的签名方案。

RSA 这个名字还可以指代 RSA 算法本身。或者说，这里列出来的几个基本操作 https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Operation

> 首先你需要定义“本质”。

我原本的意思是，可以任选一个密钥来加密，用另一个密钥来解密，在加解密的过程中不需要区分哪个密钥是哪个密钥。

> 为什么不能把 RSA 加密的公钥、加密算法当作 RSA 签名私钥、签名算法，把 RSA 解密的私钥、解密算法当作 RSA 签名公钥、验证算法？

这是四个问题，其中一个是，为什么不能把 RSA 加密的加密算法当作 RSA 签名算法。
这就是楼主问的问题
对于任何一个教科书上有答案的问题，你都可以回答说“教材上是这么写的”。所以我说你的回答是正确的废话。

> 你想象中的攻击并不一定能够成功。

你好像完成不懂密码学上的攻击是什么。一个攻击成功的概率高于暴力破解的概率，就算作一个攻击了。
你可以自己写代码去试试这个方法的成功概率有多少，当然不写代码也应该知道这个方法成功的概率大约是什么水平。
如果你认为这个方式能起到签名的作用，那你真的“需要阅读密码学的教材”了

某个东西是 “ private class member ” 就不继续往下深究了，我不认可这样的学习方式。

@geelaw
你有没有意识到自己回复的内容是正确的废话?
楼主问不混用的原因，你回答说这东西就这么规定的

在 RSA 里面，公钥和私钥没有本质的区别，公开的那个叫公钥，不公开的叫私钥。用公钥做加密是加密，用私钥做加密是签名。
至于怎么规定的，那是另外一件事。规定的那个方法当然是正确的方法，但楼主问的是为什么另一种不正确。

楼主问的问题其实很简单
如果用私钥加密得到密文，然后把密文改掉，再用公钥解密。这样也可以解出来一个结果，但是这个结果和原来不一样。签名的目的是确保收到的消息正确，所以这样做不可行

这事和性能毫无关系。
类似的情况在对称加密里也有，confidentiality 和 integrity 是两件事，要用完全不同的方法来做，看看 AEAD 的实现就懂了。