设计表以支持使用 SQL Server 更快地更新一个字段的最佳实践
我正在开发类似工作流的系统。我有一个任务表和状态字段。状态值可以是 New、ready、processing、error、abort、done 之一。
我有大约7个进程，它们会根据不同的情况被触发来改变任务状态的值。大多数时候，每个进程都会处理自己的数据集，并且每次最多只能处理 5000 条记录。但如果数据达到 200 万条左右，我仍然会看到一些僵局。我检查了 SQL Profiler，看起来像是与某些页面资源相关。我不擅长sql server性能调优，也不是很了解。
由于每天都会归档不活动的任务，我正在考虑重新设计该表以支持大约 1000 万条记录。
很少有选择可能是：
- 根据状态创建拆分表。
- 创建一个包含静态数据的主表和基于状态的支持表
对于这种情况有什么好的做法吗？
谢谢！
I am working on Workflow like system. I have one task table and status field. Value for status can be one of New,ready,processing,error,abort,done.
I have about 7 processes which will be triggered based on different situation to change value of task status. Most time each process will work on its own data set and every time it only processes up to 5000 records. But I still see some deadlock if data reach around 2 million records. I check with SQL Profiler, looks like some page resource related. I am not good at sql server performance tuning and do no understand it very well.
Since inactive task will be archived every day, I am thinking to redesign the table to support around 10 Million records.
Few choice may be :
- Create split tables based on status.
- Create a master table with static data and supported table based on status
Is there any good practice for this kind of situation?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我知道我应该发布答案，但对于这些问题，答案可能如下：
1.）表格提示是否到位？如果没有，则尝试应用这些
2.) 是否使用了所有可用索引，
TaskId列是唯一可接受的索引吗？有时，分析时的某些情况会导致需要新索引3.) 在任何给定时间所有 200 万条记录都处于活动/活动状态吗？
4.) 您检查过碎片索引吗？每日归档可能会导致索引碎片，因此您可能需要在归档作业结束时添加一个步骤来检查和修复碎片
5.)
new、ready的状态字段,processing,error,abort,done是在什么数据类型下？6.) 您是否尝试过索引视图？如果您已经知道要限制某些数据并希望避免表扫描，那么它可能会有所帮助
I know I should be posting an answer, but with these questions the answers may follow:
1.) Are table hints in place? If not, then experiment with applying those
2.) Are all available indexes utilized, and is the
TaskIdcolumn the only acceptable index? Sometimes, certain situations when analyzed will bring about the need for a new index3.) Are all 2 million records live/active at any given time?
4.) Have you checked for fragmented indexes? Daily archiving can cause index fragmentation, so you might want to add at the end of your archiving job a step to check and fix fragmentation
5.) Status field for
new,ready,processing,error,abort,doneis under what data type?6.) Have you experimented on indexed views? If you already know that you're limiting certain data and want to avoid table scans, it might be able to help