天道酬勤,学无止境

SQL Server 性能与键/对表与 XML 字段和 XPath(SQL Server Performance with Key/Pair Table vs XML Field and XPath)

问题

我已经看过一些关于这个主题的问题,但我正在寻找关于这两种技术之间性能差异的一些见解。

例如,假设我正在记录将进入系统的事件日志,其中包含特定事件的键/值对字典集。 我将在事件表中记录一个带有基本数据的条目,但是我需要一种方法来链接附加的键/值数据。 我永远不会知道会出现什么样的键或值,所以任何类型的预定义枚举表似乎都是不可能的。

此事件数据将不断流入,因此插入时间与查询时间一样重要。

当我查询特定事件时,我将使用事件上的一些字段以及键/值数据中的数据。 对于 XML 方式,我只需使用 Attributes.exists('xpath') 语句作为 where 子句的一部分来过滤记录。

规范化的方法是使用具有基本键和值字段的表,并带有指向事件记录的外部链接。 这看起来很简洁,但我担心所涉及的数据量。

回答1

对于“灵活”的存储机制,您有三个主要选项。

  • XML 字段很灵活,但将您置于 Blob 存储领域,查询速度很慢。 我已经看到,当它使用 Xpath 查询从 blob 中挖掘内容时,对 30,000 行的小型数据集的查询需要 5 分钟。 这是迄今为止最慢的选择,但它很灵活。

  • 键/值对要快得多,尤其是在事件键上放置聚集索引时。 这意味着单个事件的所有属性将在物理上一起存储在数据库中,这将最大限度地减少 I/O。 该方法不如 XML 灵活,但速度要快得多。 针对它进行报告的最有效查询将涉及数据透视(即表扫描以生成中间展平结果); 加入获得个别领域会慢得多。

  • 最快的方法是创建一个包含一组用户定义字段(Field1 - Field50)的平面表,并保存一些关于字段内容的元数据。 这是最快的插入和最容易查询的方法,但是表的内容对于任何无法访问元数据的内容都是不透明的。

回答2

我认为键/值表方法的问题与数据类型有关——如果一个值可以是日期时间、字符串或 unicode 字符串或整数,那么如何定义列? 这种困境意味着值列必须是一种数据类型,其中可以包含所有不同类型的数据,这会引发查询效率/易用性的问题。 或者,您有多个特定数据类型的列,但我认为这有点笨拙。

对于真正灵活的模式,我想不出比 XML 更好的选择。 您可以索引 XML 列。

MSDN 上的这篇文章更详细地讨论了 XML 存储。

回答3

我假设对于 INSERT 和 SELECT 操作,规范化的方式会更快,如果仅仅是因为这是任何 RDBMS 的优化目标。 “所涉及的数据量”部分也可能是一个问题,但更容易解决 - 您需要立即手头的数据多长时间,您可以在一天、几周或 3 个月后将其存档,等等? SQL Server 可以处理很多事情。

此事件数据将不断流入,因此插入时间与查询时间一样重要。

选项 3:如果您确实有大量数据不断流式传输 - 在共享内存、进程内 sqlite、单独的 db 表甚至它自己的服务器中创建一个单独的队列,以存储传入的原始事件和属性,并拥有另一个进程(计划任务、Windows 服务等)将该队列解析为针对快速 SELECT 调整的任何首选格式。 最优输入,最优输出,随时准备向任一方向扩展,每个人都开心。

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • MySql Xml 函数的性能?(Performance of MySql Xml functions?)
    问题 我对新的 Mysql XML 函数感到非常兴奋。 现在我终于可以在我的老式关系数据库中嵌入“面向对象”文档之类的东西了。 例如,考虑一个使用 facebook connect 在您的网站上唱歌的用户。 您可以使用图形 api 为用户获取一个对象,并获得很好的信息。 然而,这些信息可能会有很大差异。 有些字段可能会也可能不会设置,有些可能会随着时间的推移而添加等等。 好吧,如果您只是对非常特殊的领域(例如朋友关系、性别、电影...)感兴趣,您可以将它们投影到您的关系数据库方案中。 但是,使用 XMl 函数,您可以将整个对象存储在一个字段中,然后您的不同模型可以使用 ExtractValue 函数访问数据。 您可以立即存储所有内容,而无需担心以后需要什么。 但是表现会怎样呢? 例如,我有一个包含 50 000 个条目的表,这些条目代表用户。 我有一个 enum 字段,上面写着"male", "female ”(或政治上正确的其他各种性别)。 例如获取所有男性的性能将非常快。 但是像WHERE ExtractValue(userdata, '/gender/') = 'male'呢? 如果对象变大,性能将如何变化? 我可以以某种方式在指定的 xpath 选择上放置索引吗? 字段类型如何与此功能/性能协同工作。 变量/斑点? 我需要全文索引吗? 总结一下我的问题: Mysql XML
  • SQL Server 中的临时表使用(Temporary Table Usage in SQL Server)
    问题 这是一个有点悬而未决的问题,但我真的很想听听人们的意见。 我很少使用显式声明的临时表(表变量或常规#tmp 表),因为我相信不这样做会导致更简洁、可读和可调试的 T-SQL。 我还认为,在需要时(例如在查询中使用派生表时),SQL 可以比我更好地使用临时存储。 唯一的例外是当数据库不是典型的关系数据库而是星型或雪花模式时。 我知道最好先将过滤器应用于事实表,然后使用生成的临时表从您的维度中获取值。 这是普遍看法还是有人反对? 回答1 临时表对于复杂的批处理过程(如报告或 ETL 作业)最有用。 通常,您希望在事务性应用程序中很少使用它们。 如果您正在使用涉及多个大表的连接(也许是报告)进行复杂查询,则查询优化器实际上可能无法一次性优化它,因此临时表在这里变得有利 - 它们将查询分解为一系列更简单的那些给查询优化器更少的机会来搞砸计划。 有时您的操作根本无法在单个 SQL 语句中完成,因此需要多个处理步骤才能完成这项工作。 同样,我们在这里讨论更复杂的操作。 您还可以为中间结果创建一个临时表,然后为该表建立索引,甚至可能在其上放置聚集索引以优化后续查询。 这也可能是一种在不允许向数据库架构添加索引的系统上优化报表查询的快速而肮脏的方法。 SELECT INTO 对这种类型的操作很有用,因为它的日志记录最少(因此速度很快)并且不需要对齐选择和插入的列。 其他原因可能包括使用
  • 列顺序是否会影响Microsoft SQL Server 2012中的性能?(Does column ordering affects performance in Microsoft SQL Server 2012?)
    问题 我已经读到varchar字段应该作为一列放在数据库表的末尾-至少在MySQL中是如此。 原因是因为varchar字段的长度可变,可能会减慢查询速度。 我的问题:这是否适用于MSSQL 2012? 我是否应该将表设计为在每个数据库行的末尾都包含所有文本数据? 回答1 与数据库设计(实体,属性和关系),事务设计和查询设计对性能的影响相比,表中列的顺序对性能的影响很小。 要确定差异是否不可忽略,您确实需要设置一些测试并比较结果。 通常,我将主键放在第一列,然后是外键,然后是自然键和经常访问的列。 我通常将较长的字符串放在行尾。 但这并不一定是性能优化,而是我为方便起见使用的样式首选项。 当一行中的大量列可以为空并且其中大多数列包含NULL时,列的顺序可能会影响SQL Server中行的大小。 SQL Server(如Oracle)进行了优化,在该行的末尾不为包含NULL值的列保留空间。 该行的每一列都保留一些空间,直到该行的最后一个非NULL值为止。 由此得出的结论是,如果您有很多可为空的列,那么您希望最频繁的列在最经常为NULL的列之前不为NULL。 注意:请记住,SQL Server首先根据列是固定长度还是可变长度来对表中的列进行排序。 首先存储所有固定长度的列,然后存储所有可变长度的列。 在这些列集(固定列和可变列)中,列按定义的顺序存储。 回答2 当谈到创建索引,列顺序事做
  • 外键是否可以提高查询性能?(Does Foreign Key improve query performance?)
    问题 假设我有2个表,即“产品”和“产品类别”。 两个表在CategoryId上都有关系。 这就是查询。 SELECT p.ProductId, p.Name, c.CategoryId, c.Name AS Category FROM Products p INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId WHERE c.CategoryId = 1; 当我创建执行计划时,表ProductCategories会执行群集索引查找,这与预期的一样。 但是对于表Products,它执行集群索引扫描,这使我感到怀疑。 为什么FK不能帮助提高查询性能? 因此,我必须在Products.CategoryId上创建索引。 当我再次创建执行计划时,两个表都执行索引查找。 并且估计的子树成本大大降低了。 我的问题是: 除了FK有助于关系约束之外,它还有其他用途吗? 它会提高查询性能吗? 是否应该在所有表的所有FK列(如Products.CategoryId)上创建索引? 回答1 外键是参考完整性工具,而不是性能工具。 至少在SQL Server中,创建FK不会创建关联的索引,您应该在所有FK字段上创建索引以缩短查找时间。 回答2 外键可以改善(和损害)性能 如此处所述:外键可提高性能您应该始终在FK列上创建索引以减少查找。
  • 在经典的 asp/sql server 网站中寻找性能瓶颈(Finding performance bottlenecks in a classic asp/sql server website)
    问题 我有一个旧的经典 asp/sql server 应用程序,即使负载不大,它也会不断抛出 500 个错误/超时。 一些数据库查询非常密集,但没有什么会导致它崩溃。 有没有什么好的软件可以安装在我的服务器上,它可以准确地显示在 asp 或 DB 中的瓶颈在哪里? 回答1 您可以尝试一些工具: HP(以前称为 Mercury)LoadRunner 或 Performance Center Visual Studio Application Center 测试(仅限企业版?) Microsoft Web 应用程序压力工具(又名 WAS,又名“Homer”;应用程序中心测试的前身) 网络负载如果要跟踪应用程序代码,请使用 MS Visual Studio Analyzer。 这可以显示应用程序等待数据库调用的时间,以及使用的 SQL。 然后,您可以使用 SQL 探查器来调整查询。 回答2 超时发生在哪里? 当 ASP 连接/执行 sql 时,它是否在线? 如果是这样,您的问题要么与数据库服务器的连接有关,要么与数据库本身有关。 在 MSSQL 中加载 SQL 分析器以查看查询需要多长时间。 也许是由于数据库中的锁。 你使用交易吗? 如果是这样,请确保他们不会长时间锁定您的数据库。 确保在 ADO 中而不是在整个 ASP 页上使用事务。 您还可以通过对表使用 WITH (NOLOCK)
  • MyCAT读写分离分库分表
    MyCAT读写分离及分库分表 第1章 MyCAT分布式系统解决方案 1.1 分布式系统介绍: 分布式系统特性: 1. 透明性: a) 分布式系统对用户来说是透明的,一个分布式系统在用户面前的表现就像一个传统的单机处理机分时系统,可以让用户不比了解内部结构就可以使用 2. 扩展性: a) 分布式系统的最大特点就是扩展性,它可以分局需求的增加而扩展,可以通过横向扩展使集群的整体性能得到线性提升,也可以通过纵向扩展单台服务器的性能使服务器的集群的性能得到提升 1.2 MyCAT的设计理念: mycat的原理中最重要的一个动词就是拦截,它拦截了用户发送过来的sql语句,首先对sql语句组了一些特定的分析,如分片分析,路由分析,读写分析,分离分析,缓存分析,然后将此sql语句发往后端的真实数据库,并将返回结果做适当处理,最终返回给用户 image.png 1.1 MyCAT软件特点: 遵守mysql原生协议,跨语言,跨数据库的通用中间件代理 基于心跳的自动故障切换,支持读写分离,支持mysql一双主,多从,以及一主多从 有效管理数据源连接,基于数据分库,而不是分表的模式 基于Nio实现,有效管理线程,高并发问题 支持数据的多片自动路由与聚合,支持sum,count,max等常用的聚合函数 支持2表join,甚至基于caltet的多表join 支持通过全局表,ER关系的分片策略
  • Sql Server:选择性 XML 索引未被有效使用(Sql Server: Selective XML Index not being efficiently used)
    问题 我正在探索提高应用程序性能的方法,我只能在有限的程度上影响数据库级别。 SQL Server 版本是 2012 SP2,有问题的表和视图结构是(我不能真正影响这个 + 注意 xml 文档可能总共有几百个元素): CREATE TABLE Orders( id nvarchar(64) NOT NULL, xmldoc xml NULL, CONSTRAINT PK_Order_id PRIMARY KEY CLUSTERED (id) ); CREATE VIEW V_Orders as SELECT a.id, a.xmldoc ,a.xmldoc.value('data(/row/c1)[1]', 'nvarchar(max)') "Stuff" ,a.xmldoc.value('data(/row/c2)[1]', 'nvarchar(max)') "OrderType" etc..... many columns from Orders a; 一个典型的查询(以及下面用于测试的查询): SELECT id FROM V_Orders WHERE OrderType = '30791' 所有查询都是针对视图执行的,我既不能影响查询,也不能影响表/视图结构。 我认为向表中添加选择性 XML 索引将是我的救星: CREATE SELECTIVE XML INDEX I
  • 使用SqlDependency与定期对表进行轮询(对性能的影响)(Using SqlDependency vs. periodic polling of a table (performance impact))
    问题 在我们应用程序开发的开始,我们大量使用SqlDependency来缓存数据库结果,直到通知告知我们的应用程序获取新副本为止。 在测试过程中,我们注意到SqlDependency通知服务严重影响了SQL DB的性能。 我们缩减了使用SqlDependency的表的数量,并注意到性能有了很大的提高。 因此,我们认为我们刚刚结束使用它,所以我们继续前进。 现在我们只有几张桌子。 后来,我们发现无法缩减将建立依赖关系的用户名的安全访问级别。 每个数据库我们可以有多个连接字符串(一个用于依赖关系,一个用于其他应用程序),但是对于多个数据库和数据库镜像,这很麻烦(从SQL DB管理员和应用程序开发的角度来看)。 在这一点上,我们只是在考虑基于以下逻辑完全放弃SqlDependency: 我们不需要“即时”通知数据已更改。 如果我们在1秒钟之内知道,那将足够快。 稍加重构,我们就可以将其简化为1个表并每秒轮询一次该表。 有没有人看到这种逻辑上的缺陷? 每秒轮询一张表会比SqlDependency导致更多或更少的数据库负载吗? 有没有人对SqlDependency有类似的性能问题? 回答1 我敢尝试回答你的问题。 但我不确定您是否会得到您所希望的答案... 我记得在90年代初,Borland在其数据库Interbase中推广了“回调”这一宏伟的新功能,该功能将通过一些非常漂亮的新技术向调用方
  • SQL计数(*)性能(SQL count(*) performance)
    问题 我有一个超过2000万行的SQL表BookChapters。 它具有群集的主键(bookChapterID),并且没有任何其他键或索引。 运行以下查询需要几毫秒的时间 if (select count(*) from BookChapters) = 0 ... 但是,像这样更改时需要花费超过10分钟的时间 if (select count(*) from BookChapters) = 1 ... 或者 if (select count(*) from BookChapters) > 1 ... 这是为什么? 如何获得select count(*)以更快地执行? 回答1 以下是Mikael Eriksson的一个很好的解释,为什么第一个查询很快: SQL Server将其优化为: if exists(select * from BookChapters) 。 因此,它会寻找一行的存在,而不是对表中的所有行进行计数。 对于其他两个查询,SQL Server将使用以下规则。 若要执行类似SELECT COUNT(*)的查询,SQL Server将使用最窄的非聚集索引对行进行计数。 如果该表没有任何非聚集索引,则必须扫描该表。 另外,如果您的表具有聚集索引,则可以使用以下查询(从本网站借来的值更快获取行计数)来更快地获得计数。 --SQL Server 2005/2008
  • SQL Server中INNER JOIN与LEFT JOIN的性能(INNER JOIN vs LEFT JOIN performance in SQL Server)
    问题 我创建了在9个表上使用INNER JOIN的SQL命令,无论如何,此命令将花费很长时间(超过五分钟)。 所以我的同事建议我将INNER JOIN更改为LEFT JOIN,因为尽管我知道,但LEFT JOIN的性能更好。 更改后,查询速度得到了显着提高。 我想知道为什么LEFT JOIN比INNER JOIN快? 我的SQL命令如下所示: SELECT * FROM A INNER JOIN B ON ... INNER JOIN C ON ... INNER JOIN D等等 更新:这是我的架构的简要介绍。 FROM sidisaleshdrmly a -- NOT HAVE PK AND FK INNER JOIN sidisalesdetmly b -- THIS TABLE ALSO HAVE NO PK AND FK ON a.CompanyCd = b.CompanyCd AND a.SPRNo = b.SPRNo AND a.SuffixNo = b.SuffixNo AND a.dnno = b.dnno INNER JOIN exFSlipDet h -- PK = CompanyCd, FSlipNo, FSlipSuffix, FSlipLine ON a.CompanyCd = h.CompanyCd AND a.sprno = h.AcctSPRNo
  • 即使不引用,表中的字段数是否会影响性能?(Does the number of fields in a table affect performance even if not referenced?)
    问题 我正在读取 CSV 文件并将其解析为 SQL Server 2008 数据库。 此过程对所有文件使用通用 CSV 解析器。 CSV 解析器将解析的字段放入通用字段导入表(F001 VARCHAR(MAX) NULL、F002 VARCHAR(MAX) NULL、Fnnn ...)中,然后另一个进程使用知道哪个解析字段的 SQL 代码移动到实际表中(Fnnn) 转到目标表中的哪个字段。 所以一旦在表中,只有被复制的字段被引用。 一些文件可能会变得非常大(一百万行)。 问题是:表中的字段数是否显着影响性能或内存使用? 即使大多数字段没有被引用。 对字段导入表执行的唯一操作是 INSERT 和 SELECT 以将数据移动到另一个表中,字段数据上没有任何 JOIN 或 WHERE。 目前,我有三个字段导入表,一个有 20 个字段,一个有 50 个字段,一个有 100 个字段(这是我迄今为止遇到的最大字段数)。 目前有使用尽可能小的文件的逻辑。 我想让这个过程更通用,并且有一个包含 1000 个字段的表(我知道 1024 列的限制)。 是的,一些要处理的计划文件(来自第 3 方)将在 900-1000 字段范围内。 对于大多数文件,将少于 50 个字段。 此时,处理现有的三个字段导入表(加上更多字段的计划表(200,500,1000?))正在成为代码中的逻辑噩¢
  • SQL Server中事务,索引,触发器,游标
    文章目录 一、事务(一)事务的概念及要求(二)事务的特性(ACID)(三)事务的分类1.显示事务2.隐式事务3.自动提交事务 (四)创建事务(五)事务处理中的关键问题(六)判断某条语句执行是否出错的方法(七)事务的使用 二、索引(Index)(一)索引概念(二)索引类型1.聚集索引2.非聚集索引 (三)创建索引唯一索引:聚集索引:非聚集索引: (四)删除索引(五)索引的优点(六)索引的缺点 三、触发器(一)触发器概念(二)触发器的优点(三)触发器的作用(四)触发器的分类1.DML(数据操作语言,Data Manipulation Language)触发器2.DDL(数据定义语言,Data Definition Language)触发器3.登录触发器 (五)触发器的工作原理 四、游标(一)游标概念(二)游标分类1.静态游标2.动态游标3.只进游标4.键集驱动游标 一、事务 (一)事务的概念及要求 事务(TRANSACTION)是作为单个逻辑工作单元执行的一系列操作多个操作作为一个整体向系统提交,要么全部执行,要么都不执行事务是一个不可分割的工作逻辑单元 (二)事务的特性(ACID) 原子性(Atomicity):事务是一个完整的操作,事务的各个步骤的操作都是不可分的,要么都执行,要么都不执行一致性(Consistency):当事务完成时,数据必须处于一致状态隔离性(Isolation
  • 这才是你需要的最基础的数据库面试题(通俗易懂)
    如果有什么丢失的基础点或者描述的有错误的地方欢迎评论或者私信 这里原谅小编没有写超链接,但是可以打开目录点击同样快速访问 以后CSDN可能也不怎么更新了(个人原因😔),这段时间和蓝桥杯的群里以及CSDN大佬们的日常唠嗑让我获益匪浅,真的就是优秀的人连唠嗑都是在学习 1. 触发器的作用? 触发器是一个特殊的存储过程,当对指定的表进行某种特定操作(如:Insert,Delete或Update)时,触发器产生作用。触发器可以调用存储过程。 触发器的语句 Create Trigger[owner.]触发器名 On [owner.]表名 For {insert,update,delete} As Begin SQL语句(块) End 触发器的限制: 一个表最多只能有三个触发器,insert,update,delete 每个触发器只能用于一个表 不能对视图、临时表创建触发器 Truncate table能删除表,但不能触发触发器 不能将触发器用于系统表 常见的触发器有三种:分别应用于Insert,Update,Delete事件。 2. 什么是存储过程?用什么来调用? 存储过程其实就是一个sql的方法(你就当成Java(或者C#等等)自己写的方法,调用存储过程其实就是调用方法) 如果某次操作需要执行多次SQL,使用存储过程比单纯SQL语句执行要快。 可以用一个“execute 存储过程名 参数
  • 如何为用户定义的字段设计数据库?(How to design a database for User Defined Fields?)
    问题 My requirements are: Need to be able to dynamically add User-Defined fields of any data type Need to be able to query UDFs quickly Need to be able to do calculations on UDFs based on datatype Need to be able to sort UDFs based on datatype Other Information: I'm looking for performance primarily There are a few million Master records which can have UDF data attached When I last checked, there were over 50mil UDF records in our current database Most of the time, a UDF is only attached to a few thousand of the Master records, not all of them UDFs are not joined or used as keys. They're just
  • 读SQL Server性能调优实战——陈畅亮、吴一晴著
    sqlserver 微软 安装 根据业务特点来考虑 1、分析产品业务数据的增长量 预估某些关键业务数据在一定时间内的增长量,预估数据在未来的增长数据, 2、了解产品业务操作类型。考虑业务是以查询为主还是以更新为主。从而选择多大的内存。 SQL server配置 1、服务端的SQL server配置管理器(SQL server Configuration Management ) 2、客户端的SQL server Management Studio 数据库连接安全性 三种方式的连接协议 1、 共享内存 2、命名管道 3、TCP/IP协议 数据库实例配置 1、对CPU的使用分配,可以选择SQL server使用或者不使用某些CPU线程 2、内存配置,通过对操作系统内存的总体应用,从而优化数据库性能 ​ 2.1、最大服务器内存:SQL server的Buffer Pool最大使用的内存量。默认值2147483647MB。 当配置为0或者超过当前系统最大内存值时,使用系统最大内存量。当设置小于当前系统的最大内存值,并且大于最小内存值时,SQL server实例到达设置的最大内存量后,将不会继续扩大内存的使用量。 ​ 2.2、最小服务器内存:为SQL server实例预留能够使用的内存,当服务器内存出现压力,数据库收缩持有内存量,到达配置值将不在收缩。 影响sqlserver性能的因素 1
  • 解决SQL Server最大列数限制为1024和8kb的记录大小(Work around SQL Server maximum columns limit 1024 and 8kb record size)
    问题 我正在创建一个包含1000列的表。 大多数列都是nvarchar类型。 表已创建,但带有警告 警告:已创建表“ Test”,但表的最大行大小超出了所允许的最大8060字节。 如果结果行超出大小限制,则对该表的INSERT或UPDATE将失败。 该表的大多数列中已经有数据(即99%的列中有数据)。 当我尝试更新第310列之后的任何列时(因为所有开始的309列都具有某个值),它会给出错误: 无法创建大小为8061的行,该行大于允许的最大行大小为8060。 我将此数据插入所有开始的308列 “ Lorem ipsum胡萝卜,增加返利。” 当我使用ntext数据类型时,它允许我更新约450列,但超出该范围的ntext也不允许我进行更新。 我必须至少更新700列。 哪个SQL Server不允许这样做。 我有无法将表的某些列移到另一个表的情况。 实际上,我正在为现有的窗口应用程序工作。 这是一个非常大的Windows应用程序。 实际上,我要在其中插入700个nvarchar列数据的表是在运行时动态创建的。 仅在某些情况下,它需要插入400-600列。 但是通常它需要100个-200列,我能够轻松地对其进行处理。 问题是我无法将此表拆分为多个表。 因为用这种结构创建的许多表和表名都保存在另一个表中,即具有这种结构的表有100多个,并且它们是动态创建的。 为了创建表并处理其数据,使用了4
  • 在 SQL Server 中对大表进行分区的最佳方法是什么?(What is the best way to partition large tables in SQL Server?)
    问题 在最近的一个项目中,“首席”开发人员设计了一个数据库模式,其中“较大”的表将被拆分到两个单独的数据库中,并具有主数据库的视图,这会将两个单独的数据库表联合在一起。 主数据库是应用程序被驱动的,所以这些表看起来和感觉就像普通表(除了一些关于更新的古怪事情)。 这似乎是一个巨大的性能问题。 我们确实看到了这些桌子周围的性能问题,但没有什么能让他改变对他的设计的看法。 只是想知道这样做的最佳方法是什么,或者是否值得这样做? 回答1 我认为通过在单个服务器中跨多个数据库对表进行分区,您不会真正获得任何好处。 您在那里所做的一切首先增加了使用“表”的开销,因为它在单个 SQL Server 实例下有多个实例(即在两个不同的数据库中打开)。 你有多大的数据集? 我有一个客户端在 SQL Server 中有一个 600 万行的表,其中包含 2 年的销售数据。 他们在事务中使用它并进行报告,而没有任何明显的速度问题。 当然,调整索引并选择正确的聚集索引对性能至关重要。 如果您的数据集非常大并且您正在寻找分区,那么跨物理服务器对表进行分区将获得更多收益。 回答2 分区不是一件轻而易举的事情,因为可能会有许多微妙的性能影响。 我的第一个问题是您是指将较大的表对象简单地放在单独的文件组中(在单独的主轴上)还是指的是表对象内的数据分区?
  • 表变量在SQL Server存储过程中插入时性能较差(Table variable poor performance on insert in SQL Server Stored Procedure)
    问题 我们在存储过程中使用表变量遇到性能问题。 这是实际发生的情况: DECLARE @tblTemp TABLE(iId_company INT) INSERT INTO @tblTemp(iId_company) SELECT id FROM ..... SELECT返回138个结果,但是在TABLE变量中插入需要1min15,但是当我使用具有相同SELECT的临时表时,woops需要0sec: CREATE TABLE #temp (iId_company INT) INSERT INTO #temp(iId_company) SELECT id FROM ... 是什么原因引起的? 回答1 使用临时表。 您会看到更好的性能。 但是,对于以下原因的详细解释超出了初始问题的范围: 一个表变量由SQL Server优化为一行,即假定将返回1行。 表变量不会创建统计信息。 Google临时表与表变量提供了大量资源和讨论。 如果您随后需要特定的帮助,请给我发送电子邮件或在Twitter上与我联系。 回答2 通常,对于较小的数据集,表变量应比临时表快。 对于更大的数据集,性能将下降,因为表变量不支持并行性(请参阅此文章)。 话虽这么说,但我还没有经验,或者发现经验如此之少,因为表变量比临时表慢。 回答3 没关系,但是您选择的是什么样子? 在SQL Server 2005中
  • 表与临时表性能(Table vs Temp Table Performance)
    问题 对于数百万条记录,哪个更快:永久表或临时表? 我只需要将它用于 1500 万条记录。 处理完成后,我们删除这些记录。 回答1 在您的情况下,我们使用称为临时表的永久表。 这是大型导入的常用方法。 事实上,我们通常使用两个临时表,一个包含原始数据,一个包含清理过的数据,这使得研究提要问题变得更加容易(它们几乎总是我们的客户发现向我们发送垃圾数​​据的新方式和不同方式的结果,但是我们必须能够证明这一点)。 另外,您可以避免诸如必须增加临时数据库或给想要使用临时数据库但必须等待它为您增长的其他用户带来问题等问题。 您也可以使用 SSIS 并跳过临时表,但我发现无需重新加载 50,000,000 表即可返回和研究的能力非常有用。 回答2 如果您不使用 tempdb,请确保您正在使用的数据库的恢复模式未设置为“完整”。 这将导致那些 50M 行插入的大量开销。 理想情况下,您应该尽可能在 RAID 10 上使用临时数据库、简单恢复模型,并提前调整其大小以为您的所有操作提供足够的空间。 关闭自动生长。 使用 INSERT ... WITH (TABLOCK) 避免行级日志记录: INSERT INTO StagingTable WITH (TABLOCK) (.....) SELECT ..... 批量插入也是如此。 如果删除并重新创建,请在插入之前创建聚集索引。 如果不能
  • 平面表与维度和事实的 Redshift 性能(Redshift Performance of Flat Tables Vs Dimension and Facts)
    问题 我正在尝试在平面 OLTP 表(不在 3NF 中)上创建维度模型。 有些人认为不需要维度模型表,因为报告的大部分数据都呈现单表。 但是该表包含的内容超过了我们需要的 300 列。 我是否仍应将平面表分为维度和事实,还是直接在报告中使用平面表。 回答1 您已经问了一个关于数据仓库的数据库建模的通用问题,这将为您提供可能不适用于您正在使用的数据库平台的通用答案 - 如果您想要能够使用的答案那么我建议更具体。 问题标签表明您使用的是 Amazon Redshift,该数据库的答案与 SQL Server 和 Oracle 等传统关系数据库不同。 首先,您需要了解 Redshift 与常规关系数据库有何不同: 1) 它是一个大规模并行处理 (MPP) 系统,它由一个或多个节点组成,数据分布在这些节点上,每个节点通常会完成回答每个查询所需的部分工作。 因为数据在节点之间的分布方式变得很重要,目标通常是让数据以相当均匀的方式分布,以便每个节点为每个查询做大约相等的工作量。 2) 数据以列格式存储。 这与 SQL Server 或 Oracle 的基于行的格式完全不同。 在列式数据库中,数据的存储方式使大型聚合类型的查询效率更高。 这种类型的存储部分否定了维度表的原因,因为在行中存储重复数据(属性)是相对高效的。 Redshift 表通常使用一列的值(分布键)跨节点分布。 或者