Jor*_*oba 7 database sql-server performance sql-server-2005 insert
在我的工作中,我们有一个小型数据库(如200个表,可能总共有100万行左右).
我一直期望它以每秒几十万次插入的顺序非常快,并且一旦建立连接就需要几毫秒的查询.
恰恰相反,我们遇到了一些性能问题,因此我们每秒只能进行几百次插入和查询,即使是最简单的插入也是永远需要的.
如果这是标准的行为/表现,或者我们做错了什么,我并不确定.例如,1500个查询意味着在一个键列上连接4个表大约需要10秒.在不违反任何约束的情况下,使用简单插入将xml格式的300K数据加载到数据库中需要3分钟.
该数据库是SQL Server 2005,具有丰富的关系依赖模型,意味着对数据的许多关系和分类以及分类代码和其他一些事项的全套检查约束.
那些时候对吗？如果没有,可能会影响性能？(所有查询都在索引列上完成)
进行粗略的比较:SQL Server的TPC-C基准记录大约是每分钟1.2百万个事务处理,并且在过去4年左右就是这样(由64个CPU操作系统限制).这是每秒约16k交易的平台.这是在超高端机器,64个CPU,大量RAM,每个NUMA节点的亲和客户端和服务器短剥离的I/O系统(仅使用每个主轴的1-2%).请记住那些是TPC-C事务,因此它们包含多个操作(我认为平均每个操作4-5次读取和1-2次写入).
现在,您应该将此顶级硬件缩减到实际部署,并将获得设置您对整个OLTP事务处理的期望的大概.
对于数据上传,当前世界纪录在30分钟内约为1TB(如果仍然是当前的......).每秒几万个插件是非常雄心勃勃的,但是如果在严肃的硬件上正确完成,则可以实现.链接中的文章包含ETL高吞吐量的提示和技巧(例如,使用多个上传流并将它们关联到NUMA节点).
对于你的情况我建议首先衡量,所以你找出瓶颈,然后问具体的问题,如何解决具体botlenecks.一个很好的起点是Waits and Queues白皮书.
索引是这里的一个主要因素,如果正确完成它们可以很好地加速Select语句,但请记住,索引会使插入陷入困境,服务器不仅会更新数据,还会更新索引.这里的诀窍是:
1)确定真正速度关键的查询,这些查询应该具有最佳索引.
2)填充因子在这里也很重要.这为索引页面提供了空白空间,以便以后填充.当索引页面已满(插入足够的行)时,需要创建一个新页面,花费更多时间.但是空页占用磁盘空间.
我的诀窍是,对于每个应用程序,我设置优先级如下:
1)读取速度(SELECT,Some UPDATE,Some DELETE) - 优先级越高,我创建的索引越多
2)写入速度(INSERT,Some Update,Some DELETE) - 优先级越高,我创建的索引越少
3)磁盘空间效率 - 优先级越高,填充因子越高
请注意,此知识通常适用于SQL Server,您的里程可能因不同的DBMS而异.
SQL语句评估也可以在这里提供帮助,但这需要一个真正的专家,小心的WHERE和JOIN分析可以帮助确定瓶颈以及您的查询所处的位置.打开SHOWPLAN并查询计划,评估您看到的内容并进行相应的计划.
另请参阅SQL Server 2008,索引连接!