优化云服务成本¶
如果您发现 云服务使用量 高于预期，请检查您对 Snowflake 的使用是否遵循以下任一模式。每种模式都包含一项建议，可帮助您降低与云服务相关的成本。
- 模式：事务锁导致查询受阻
更新和合并命令会在表上加一个事务锁，在释放锁之前，其他命令无法在该表上执行。查询在等待锁释放的过程中会使用云服务 Credit。查询在云服务层等待锁的时间越长，使用的 Credit 就越多。
建议： 当用户在单个表上并发运行更新/合并命令时，尤其是当每个命令只更新几行时，经常会出现事务锁。您可以使用批处理命令而不是单个更新，更大限度地减少这些锁。在该策略中，您将执行以下步骤：
使用批处理 INSERT 语句将新数据加载到临时表中。避免使用单行插入即使是连续加载新数据的 API 调用，其设计方式也应是提交批处理插入，而不是单行插入。
使用临时表更新/合并目标表。
如果数据源全天不断发送新数据，可考虑使用 任务 定期更新目标表。
- 模式：选择性较差的复制命令
执行复制命令需要列出 Amazon Simple Storage Service (S3) 中的文件。由于列出文件只使用云服务计算，因此执行选择性较差的复制命令会增加云服务使用量。
建议： 考虑更改 S3 桶的结构，使其包含某种日期前缀，以便只列出所需的目标文件。
- 模式：高频率 DDL 操作和克隆
数据定义语言 (DDL) 操作，尤其是克隆，完全是元数据操作，这意味着它们只使用云服务计算。经常创建或删除大型架构或表，或克隆数据库进行备份，都会导致大量云服务使用量。
建议： 克隆仅使用深度复制所需资源的一小部分，因此您应该继续克隆。审查克隆模式，确保它们尽可能细化，并且不会被过于频繁地执行。例如，您可能只想克隆单个表，而不是整个架构。
- 模式：高频率、简单的查询
单个简单查询的云服务使用量可以忽略不计，但以极高频率（每天数万次）运行
SELECT 1、SELECT sequence1.NEXTVAL或SELECT CURRENT_SESSION()等查询会产生极大的云服务使用量。建议： 审查查询频率，并确定频率设置是否适合用例。如果发现使用 JDBC 驱动程序的合作伙伴工具产生的
SELECT CURRENT_SESSION()查询频率很高，请确认合作伙伴已更新其代码，以使用 SnowflakeConnection 接口 中的getSessionId()方法。这样可以利用缓存，减少云服务的使用量。
- 模式：高频率 INFORMATION_SCHEMA 查询
针对 Snowflake Information Schema 的查询只使用云服务资源。针对 INFORMATION_SCHEMA 视图的单次查询对云服务的使用量可能忽略不计，但以极高的频率（每天数万次）运行这些查询，会导致大量云服务使用量。
建议： 审查查询频率，并确定频率设置是否适合用例。另外，您还可以查询 ACCOUNT_USAGE 架构 中的视图，而不是 INFORMATION_SCHEMA 视图。查询 ACCOUNT_USAGE 架构使用的是虚拟仓库而不是云服务。
- 模式：高频率 SHOW 命令（由数据应用程序和第三方工具发出）
SHOW 命令完全是元数据操作，这意味着它们只使用云服务计算。当您基于 Snowflake 创建应用程序时，以高频率执行 SHOW 命令，通常会发生这种模式。这些命令也可能由第三方工具启动。
建议： 审查查询频率，并确定频率设置是否适合用例。如果是合作伙伴的工具，请与合作伙伴联系，了解他们是否有调整使用量的计划。
- 模式：单行插入和碎片化架构（由数据应用程序提供）
Snowflake 不是 OLTP 系统，因此单行插入并不理想，而且会使用大量云服务资源。
如果构建的数据应用程序为每个客户定义一个架构，可能会导致在给定时间段内出现多个数据负载，从而造成较高的云服务使用量。
这种模式也使得 Snowflake 需要维护更多的元数据，而元数据操作会使用云服务资源。每个元数据操作单独使用的资源极少，但总体使用量可能很大。
建议： 一般情况下，进行批处理或批量加载，而不是单行插入。
使用共享架构可大大提高效率，从而节省成本。您可能希望基于
customer_ID对所有表进行聚类，并使用 安全视图。
- 模式：复杂 SQL 查询
如果查询包含许多联接/笛卡尔积，使用带大型列表的 IN 运算符，或者是非常大的查询，那么查询可能会使用大量的云服务计算。这些查询类型的编译时间都比较长。
建议： 审查查询，确认它们正在按照您的意图进行操作。Snowflake 支持这些查询，并且只对使用的资源收费。