不是 ..等等... 我怎么有点晕..
Non-Standard SQL 听起来像是说方言问题 .但是下一步又说到了性能问题...
op 到底是对那部分问题有疑问?

另外....performance 为什么不直接说性能呢, 略微奇怪.

完全新手不推荐弯把. 通勤其实也不适合.
一个小水坑 钢网的排水地漏 都容易摔车.

建议可以考虑平把. 楼上也都说了好多了.

咸鱼 1 块钱起拍..让一堆人抢着玩...

@coderth 我也看到过类似方案 . 加密后存云盘.但是感觉还是不太放心. 毕竟云盘的内容谁也不敢保证一定能保留

@MagmaBlock 是的我也在想这种方案 也是比较适合小容量的用户.

基本零基础 3 年看了两年半的小说 . 一个月左右数学从 30 分左右 提升到了 90 分..

数据就是套公式 .题目都有固定类型 ,.让你妹妹试着理解下就好了.

简单看了下.
比如上 json hero 和 json crack 的搭配使用.

看你具体场景 ,一般是 sqlite 或者 h2 吧.

@ThomasKim hhh 看来我阅读理解太不过关了

@lazywen 正解 . 从公司的运行状态来说 并不称得上算是健康的车企 股票都贬值成什么样子了..
当然股票好 不能说明什么..但是股票那么差.. 我觉得应该是有问题的.

主要是蔚来 还没实现盈利 比较担心.股票形势也非常差.
还有就是蔚来的换电技术短期内肯定不是发展方向.
当然楼上说的 卡罗拉、轩逸 就算了..

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 的版本都老掉牙. 差价也没几个.