Грузчик Asked:2022-08-06 19:42:03 +0800 CST2022-08-06 19:42:03 +0800 CST 2022-08-06 19:42:03 +0800 CST 使用慢速硬盘来模拟查询延迟是否正确？ 772 为了在安装了 ssd 的生产环境中优化数据库查询，我想在慢容量存储上优化它们。对于 SSD 上具有相同查询的相同数据库，优化是否相同？ база-данных 1 个回答 Voted Best Answer S.H. 2022-08-06T20:01:39+08:002022-08-06T20:01:39+08:00 不幸的是，不会，不会。 不受磁盘速度影响的查询示例：尝试执行称为“表扫描”的操作 - 例如使用where Name like '%тра та та%'. 在这里，从磁盘读取串行数据的速度将不再是决定性的。在这两种情况下，查询的性能同样很差，特别是因为在第一次调用之后，数据库页面很可能会保留在内存缓存中。 查询本身很慢的另一种情况：select top 50 * from (...) union (...) order by ...在数据库的不同部分执行子查询而不是省略号。不做全表扫描就无法处理这个查询：必须先计算完整的子查询，然后组合它们，然后取top'chik。 这些只是您有时不得不偶然发现的错误查询的琐碎案例。 如果您想模拟一个慢速网络 - 有一堆“查询速度较慢”，例如，这里有一个命令将“增加 250 毫秒延迟，将带宽限制为 1 Mbps 并将 10% 的数据包丢弃到指定地址使用指定端口上的指定协议”。 也许并非所有这些都是必要的，但添加延迟可以让您在客户“过于积极”与基地沟通时找到问题区域，非常自信。 但是要模拟基地的行为......我不知道。但是用另一种硬盘替换一种硬盘并不是一种非常合适的建模方法：总比没有好，但并非所有可能的“刹车”都可以识别
不幸的是，不会，不会。
不受磁盘速度影响的查询示例：尝试执行称为“表扫描”的操作 - 例如使用
where Name like '%тра та та%'.在这里，从磁盘读取串行数据的速度将不再是决定性的。在这两种情况下，查询的性能同样很差，特别是因为在第一次调用之后，数据库页面很可能会保留在内存缓存中。
查询本身很慢的另一种情况：
select top 50 * from (...) union (...) order by ...在数据库的不同部分执行子查询而不是省略号。不做全表扫描就无法处理这个查询：必须先计算完整的子查询，然后组合它们，然后取top'chik。这些只是您有时不得不偶然发现的错误查询的琐碎案例。
如果您想模拟一个慢速网络 - 有一堆“查询速度较慢”，例如，这里有一个命令将“增加 250 毫秒延迟，将带宽限制为 1 Mbps 并将 10% 的数据包丢弃到指定地址使用指定端口上的指定协议”。
也许并非所有这些都是必要的，但添加延迟可以让您在客户“过于积极”与基地沟通时找到问题区域，非常自信。
但是要模拟基地的行为......我不知道。但是用另一种硬盘替换一种硬盘并不是一种非常合适的建模方法：总比没有好，但并非所有可能的“刹车”都可以识别