我正在使用MS SQL服务器。
我有一个名为“ User”的表,该表具有三列和默认索引,该表是使用表的主键UserId创建的。
我有一个Word文件,其中逐行包含用户信息。几乎有10000行。
我有一个程序,可从word文件中读取用户信息并将其插入数据库中。它是用Visual Studio中的C#编写的。该程序使用存储库和工作单元模式。
程序工作流程如下: 1)从word文件中读取一行用户信息。 2)根据信息创建用户对象 3)将对象写入存储库 4)提交在数据库中执行插入语句的工作。
基本上,该程序每次从Word文件中读取用户信息时都会执行“插入语句”。
这是我的问题。
我记录了每个“插入语句”的时间,随着插入的数据更多,我可以看到“插入语句”花费的时间更长。这是因为表的主键上具有默认的聚集索引,所以数据库有更多数据可以在B树中整理吗?
请启发我在SQL数据库中的插入语句之后和之前发生的事情。
谢谢你们。
答案 0 :(得分:0)
这是因为自数据库以来,数据库有更多数据要在B树中进行排序 一个表的主键上具有默认的聚集索引?
否。实际上,USERID autoincreament
和clustered index
是CI的理想选择。
由于PK候选者为Auto Increament
。数据将始终附加在最后一页。
但是,如果地址长于以前的日期,则可能发生Udate语句分页的情况。
请尽可能将地址设为varchar
,并使其尽可能地狭窄。
主要问题是非常频繁的插入,非常频繁的数据库命中。
如果要插入1000条记录,则一次创建UDT
并一次插入create 50/100
。您可以通过在insert方法中应用Paging逻辑来做到这一点,这很容易并且会有所帮助。
像使用Connection Pooling
一样优化UI层代码,在DAL(Sql parameter)
中保留相关的数据类型和变量的长度。
我记录了每个“插入语句”的时间,可以看到 由于插入了更多数据,因此“插入语句”花费的时间更长。是 这是因为数据库自从 表的主键上有默认的聚集索引?
否,因为用户ID不断增加。没有分类工作发生。 “插入sql脚本”中可能存在错误。罪魁祸首是数据库命中率很高。
Please enlighten me what happens after and before the insert statement in SQL database.
请启发我在SQL数据库中的插入语句之后和之后发生的事情。
无论何时插入数据,插入都会在两个地方进行。在数据页面的表级别和索引级别。
聚簇索引除了基于聚簇控制数据页内数据的排序标准和页面本身的顺序外,还可以在索引的叶级存储表的实际数据行。索引键。
索引页将发生分割。怎么样 ?假设有3个中间级别和4个叶子级别。 例如,如果现在插入1条记录,则2条记录将不会发生。在此阶段插入过程将很快。
假设您再插入几条记录(例如10,20之后),那么中级水平和叶级都会增加。因为索引页有空间限制,所以当它没有时
更长的时间可以容纳新记录,然后它将拆分页面以容纳新记录。由于这个原因,列的长度应尽可能地窄。
但是在您的情况下,聚簇索引不必执行criteriA排序。因此,聚簇索引执行的工作要少一些。
“索引”页面的拆分成本也将低于非自动取消键或宽键。
由于您经常插入记录,因此会不时影响您的性能。
在大容量插入索引的情况下,页面拆分会减少,因此性能会提高。
在HEAP表中,由于没有要维护的聚簇索引,因此它要做的事少了。因此,非常频繁的插入可能会改善。
但是您必须决定插入效果与选择效果。
如果该表非常频繁地用于获取记录,则您可以保持聚集索引。 如果很少使用或记录少于100的HEAP表是可以的。
进一步阅读
答案 1 :(得分:0)
如果您的Word文档包含UserId(PRIMARY KEY),然后将其插入到表中,我将明白为什么这样做会很慢。
了解群集索引与非群集索引。
在聚集索引中,每个表的物理行均根据索引进行重新排列。要使用日常类比,就像在书架上按字母顺序排列书籍(记录)。每次有新书问世时,您都必须在物理上重新排列其他书本,以便正确维护字母索引。显然,这对于插入来说非常慢,但是对于SELECTS来说确实非常快。
另一方面,当出现新记录时,非聚集索引不会改变表中的物理行。如果您想按以下方式查找书本,可以使用书架作为类比:作者,您可以在纸上保留一张纸作为“索引卡”,以查找与特定作者匹配的书架中的位置。
如果您要一次插入大量记录,我对您的问题的解决方法是: