上万条数据, 短时间内连续查询几千次, 是数据库查, 还是内存查更好一点?

[bthulu]

客户库存有一万多, 要将这一万多库存按客户要求分散到几百个工位上, 需要针对库存的多个属性进行多次查询, 循环里套循环, 能查上千次甚至更多.

这种情况下, 我是直接数据库查, 还是将数据一次全拉到内存, 在内存里查更好?

数据库查可以走索引, 内存里可就没索引查一次就是全量遍历一次了. 如果有内存里支持索引的列表就好了. 语言是.net8.

别说什么优化查询方案一次查询搞定的了, 这不可能. 现实业务就是各个工位之间关系也是错综复杂, 只能这样查了.

[seers]

设计数据库的又不是傻子，你这种热数据肯定读到内存缓冲池后后面都是从内存读了，有时候真的建议多看看数据库设计原理

[vance123]

@seers 数据库处理这几千个请求就得创建几千次线程，这不耗费资源吗？

[seers]

@vance123 还是那句话，设计数据库的又不是傻子，数据库内部有线程池实现，提问前多动动脑子

[cnbatch]

那就复制一份数据到 redis 再查

dotnet 8 的话，还有另一个选择：微软最新推出的 Garnet ，也是用 dotnet 8 写的，是 Redis 的替代品

[ZZ74]

才几千次，还能走索引，怕个球。来点护城河，还可以把一小部分逻辑变成存储过程，就更不用担心了

[kb666]

一万多条其实很少了.. 你可以先用数据库查，看看性能表现

[night98]

最简单的直接根据你要的属性去分组就行了，不会占多少内存的，速度嗖嗖的。

[lvlongxiang199]

动手实现一遍, 之后压测试试呗

[kongkongyzt]

其实这些数据并不多的，直接内存查吧，走 MySQL 的磁盘 IO 很慢的

[jackOff]

有一种很愚蠢但是可能非常高效的做法，就是把上万条数据全部在一个目录下一一对应生成本地文件，查询的时候直接判断对应路径是否存在，这个理论上的时间复杂度是 o(1)，如果你查的数据不敏感并且更新数据比较少+懒惰的话你可以试试这个

[moyuuuu]

精确查找还是需要范围查找？

如果是精确查找，可以用 HashMap 数据结构存，key 是 width ，value 是一个列表，那通过查询 key=800 就能直接查出那几十条 width=800 的数据；

如果需要范围查找，可以定义一个按需要查询的条件排好序的列表，然后写一个简单的二分法进行查找最小值，然后再进行遍历，直到最大值的时候停止，这样比遍历全部数据效率要高得多；

如果是有多个需要查询的条件，那就需要为每一个查询条件创建一个 HashMap 或者有序 List ，其实就跟数据库的原理一样，通过多个条件查询查出来后，将结果做一次交集，就是最终需要的结果了。

当然，这样肯定会增加开发成本，就看你怎么权衡了。

[moyuuuu]

@moyuuuu 其实就是仿数据库的索引一样，在内存手动给每个字段做一个索引

[jianchang512]

mysql 表使用内存表，ENGINE=MEMORY ，这么点数据都放内存。只需要改表类型，其他都不需要动

[goldenAndGreen]

10000 的数据量, 直接放内存 list, for each data line, 用你的所有条件 filter 就行.
一次 filter 不行要么就属性打平做大宽表, 那么多做 filter,存内存肯定比 io 快

[laminux29]

机器配置，系统架构，业务逻辑，啥也不说，鬼看了都难搞。

万一楼主的服务器是 J1900 上的 PVE 里的虚拟机里的 docker 呢？

万一楼主的服务器接在一台百兆交换机上呢？

[mingl0280]

一万多条数据，你直接内存数据库查就行了，剩下的都不用你管（量太小了）

[GeruzoniAnsasu]

30 秒一次，单机数据库，无并发，总共就一万多条数据

…… 这么点压力应该远远没到需要优化性能瓶颈的地步吧

[opengps]

你要做的工作远不止这个问题，而这个问题实际写代码测试一下，你收获的结果会更多

[bianhui]

dotet 不是有 Linq 吗？而且这种情况通常最好的建议是，通过业务逻辑，用几个字段对表数据进行分组。
例如：有个数学成绩属性，全班有 30%数学成绩在 80+，40%是 60+，30%是 30+，全班 60 人，你不应该无脑查询 60 次，也不应该一次全查出，你应该是先查出 80 分以上的，然后再内存中对这些数据进一步筛选。这样一共查下三次，内存容量操作也适中。反正大概这个意思，做业务开发不要脱离业务逻辑。

[klo424]

我觉得这应该是个算法问题，而不是查询问题。