对于合理可行的SQL查询速度,您是否有任何正式或非正式标准？你是如何执行它们的？假设生产OLTP数据库在每秒几十个查询的完全实际生产负载下,正确配备和配置.
出于说明目的的个人示例(不是推荐,非常依赖于许多因素,有些因素超出您的控制范围):
期望:
每个事务单元(单个语句,从开始到结束事务边界的多个SQL语句,或单个存储过程,以最大者为准)必须在1秒或更短的时间内执行,没有异常异常值.
解析度:
较慢的查询必须根据标准进行优化.报告和其他分析的慢查询将移动到OLAP多维数据集(最佳情况)或静态快照数据库.
(显然有些执行查询(插入/更新/删除)无法移动,因此必须进行优化,但到目前为止,根据我的经验,这是可以实现的.)
鉴于您无法预期系统上的确定性性能(至少在理论上)会受到瞬态负载峰值的影响,您希望性能SLA具有概率性.一个例子可能是:
95%的交易在2秒内完成.
95%的搜索查询(更适合搜索屏幕)在10秒内完成.
95%的运营报告在10秒内完成.
事务性和搜索查询无法从事务性系统移出,因此您可以采取的唯一操作是数据库或应用程序调优,或购买更快的硬件.
对于运营报告,您需要对有资格作为运营报告的内容进行无情的处理.只有绝对需要访问最新数据的报告才能在实时系统上运行.执行大量I/O的报告在生产系统上非常反社交,规范化模式往往对报告效率很低.将任何不需要实时数据的报表移动到数据仓库或其他单独的报表工具中.
在编写/重构存储过程时，我通常遵循一秒规则，尽管我的工作场所对此没有任何具体规则。这只是我的常识。经验告诉我，如果执行一个过程需要十秒或更长时间，并且不执行任何大容量插入，则代码中通常存在可以轻松纠正的严重问题。
我在性能较差的 SP 中遇到的最常见问题是不正确地使用索引，从而导致昂贵的索引查找操作。
| 归档时间： |
|
| 查看次数： |
632 次 |
| 最近记录： |