问题描述
我有一个查询，该查询使用主键查找表中的字段来更新表中的字段。该表可以包含许多行，其中date / time字段最初为NULL，然后使用Now（）使用日期/时间戳进行更新。
当我在表上运行update语句时，查询日志条目变慢（3.38秒）。该日志表明已检查了200,000行。如果我使用PK识别正在更新的行，为什么还要检查那么多行？
主键是item_id和customer_id。我已验证MysqL表结构中的PRIMARY键正确。
<nav class="navbar navbar-expand-lg navbar-light bg-light fixed-top">
解决方法
我想知道这是否是硬件问题。
虽然我在评论中提到的更改可能会有所帮助，但实际上，我无法复制此问题...
我有大约100万行的数据集...：
rst没有更新就选择记录需要多长时间？
如果选择速度很快，那么您需要研究会影响更新/写入速度的事物。
- 表上的索引太多，不要忘记过滤后的索引和索引视图
- 索引页的填充因子为0，需要拆分以适应数据更改。
- 具有级联的引用约束
- 触发器
- 存储级别的写入速度慢
如果选择缓慢
- 有关索引的旧/错误统计信息
- 极度破碎
- 打开的行组过多的列存储索引
如果第一次之后选择速度有了显着提高，则可能存在一些冷缓冲区性能问题。那也可能指出存储I / O问题。
您还可能由于另一个进程暂时锁定表而导致并发问题。
最后，执行查询的工具是否有可能返回错误的持续时间？例如，即使服务器处理得非常快，SQL Server Management Studio偶尔也会很慢地返回较大的结果集。