最简单的测试方法就是看两种情况下的执行计划就行了，inner join 条件下 on 和 where 在优化器不出岔子的情况下理论上没任何区别，但如果涉及到的表统计信息不对 /不及时，导致优化器出的执行计划两者不一样，或者优化器很笨不知道你写在 on 里的条件能让它选择更好的 join 方式，那肯定还是有区别的

就是前面有一个 v 友说的“在复杂的语句（动辄百行以上），CBO 分析不过来的时候，on 能更好的帮助确定过滤集”。这也是为啥 oracle 支持的 hint 对于数据库工程师来说是超强的利器，你分析不过来工程师自有更好的执行法子限制你不发癫。

outer join 就不谈了，从 on 挪到 where 里结果都可能会不同

@DsuineGP #36 ？？？呃，是在让我反思？？？

总共 698 个
cn 256
edu 162
tw 16
vn 16
com 14
eg 11
pe 9
tech 8
th 8
mx 8
id 7
ph 7
org 7
kg 7
me 7
tr 6
pk 6
ca 6
pl 5
uk 5
net 5

占比 36.68%

“丢不丢人哪”.jpg

@xdeng #3 换句话说国内一套甚至半套一二线城市房子的钱（全款），就已经能随便移民加拿大了？？？
怪不得那么多人跑那么快我靠！

mysql, pgsql 和 mongodb 其实都可以
逻辑上数据量也就几万行，完全无压力，真实数据文件是数据库自己管理的，肯定会分文件管理，只要你磁盘没崩数据基本不会崩，不过得注意定期清理收缩数据库

mysql 用 longblob
pgsql 用 bytea 或者 large objects ( https://stackoverflow.com/questions/4386030/how-to-use-blob-datatype-in-postgres)
mongodb 用 GridFS ( https://www.mongodb.com/docs/manual/core/gridfs/)

@whats #9
除了 spark 和 flink ，
补充一个 Apache Ignite （这个才是和 redis 一类的真内存数据库，支持内存数据表 session 持久化，支持 acid ）

https://stackoverflow.com/questions/36036910/apache-spark-vs-apache-ignite

不过所有内存的东西不落盘都不靠谱，即便你能用上持久化内存也一样，所以你得切分清楚哪些东西是进了内存库后往里读 /往外写了一半全丢了也不要紧

月经贴
目前来看未来个鬼
不可能三角总得舍弃一个或者妥协两个，然后 web3 变 web2.5

不过人类如果会为了追求 “可信任”、“不可更改”的去中心化 而放弃 “高效率”的中心化 /半中心化，那真是可以想见的生产力倒退

不说数据量？
你内存要够大到几个 T 的地步，那确实一般情况随便上内存数据库做运算只把最后结果落盘啊？但数据量一大起来，几个 T 也不够看的