mysql 36 讲解 yyds .
有些东西可以不用太去花时间了解 . 比如 数据库如何同步 .
可以多了解下怎么使用索引 ,应该如何高效创建索引.

@laminux29 6W 功率输入的时候还真的 比不过 3 代 i7 这东西跑满能到 25 多 w.

你这个从产品思路上就错了..
首先要做的是软件分类 ,而不是文章内容查询.
看了下你做的软件分类太过于粗糙了.

其次可以再给文章打标签 ,对标签进行搜索 最后搜索只查标题就好了..谁也不会闲着没事记软件的内容的.

N 年前也遇到了和楼主同样的情况,数据量不大. 但是 join 之后就的体积就大了.同样也是查询条件分散在不同的表上.
我当时的做法是用 debezium 重新聚合到另外一张表上 .并适当的做 水平&垂直分表, 一个完整的 etl 流程

https://juejin.cn/post/7207410405786484796
https://juejin.cn/post/7323570678690185242

ps 楼上不少同学对复杂查询的经验不太足, 可能是比较幸运的程序员没有接受过复杂 erp 中各种逆天的 sql
1) 推荐 es 的: 虽然 es 是查询引擎 但 es 的查询侧重的并不是点对点查询 ,op 的问题主要在于 join 后的笛卡尔积太大.
2) 分开查询在 join: 如果你的所有条件都在一张表上是没问题的.如果是多张表那肯定还是数据库直接写 join 吧

同时 @yiyufxst 的经验非常好 数仓其实主要优化的还是复杂查询 ,在内存充足的情况下能保证结果尽量能出来.
@jjx 的提到的 hana 的确可以搞一搞..但是就是价格也不菲.

我感觉几条可行的解决方案是 :

1) 自己写一套 etl 流程.制作宽表
2) 不写 etl 了, 直接全量 all in 到关系型数仓中 ,在关系型数仓中进行查询 (不过数仓也很耗费资源 .并且如果将来数据量大,同样也是会查询失败)
3) 内存之类的数据库 ( 这个我没试过 ,听介绍有可能可以.

你这哪里是 nas 的配置啊.找个板油一体的低压呗

@yjxjn 商业保障+ 数据库性能保障.. 开源数据库性能被商业数据库按到地上摩擦


我自己是 jdk17+ pg13 以上.. 国内云看着对 pg 很熟.. 结果一个个 pg 的版本都老掉牙. 差价也没几个.

200w 的杭州 应该算是比较差的板块了吧..
这种地方就别买了.

其实这个问题的回答已经列举了双方的不同

一个是剑走偏锋的计算机大学
一个是比较均衡的 985 大学

所以取决于你是想把专业当成一个兴趣爱好，还是仅仅一个吃饭的工具。

@mythabc 说的不错。你能离开互联网生态吗？

15l 列举的比较相信.. 变更工具太多了.

哈哈 想到了一个 比较蠢的办法.. 需要查的时候临时在 mapper 那边 override 一个插入方法..
然后看下这个方法调用情况.

@Unlikely 氦气 好像是为了数据稳定性吧... 这种一般是有些追求资料稳定性的万家了.
并且真说起来 全闪比氦气贵多了.

ps 3K 组 nas 我实在没看出来穷在哪里了....

一种精心设计的丑...

提个建议给 OP ..如果真的管控不了那么多元素 ..就尽量把元素简单话..

这一点可以参考阮一峰的博客