这是一个非常经典的“软件并发 (Concurrency) 与硬件并行 (Parallelism) 碰撞”的系统级问题！
简单来说：DuckDB 的 PRAGMA threads 决定了任务被切分成几份（软件上的工人数量），而 taskset 决定了这些工人被允许进入哪个车间干活（物理硬件资源）。
针对你提到的三种情况，Linux 系统的行为和产生的性能后果截然不同：
1. 设了 2 个线程，但只绑定 1 个核心 (taskset -c 0)
结果：性能劣化，不如单线程。
- 底层发生了什么： DuckDB 以为自己有 2 个线程可用，于是把 12 亿行数据切成两半，交给 Thread A 和 Thread B 同时处理。然而，
taskset像一道铁墙，把这两个线程死死关在了 Core 0 这一个物理核心里。 - 微架构灾难：
- 上下文切换 (Context Switch)： Core 0 无法同时执行两个线程，只能通过操作系统的调度器（CFS）在 Thread A 和 Thread B 之间疯狂切换。保存现场、恢复现场会浪费大量时钟周期。
- Cache 踩踏 (Cache Thrashing)： Thread A 刚把自己的数据加载到 L1/L2 Cache，时间片耗尽被踢出；Thread B 进来后，立刻覆盖掉 A 的 Cache 数据。当 A 再次进来时，面临的将是海量的 Cache Miss。
- 结论： 纯粹的负优化。CPU 把宝贵的算力花在了调度和等待内存上，耗时通常会比纯单线程（
threads=1+taskset -c 0）还要长。
2. 设了 2 个线程，绑定了 2 个核心 (taskset -c 0,1)
结果：完美的硬件级并行，性能翻倍。
- 底层发生了什么： DuckDB 派出的 Thread A 和 Thread B，被 Linux 调度器完美分配到了 Core 0 和 Core 1 上。
- 微架构表现： 两个物理核心各自拥有独立的 L1/L2 Cache（甚至独立的执行流水线），它们互不干扰地全速扫描各自负责的那半个表。只要没有触碰到底层的内存带宽瓶颈（Memory Bandwidth Wall），对于 Scan 和 Sum 这种计算，耗时几乎会完美减半。
- 结论： 这是多线程加速的最佳状态。
3. 设了 2 个线程，却绑定了 3 个核心 (taskset -c 0,1,2)
结果：性能与绑定 2 个核心完全一样，第 3 个核心“摸鱼”。
- 底层发生了什么： 你的“车间”里有 3 个工位（Core 0, 1, 2），但 DuckDB 只派出了 2 个工人（Thread A, B）。Linux 调度器最多只能把这两个线程放到其中两个核心上（比如 Core 0 和 Core 1）。
- 微架构表现： Core 2 根本分不到 DuckDB 的任务，处于空闲状态（Idle），最多处理一点系统的后台杂活。有时候，Linux 调度器为了平衡热量，可能会把 Thread A 从 Core 0 迁移到 Core 2，但这并不会增加并发度。
- 结论： 软件的并发度限制了硬件的发挥。多出来的物理核心被浪费了。