同表多并发查询性能极差，异步编程不适合磁盘数据读取场景吗？

核心错误点 #

• SQL分页逻辑性能灾难：你用的ROW_NUMBER()偏移分页，每次执行都需要对全表做排序计算行号，开N个并发任务等于重复执行N次全表排序+扫描，性能远低于单次全表查询，数据量越大性能衰减越严重。
• 数据库连接使用错误：如果多个Task共用同一个数据库连接，绝大多数数据库的连接实例不支持并发操作，会引发连接锁、死锁甚至连接崩溃，直接导致任务无法返回；哪怕用连接池，短时间发起大量并发连接也会占满连接池，后续任务排队阻塞。
• 集合线程安全问题：List<dynamic>本身不是线程安全的集合，多个Task并发调用AppendItensToDataList往同一个List写数据时，会出现竞态条件，轻则数据丢失、重则程序崩溃，这是你方案无法正常返回的直接原因之一。
• 分页边界逻辑错误：你按numberOfTasks * chunkSize计算分页范围，如果表的总行数超过该值，超出部分的数据会直接丢失；如果总行数不足，又会执行很多无意义的空查询浪费资源。

异步编程在磁盘/数据库这类IO密集场景下的收益很高，你当前的问题都是用法错误导致的，和异步本身的特性无关。

优化方案 #

• 替换分页方式：放弃偏移分页，改用键集分页（Keyset Pagination），如果你的排序字段firstColumn是主键/有索引的唯一字段，SQL可以改成SELECT * FROM {currentTable} WHERE {firstColumn} > 上次查询的最大值 ORDER BY {firstColumn} LIMIT {chunkSize}，无需每次全表排序，查询性能提升10~100倍。
• 控制并发量级：数据库的并发查询能力有上限，并发任务数控制在2~4即可，过多的任务只会引发数据库的IO、锁竞争，反而拖慢整体速度。
• 修复线程安全问题：要么每个Task单独持有自己的结果List，所有任务完成后再合并到总集合；要么改用线程安全集合如ConcurrentBag<dynamic>存储结果，或者对写集合的操作加锁。
• 规范连接管理：每个Task使用独立的数据库连接，用完即释放，不要全局共用同一个连接实例。
• 更优全表导出方案：如果目标是导出全表数据，无需分页也不需要把全量数据加载到内存，直接开启数据库游标流式读取数据，边读取边写入压缩包，内存占用极低且不会触发查询超时。

进阶学习资料 #

• 《SQL性能优化方法论》：覆盖常见查询优化场景，包括分页、索引的正确使用方式
• 《C#并发编程实战》：详解.NET平台下异步、多线程编程的常见坑点和最佳实践
• 你所用数据库的官方开发文档：重点查阅查询优化、连接管理、批量操作相关章节

内容的提问来源于stack exchange，提问作者Daniel Hadad