CLR 存储过程中的多线程代码？
多线程 CLR 存储过程可能吗？
我有一项数据密集型任务，具有很大的并行化潜力。 CLR 存储过程非常适合消除将数据移出进程的开销，但我担心我必须放弃并行计算。
我有什么选择？
注意：我们使用的是 SQL Server 2005，计划在 <<升级到 SQL Server 2008 的时间为 4 个月
Are multi-threaded CLR stored procs possible?
I have a data-intensive task with lots of potential for parallelization. CLR Stored Procs would be great to remove the overhead of moving the data out of process, my I fear that I'd have to give up parallel computing.
What are my options?
Note: We're on SQL Server 2005 with plans in the < 4 month range to upgrade to SQL Server 2008
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果是数据密集型且具有并行化潜力，您应该以集合为导向的方式处理它，并让SQL按照它认为合适的方式并行化处理。在对每个 CPU 的数据访问进行分区方面，您将无法做比 SQL 更聪明的事情，它只是可以访问您无法访问的信息（缓冲池填充状态、页面预期寿命、CPU/NUMA 关联性等）。
如果您的处理是面向标量和 CPU 密集型的（甚至是一些面向集合的处理），请将处理放在 UDF CLR 函数中，然后再次让查询执行并行化您的函数执行。
如果您的处理有任何类型的 I/O（即 Web 调用），请不要将其放入 SQL 中，而应放在服务器进程之外。
如果您的处理确实不属于所有这些类别，并且您仍然相信可以从多线程中受益，那么理论上可以在 SQL 内部启动线程。请注意，SQL 内的 CLR 主机不是您的普通 CLR 主机（即众所周知的应用程序主机或 ASP 主机）。 SQL CLR 是第三种主机类型，在 SOS 构造（工作者、锁存器、内存管理员等）。我强烈建议不要在 SQL 中进行显式多线程 CLR 处理。
If is data intensive with potential to parallelization, you should process it in set oriented manner and let SQL paralelize the processign as it sees fit. You will not be able to do anything smarter than SQL already does in regard to partition the data access per CPU, it simply has access to information you don't (buffer pool fill state, page lifetime expectancy, CPU/NUMA affinity etC).
If your processing is scalar oriented and CPU intensive (and even some set oriented processing), place the processing in an UDF CLR function and again, let the query execution paralelize your function execution.
If your processing has any sort of I/O (ie. web calls), do not put it in SQL, place outside the server process.
If your processing really falls outside all these categories and you still believe you could benefit from multithreading, in theory is possible to start threads inside SQL. Be warned that the CLR host inside SQL is not your normal CLR host (ie. the well known application host or the ASP host). SQL CLR is a third host type, offering its own primitives (threads, locking, memory management etc) layered on top of SOS constructs (workers, latches, memory clerks etc). I would strongly advise against doing explicit multi-threaded CLR processing in SQL.