我正在使用MS SQL server。
我有一个名为"User"的表，有三列和默认索引，它是用表的主键创建的，属于UserId。
我有一个逐字逐句包含用户信息的word文件。有近10000条线路。
我有一个程序，可以从word文件中读取用户信息并将其插入数据库。它是用visual studio中的C#编写的。该程序使用存储库和工作单元模式。
程序工作流程如下：1) 从单词文件中读取一行用户信息。2) 基于信息创建用户对象3) 将对象写入存储库4) 提交执行数据库insert语句的工作。
基本上，程序每次从word文件中读取用户信息时都会执行"插入语句"。
这是我的问题。
我记录了每个"插入语句"的时间，我可以看到，随着插入的数据越来越多，"插入语句"需要更长的时间。这是因为数据库在B树中有更多的数据要排序，因为表的主键上有默认的聚集索引吗？
请告诉我在SQL数据库中插入语句前后会发生什么。
谢谢大家。
这是因为数据库在B树中有更多的数据需要排序吗表的主键上有默认聚集索引吗？
否。事实上，USERID autoincrement和clustered index是CI的理想选择
由于候选PK是自动递增的，数据将始终附加在最后一页。
然而，在更新语句的情况下，如果地址的长度比以前长，则可能会发生页面分割。
如果可能，将地址设置为varchar，并尽可能缩小。
主要问题是非常频繁的插入，非常频繁的数据库命中。如果要插入1000条记录，则一次创建UDT和插入创建50/100。您可以通过在insert方法中应用分页逻辑来实现这一点。这很容易，也会有所帮助。
优化您的UI层代码，如使用Connection Pooling，在DAL(Sql parameter)中保留相关的数据类型和变量的传递长度。
我记录了每个"；插入语句"；，我可以看到"插入语句"；插入的数据越多，所需时间就越长。是这是因为数据库在B树中有更多的数据需要排序，因为表的主键上有默认的聚集索引吗？
否，因为用户ID一直在增加。没有进行分拣工作。可能是"插入sql脚本"中存在错误。罪魁祸首是频繁的数据库命中。
Please enlighten me what happens after and before the insert statement in SQL database.
请告诉我在SQL数据库中插入语句前后会发生什么。
每当插入数据时，插入将在两个位置进行。在数据页的表级别和索引级别。
聚集索引除了根据聚集索引键控制数据页内数据的排序标准和页本身的顺序外，还将表的实际数据行存储在索引的叶级别
将发生索引页拆分。怎样假设有3个中间层和4个叶层。例如，现在如果插入1条记录，则插入2条记录，将不会发生任何事情。该阶段的插入过程将很快。
假设你再插入一些记录(比如在10,20之后)，那么中间的羽球和叶片水平都会增加。因为索引页有空间限制，所以当它没有时
能够容纳新记录的时间越长，则它将拆分页面以容纳新记录。由于这个原因，列的长度应该尽可能短。
但在您的情况下，聚集索引不必做排序标准A。因此，Cluseted索引少做了一项工作。
此外，索引页拆分成本将小于非自动递增键或宽键。
由于您非常频繁地插入记录，这会不时影响您的性能。
在大容量插入索引的情况下，页面分割会更少，因此性能会有所提高。
在HEAP表中，由于没有集群索引来维护，所以它少了一项任务要做。所以非常频繁的插入可能会有所改进。
但您必须决定插入性能与选择性能。
如果这个表经常被用来获取记录，那么您必须保留聚集索引。如果它很少使用或记录少于100 HEAP表是可以的。
进一步读取，
索引结构和概念
索引体系结构和设计指南
堆(没有聚集索引的表)
如果您的Word文档包含UserId(PRIMARY KEY)，然后将其插入到表中，我可以理解为什么这会非常慢。
理解集群索引与非集群索引。
在CLUSTERED INDEX中，根据索引重新排列每个表的物理行。用每天的比喻，这就像按字母顺序排列书架上的书(记录)。每次有新书问世，你都必须对其他书籍进行物理重新排列，以便正确地保持按字母顺序排列的索引。显然，这对于插入来说非常慢，但对于SELECTS来说非常快。
另一方面，当有新记录出现时，非聚集索引不会改变表中的物理行。以书架为例，如果你想按作者查找书籍，你可以在书架的侧面放一张纸作为"索引卡"，以查找书架上与特定作者相匹配的书籍的位置。
如果你要同时插入大量记录，我的解决方案是：
- 删除索引
- 批量插入数据
- 重新创建索引