在我的工作中，我们有一个小型数据库（有 200 个表，总共可能有 100 万行左右）。
我一直期望它的速度相当快，每秒插入数万次，并且一旦建立连接，查询只需几毫秒。
恰恰相反，我们遇到了一些性能问题，因此我们每秒只能进行几百次插入和查询，即使是最简单的查询也会永远持续下去。
我完全不确定这是否是标准行为/表现，还是我们做错了什么。例如，1500 个查询意味着在单个键列上连接 4 个表大约需要 10 秒。在不违反任何约束的情况下，使用简单的插入将 300K xml 格式的数据加载到数据库中需要 3 分钟。
数据库是 SQL Server 2005，具有丰富的关系依赖模型，这意味着数据上有很多关系和分类，以及分类代码和其他一些东西的一整套检查约束。
那些时间对吗？如果不是，什么可能会影响性能？ （所有查询均在索引列上完成）
粗略比较一下：SQL Server 的 TPC-C 基准记录 http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=105112801每分钟大约有 120 万笔交易，并且在过去 4 年左右的时间里一直如此（受到 64 个 CPU 操作系统的限制）。那是在 balpark 中的东西每秒约 16,000 笔交易。这是在超高端机器上，64 个 CPU、充足的 RAM、每个 NUMA 节点有关联的客户端以及服务器短剥离 I/O 系统（每个主轴仅使用大约 1-2%）。请记住，这些是 TPC-C 事务，因此它们由多个操作组成（我认为平均每个操作 4-5 次读取和 1-2 次写入）。
现在，您应该将这个顶级硬件缩小到您的实际部署，并大致了解在哪里设置您对整体的期望OLTP事务处理.
对于数据上传当前世界纪录是30分钟约1TB http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx（如果仍然是当前的...）。每秒数万次插入是相当雄心勃勃的，但如果在严格的硬件上正确完成，这是可以实现的。链接中的文章包含 ETL 高吞吐量的提示和技巧（例如，使用多个上传流并将它们关联到 NUMA 节点）。
对于你的情况我首先建议measure所以你找出瓶颈然后问specific问题如何解决特定的瓶颈。一个好的起点是等待和队列白皮书 http://sqlcat.com/whitepapers/archive/2007/11/19/sql-server-2005-waits-and-queues.aspx.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
