这是一个创建于 796 天前的主题，其中的信息可能已经有所发展或是发生改变。
分析性业务，100 个 SQL 产生 400 个标签，但是其实 100个 SQL 使用的只有 20 张表，并且 WHERE 后的查询条件大多一致，根据 uid ，并且这 400 个标签在高 QPS 的接口中，所以为了减少 DB 压力，现有执行计划是先执行 20 个表的 SELECT ... WHERE ，并且把数据存储在内存中，在内存中使用 pandas 进行之后的 join 、aggregate 等操作。现在的问题是把 SQL 转 pandas 的操作非常痛苦，并且很容易出错。 所以希望能在内存中通过 SQL 直接做计算逻辑，golang 或者 rust 有没有类似可以在内存中通过原生 SQL 做计算的库？
- 我对 mysql 比较小白，想问一个问题，mysql 会对短时间内类似的查询做缓存吗？也就是说我以上的方案是否真正节省了成本？
 | 1 thinkershare 2023 年 11 月 20 日 直接上存储过程不行吗？为什么一定要在 go&rust 中做？ |
 | 2 wenhuacode 2023 年 11 月 20 日 你的数据是直接抓的生产库？我觉得搭建一个备数据库然后从这个专用的数据库去执行 sql 吧。 |
 | 3 leonshaw 2023 年 11 月 20 日 sqlite? |
 | 4 yellowmarlboro OP @wenhuacode 的确是在备库中查的，但是没有把所有 sql 都直接查 db |
 | 5 baihekong 2023 年 11 月 20 日 加个从库 |
 | 6 sujin190 2023 年 11 月 20 日 @yellowmarlboro #4 其实既然都是备库了，sql 库无论 sql 执行效率和内存效率都是最高的了吧，你自己搞个内存计算的既不如数据库高效也不如数据库稳定，性能不够多搞几个备库节点就是了呗，网络消耗的其实无所谓了吧 更进一步其实可以直接在应用节点搞个备库就是了呗，或者用 sqlite 也行呗，没必要非要搞个内存执行 sql 吧 |
| 7 sujin190 2023 年 11 月 20 日 @yellowmarlboro #4 数据库也是可以当作普通软件用的吧，mysql 什么针对特定场景优化配置其实内存消耗可以非常低的，容错了简单，本地库查挂了就再查一次主库就是了，再搞个监控解决了 |
| 8 yellowmarlboro OP 谢谢大家 我其实也在想这样是不是多此一举，脱裤子放屁又要造轮子的做法，但是要验证的确需要理论支持实验测试才知道。感谢大家的意见 |
 | 9 misoomang 2023 年 11 月 21 日 是否可以采用 MySQL 临时表的方案解决该问题 所有的表数据查询后都汇总到临时表中，然后在临时表进行 join 、aggregate 的操作，断开数据库连接后临时表也会自动回收掉 |
 | 10 dayeye2006199 2023 年 11 月 21 日 via Android saline in memory |
| 11 dayeye2006199 2023 年 11 月 21 日 via Android Sqlite in memory |
 | 12 qieqie 2023 年 11 月 21 日 存本地数据库，duckdb 比 sqlite 更适合分析型任务。 |
Select Language