Sql server SQL Server：基本设计问题？

我工作的公司的董事在一次聚会上遇到了一家软件公司的另一位董事（这不是开玩笑！）

第二个导演告诉我的导演

“他花了一大笔钱放弃了SQL Server”，因为“如果有几个人以不同的方式查询同一个表，数据库就会被锁定”。此外，这是“SQL Server已知的基本设计问题，其中每个查询都会争夺最大资源，直到SQL Server在对同一个表进行大约7次并发查询后锁定”

现在我对SQL Server锁定和IO有了一些了解，这对我来说是个新闻。顺便说一句，SQL Server体系结构中没有任何固有的东西会导致此类问题。SQL Server在TPC基准测试中表现良好，特别是在性价比方面

问这个问题我感到很尴尬，但我必须确定——他说的话有什么道理吗

---

编辑-在阅读了一些评论后，我想我会明确表示，我同意在sql Server中编写性能差的sql是可能的，因为它在任何数据库平台上都是如此。有点像是在问，在某些高并发条件下，无论您的db/sql制作得有多好，体系结构中是否存在阻止它的固有因素？

这绝对不是事实，而另一位主管的it部门显然有以下两种情况之一，这可以在许多公司找到：

没有DBA，或者（白痴）主管是DBA，或者没有任何DBA资格的人被迫担任DBA

不称职的DBA或不称职的IT员工，他们创建了数据库模式，并在给定这些模式的情况下以不称职的方式查询数据库。另外，请参见下面TomTom对该答案的评论，该评论进一步扩展和阐述了该问题

此外，在得出SQL Server无法有所作为的结论之前，请务必先了解一下SQL Server目前的市场主导地位

这并不是说SQL Server是完美的，没有“基本的设计问题”，例如，在使用标识列时，您可能会遇到一个难以置信的错误，而实际上每个人都会遇到这个错误：

---

写得不好的查询可能会导致他所说的行为。但这并不是放弃SQL Server的原因，而是寻找更好的开发人员/DBA的原因

---

任何技术如果使用不当都可能出现问题。有许多大型项目都是在SQL Server（包括）上构建的。如果他所描述的是SQL Server的结果，而不是开发人员的结果，那么SQL Server很可能根本就不存在……

我知道您可能会意外地锁定SQL，或者使用一些编写糟糕的查询，但我不会说这是SQL Server本身的设计缺陷

我开发的软件将在英国各地部署，80多家商店都在查询相同的表，从未出现过任何问题。我们公司还生产了基于SQL数据库的大型软件，该数据库有100多个存储区，包含10-100多个应用程序，所有应用程序都查询/更新相同的表。我们遇到了一些死锁问题，但都得到了解决

有了合适的人员和知识，SQL是一个了不起的工具，当你让任何一位老程序员成为DBA时，你就会遇到我怀疑在这里发生的问题

当我听到这样的故事时，除非有人告诉我正在开发一些大型企业级应用程序，否则我总是认为，如果大企业能够在不给他们带来巨大问题的情况下使用该应用程序，那么我说我不能在较小的应用程序中使用SQL，那就是我做错了

---

知道它们迁移到了什么地方而不是SQL是很有趣的。

好吧，这取决于查询-如果它是以持有悲观锁的方式编写的，那么他可能观察到了您所描述的内容-但这将是查询作者的错，而不是SQL Server本身的错！投票结束，因为这可能会引发一场宗教战争。当你说“质疑”是什么意思？插页？选择？更新？-1@Stuart-天哪，禁止一些争论…非常有趣的问题+1.现实可能要求开发者对这一指控作出回应。或者被问到他的意见。这对他来说是一个很有价值的答案。所以你的第二个场景确实提供了一点真相——是的，DB在某些条件下可能会被锁定。不过，我一分钟也没有暗示这是SQL Server中的一个缺陷！将不了解锁定的开发人员添加到DBA中，您将进入一个非常正常的场景。大多数开发人员并不知道数据库是如何工作的，“只是通过某种方式让代码正常工作”。甚至SQL也避开了它们（即COMPELX SQL，而不是simpel select）。这是最可能的情况。有些白痴开发人员抱怨，一些白痴技术人员购买，一些白痴CTO做出决定。@ K.Bob，任何适当执行的RDBMS都有可能出现性能问题，就像可以在C++中写慢速应用程序一样。@ TimToM，在这里，我赞成你的评论！Crispalot-当然会，因此我希望自己清楚地表明这不是SQL Server的问题。+1如果我们发现他们抛弃SQL Server的原因，以及相同的开发人员是否在他们的新数据库中发现相同的致命缺陷。