Closed John0King closed 3 years ago
如果你数据库 select count(*) from 返回值能达到 LONG可以说 你一个小时也查不出来
COUNT 会全表扫描 超过 1000W就会很慢 更别提INT.MAX了 ,任何用 COUNT去查 1000W条记录以上的表都是不可以行的, 因为用了COUNT你查很久,不用COUNT查前几页很快
异步查询 https://www.donet5.com/Home/Doc?typeId=1189 用法很明确了
RefAsync
@donet5 我有点不信,真要是这样,那么 count_big的出现就有点不太合理,明天我就试试,填充10亿条数据试试
https://www.cnblogs.com/jacker1979/p/4661125.html 1亿能上1分钟已经优化到极限了 INT.MAX是几十亿
填充到了2kw , 目前执行的时间是 2s , 实际开销是 扫描聚集索引的时间 BigCount |----------| 20854144
不排除是 docker wsl 跟 win 文件系统的性能问题导致的
1亿10秒 21亿 210秒, 你分页光统count 就几分钟 合理吗?
如果只查询几条几秒就出来了
这只是21亿最理想的时间 210秒, 数据越多 后面运行速度越慢
@donet5 大佬, 我最后用Dapper了, 主要是查询太复杂有 with , 有临时表 , 而你们的方法好像一定会 包裹一层,不能使用原始的Sql查询, 导致查询报错, 不知道是不是没有找到相关的配置或者什么。
目前的打算是 先用 dapper搞, 以后有新的 Sql 再用这个库, 另外我有点担忧这个库 再 .net 4.0 上面是否有缺陷
db.ado.SqlQuery 不会包一层
如果一个表,自增字段采用
BIG_INT
, 且个数大于Int.MaxValue
, 那么现有的ToPageList
应该会出现问题,long
ref
和out
跟 异步有天生的相对性, 这个应该建立一个自己的类,PagedResult<T>
, 不应该集成 IEnumerable, (或者 ValueTuple)