作为生产DBA我看到不同的问题场景所有的时间。而在这些场景中的每一个总是有这种推卸责任的游戏正在进行。该应用程序的人认为它的数据库;该数据库的人认为这是盘;磁盘家伙人认为它的服务器;服务器人员人认为它的网络;和网络偷看可能不会在任何人指责，不知道它是什么，他们只知道这是不是网络。和乐趣，那场比赛通常，没有人打扰实际上拉号来解决这个问题，除了看到它不可能是在他们自己的地盘。有什么更好的是他们对他们的诊断证明。我想谈一下数据库，因为这就是我活在世界上大多数国家。
告诉我你有多少次听到这样的对话：
DBA：“是什么让你觉得这是数据库？”
AppGuy：“嗯，这是一个数据库应用程序，所以按理说数据库的问题，因为我们还没有在应用程序中改变任何东西。”
DBA:“但几天前，甚至是今天早些时候，它还能正常工作。我们这边也没有做任何改变。”
AppGuy：“也许数据库达到阈值，现在是不是能跟上。”
DBA:“真的吗，这就是你想要的?”
我一直对这个似乎困扰它的魔法门槛感到好奇。因为它不仅存在于DBs中，它还困扰着网络、服务器和操作系统。似乎它的每个方面都有一个假想的点，它停止工作只是因为它累了。现在我们知道存在阈值，但是在数据库仍然小于TB (TB)的情况下宣布它达到了阈值，这是非常荒谬的，并且向所有人显示了您知道的太少。即使DB超过TB，仅仅在一个下午它就从运行变为爬行，因为已经输入了额外的50行，这种可能性是没有意义的。
什么是有意义的，虽然是一个索引变得过于分散，并停止在一天中表现良好。这一切发生的时间。这也有道理，你可以使用一个额外的工作量繁重的磁盘而这使事情移动速度较慢。那么，这些门槛？无不是真的。他们所发生的所有的时间操作的一个正常部分。所以我们现在看到是非常无知的IT人在抓救命稻草，以找到一个解决方案。我的谈话非常相似，在此之前实际上已经停止了会议：
AppGuy：“这一定是数据库。”
我:“为什么?”
AppGuy：“好吧，我注意到，我们在这个表中超过200万行，所以必须越过某种门槛。也许我们需要创建另一个表，两者以期连接起来。”
我:“实际上，是系统的颜色。Windows处理Blue要困难得多，这可能会对性能造成严重影响。”
AppGuy：“你说什么？”
我:“哦，对不起，我还以为我们在搞一个最愚蠢的借口比赛呢。”
而我的家伙，现在采摘的应用程序，但事实是，我已经看到了很多这样的事情，从数据库管理员了。听着，“门槛”不能是默认的诊断，说明你不能够解决所有问题。
治愈
必须有一个虽然答案，对吗？当然有...迷信停止相信和做明显的，但耗时的事：捡起一本书。地狱，拿起3个或5，而你在这。我当然知道，简单地拿起了一本书，读它不是实际的治愈。你有实际工作的例子，明白为什么事情正在做他们的方式。力争真正理解什么使得它的工作，然后你就可以开始理性的答案自己。知识为王。如果书是不是你的东西，进入论坛，并提出问题。最重要的是，而不是大胆地陈述问题是什么，问了DBA，如果他看到什么不好的数据库。然后让他回答。 help educate you. Ask the question, is there a threshold that would keep the database from processing a table this size? Here’s another good one. What kinds of things could make the database performance tank so quickly?
当然，它总是以基准您的服务器一个极好的主意。你怎么可能知道什么是正常的还是真的是什么，如果你从来没有跑太多工作量模仿你的，增加它，直到该服务器尖叫？每个人都应该知道他们的服务器的限制是，他们是对他们的距离。
我的店里有一个最大的阈值失控的例子。我们的一个供应商认为SQL Server不能处理超过60GB的数据库，所以他们给自己的数据库设置了上限。现在我们有几个60GB的DBs，而不是一个大的DB。前端必须找出它要查找的数据存储在哪里，然后去查询正确的数据库。我有这个愿景一些c#的家伙写这个程序,没有捡起一个SQL书,决定他的应用在某种程度上是特殊的,瞬间越过这个神奇的阈值,突然一个数据库引擎,可以处理许多TBs的实时数据在其他地方,突然坏了,他的天才。现在我还没有查看模式，但我敢打赌，问题是在他的查询、索引或设计中突出的。我几乎可以保证这是一个简单的新手错误。