我读过一篇文档(Designing Highly Scalable OLTP Systems),它描述了如何获得更高性能的技巧:
因为行很小(许多适合一页)多个锁可能会争用一个 PAGELATCH。我们可以“浪费”一点空间来获得更多的性能。解决方案:用 CHAR 列填充行,使每一行占据整页。
有人使用这种方法吗?你有什么结果?
谢谢你。
添加:
警告。链接的文章不是行动指南。Thomas Kejser描述了对 TB 大小的数据库的测试,仅此而已。
我读过一篇文档(Designing Highly Scalable OLTP Systems),它描述了如何获得更高性能的技巧:
因为行很小(许多适合一页)多个锁可能会争用一个 PAGELATCH。我们可以“浪费”一点空间来获得更多的性能。解决方案:用 CHAR 列填充行,使每一行占据整页。
有人使用这种方法吗?你有什么结果?
谢谢你。
添加:
警告。链接的文章不是行动指南。Thomas Kejser描述了对 TB 大小的数据库的测试,仅此而已。
我只是简单地浏览了文档,但我的第一个想法是“哦,一个 SQLCAT 出版物”。这些人推出了一些很棒的材料,但他们的大部分指导都来自突破界限的极端极端。
您可以通过阅读有关 SQL Server 在数百万 $$$ 实现中的行为来学到很多东西,但其中很少适用于典型安装。此特定文档是测试 10k/tps、256 核、500 轴系统的结果。
在现实世界中,您不会将 SQL Server 内部结构推到超出其预期限制的位置,这些都是有趣的消遣,而不是建议。
你的问题可能有点危险。一个偶然路过的人可能会阅读您的问题,简单地浏览链接的文档并得出结论,填充行以填充页面是个好主意。
是的。正如 Thomas Kejser 所展示的那样。
绝对不!
对我来说听起来很可怕。你想要每页一行?如果表很大并且您除了单行查找之外还做了任何事情,我认为您是在自找麻烦。当然,您的平均页面争用可能较少,但您的 I/O 将达到顶峰。现在,影响将是相对的——例如,通常有多少行适合一个页面?我们是在谈论 3 kb 行还是 300 字节行?