# Aurora DSQL 的计费方式
使用 Amazon Aurora DSQL，您只需按实际使用量付费，没有预付费用。本节介绍 Aurora DSQL 如何计量您的数据库活动并将其转换为 AWS 账单上的费用。有关当前按区域划分的定价，请参阅 [Aurora DSQL 定价页面](https://aws.amazon.com/rds/aurora/dsql/pricing/)。
**Topics**
+ [计费方式](#billing-how-metering-works)
+ [DPU 组成部分计量说明](#billing-dpu-components)
+ [多区域计费](#billing-multiregion-write-dpu)
+ [使用 CloudWatch 监控 DPU 使用情况](#billing-cloudwatch-monitoring)
+ [使用 EXPLAIN ANALYZE VERBOSE 了解成本](#billing-explain-analyze)
+ [成本估算最佳实践](#billing-best-practices)
## 计费方式
与按预置容量收费的传统数据库不同，Aurora DSQL 仅按照实际执行的工作量收费。Aurora DSQL 计量两个主要组成部分：按分布式处理单元（DPU，Distributed Processing Unit）衡量的数据库活动，以及按 GiB-月衡量的存储空间。
DPU 衡量系统为运行 SQL 工作负载所执行的工作量，在单区域集群中，工作量包括三个组成部分：计算 DPU、读取 DPU 和写入 DPU。多区域集群会产生额外的多区域写入 DPU 组成部分。有关详细信息，请参阅[多区域计费](#billing-multiregion-write-dpu)。
下表汇总了 Aurora DSQL 在计量数据库活动时所用的组成部分。在账单上，您将只看到两个行项目：一个表示存储空间，一个表示 DPU，后者是各个组成部分的总和。
| 计量单位 | 活动类型 | 测量 |
| --- | --- | --- |
| 计算 DPU | 查询处理 | CPU 时间 |
| 读取 DPU | 从数据库中读取数据 | 从存储中读取的字节数 |
| 写入 DPU | 将数据写入数据库 | 写入存储的字节数 |
| 仓储服务 | 表存储 | GiB-月 |
## DPU 组成部分计量说明
对于每个事务，Aurora DSQL 计算的总 DPU 是三个组成部分之和：计算 DPU、读取 DPU 和写入 DPU。以下部分说明 Aurora DSQL 如何计量各个组成部分。
```
Total DPU = ComputeDPU + ReadDPU + WriteDPU
```
### ComputeDPU
在衡量计算 DPU 时，使用的是执行查询所用的总处理时间，这包括联接、函数、聚合、排序和查询计划。由于查询的各个部分可以并行处理，因此计算 DPU 反映的是所有处理时间的总和，而不是查询的实际执行时间。
以下公式总结了计算 DPU 的计算方法：
```
ComputeDPU = Total Compute time (in seconds)
```
### WriteDPU
对于每个事务，Aurora DSQL 按照写入到存储的总字节数来衡量写入 DPU。写入 DPU 包括写入基表以及任何二级索引的数据总量。对写入基表和二级索引的每一行，在不足 128 字节时，Aurora DSQL 按 128 字节计费。对于写入事务，在不足 1024 字节时，Aurora DSQL 按 1024 字节计费。
**注意**
写入操作还会产生 ReadDPU 费用，因为 Aurora DSQL 在写入之前会读取主键索引以验证唯一性。
以下公式演示了计算写入 DPU 的步骤：
**第 1 步：计算写入的字节数**
```
Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written
```
**第 2 步：计算 WriteDPU**
```
WriteDPU = max(Bytes Written, 1024) × 0.00004883
```
### ReadDPU
对于每个事务，Aurora DSQL 按照从存储读取的总字节数来衡量读取 DPU。读取 DPU 包括从基表以及从任何二级索引读取的数据。
**每分区最低计费标准：**Aurora DSQL 衡量对每个存储分区读取的字节数，而不是每行的字节数。如果对存储分区的读取请求返回的字节少于 128 字节，Aurora DSQL 会将其向上舍入为 128 字节。例如，如果查询从四个分区读取数据：从一个分区读取 200 字节，从其他三个分区中各读取 50 字节，则三个 50 字节的读取均向上舍入为 128 字节，因此总共对 200 \+ 128 \+ 128 \+ 128 = 584 个字节计费。
**事务最低计费标准：**对于读取事务，在读取的字节总数少于 2048 字节时，Aurora DSQL 按 2048 字节计费。
以下公式演示了计算读取 DPU 的步骤：
**第 1 步：计算读取的字节数**
```
Bytes Read = # of rows read × size of each row
```
**注意**
实际读取的字节数取决于数据如何分布在各个存储分区中，因为对于所有分区，均适用 128 字节的每分区最低计费标准。如果所有行大小都大于 128 字节，则只需将读取的行数乘以每行的大小即可。
**第 2 步：计算 ReadDPU**
```
ReadDPU = max(Bytes Read, 2048) × 0.00000183105
```
### 计费示例
以下示例演示对于常见的操作，Aurora DSQL 如何计算 DPU。这些示例中的成本值使用 us-east-1 区域的价格。对于其他区域的定价，请参阅 [Aurora DSQL 定价页面](https://aws.amazon.com/rds/aurora/dsql/pricing/)。
#### 示例：简单点查找（读取）
此示例演示点查找的 ReadDPU 计算，其中适用事务最低计费标准。
**架构：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查询：**
```
SELECT * FROM orders WHERE customer_id = 'cust-12345';
```
**场景：**查询返回 5 行，每行大约 100 个字节。假设所有行都位于一个存储分区中，则读取的字节总数为 5 × 100 = 500 字节。由于 500 字节超过了 128 字节的每分区最低计费标准，因此每分区最低计费标准不适用。
**计算 ReadDPU：**
```
ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
由于 500 < 2048，因此 2048 字节的事务最低计费标准适用。
**事务总成本：**
假设查询执行时间为 3 毫秒（0.003 秒）：
```
ComputeDPU: 0.003
ReadDPU: 0.00375
WriteDPU: 0.0
-------------------
Total DPU: 0.00675
```
#### 示例：筛选范围扫描（读取）
**架构：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
-- Table contains 100 orders for customer 'cust-12345'
```
**查询：**
```
SELECT * FROM orders
WHERE customer_id = 'cust-12345'
AND total_amount > 500.00;
```
**场景：**查询扫描 100 行以查找客户“cust-12345”，但 `total_amount > 500.00` 筛选条件将结果减少到仅返回 10 行。Aurora DSQL 对扫描的全部 100 行计费。假设所有行都位于一个存储分区中，则读取的字节总数为 100 × 100 = 10000 字节。
**计算 ReadDPU：**
```
ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831
```
由于 10000 字节超过了 2048 字节的事务最低计费标准，因此将使用实际读取的字节数。
**事务总成本：**
假设查询执行时间为 8 毫秒（0.008 秒）：
```
ComputeDPU: 0.008
ReadDPU: 0.01831
WriteDPU: 0.0
-------------------
Total DPU: 0.02631
```
**重要**
为了尽可能减少 ReadDPU 成本，请将查询和索引设计为仅扫描所需的行。在此示例中，在 `(customer_id, total_amount)` 上添加索引可以减少查询所扫描的行数。
#### 示例：单次插入（读写）
**架构：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查询：**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES ('cust-67890', 150.00, 'pending');
```
**场景：**插入 1 行，大约 100 个字节。
**WriteDPU 计算：**
*第 1 步 – 计算写入的字节数：*
```
1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes
```
*第 2 步 – 计算 WriteDPU：*
```
WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05
```
由于 128 < 1024，因此 1024 字节的事务最低计费标准适用。
**ReadDPU（主键检查）：**
Aurora DSQL 在写入之前会读取主键索引以验证唯一性。这会产生事务最低计费标准读取费用。
```
ReadDPU = 0.00375 (transaction minimum)
```
**事务总成本：**
假设查询执行时间为 8 毫秒（0.008 秒）：
```
ComputeDPU: 0.008
ReadDPU: 0.00375
WriteDPU: 0.05
-------------------
Total DPU: 0.06175
```
#### 示例：批量插入（读写）
**架构：**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**查询：**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES
('cust-001', 100.00, 'pending'),
('cust-002', 150.00, 'pending'),
... -- 100 rows total
('cust-100', 200.00, 'pending');
```
**场景：**插入 100 行，每行大约 100 个字节。
**WriteDPU 计算：**
*第 1 步 – 计算写入的字节数：*
```
100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes
```
*第 2 步 – 计算 WriteDPU：*
```
WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625
```
**ReadDPU（主键检查）：**
Aurora DSQL 会读取每一行的主键索引以验证唯一性。假设所有 100 个键查找都位于一个存储分区中，则读取的字节总数为 100 × 16 字节（UUID）= 1600 字节。
```
ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
由于 1600 < 2048，因此 2048 字节的事务最低计费标准适用。
**事务总成本：**
假设查询执行时间为 80 毫秒（0.08 秒）：
```
ComputeDPU: 0.08
ReadDPU: 0.00375
WriteDPU: 0.625
-------------------
Total DPU: 0.70875
```
## 多区域计费
除了标准的计算 DPU、读取 DPU 和写入 DPU 之外，多区域集群还会产生额外的多区域写入 DPU 组成部分。本节仅适用于多区域集群。单区域集群不会产生此费用。
多区域写入 DPU 测量写入对等区域的总字节数。由于 Aurora DSQL 同步复制写入对等区域的数据，因此多区域写入 DPU 值等于写入 DPU 的值。Aurora DSQL 在发起写入的区域对此 DPU 收费，而不是在对等区域中。
```
MultiRegionWriteDPU = WriteDPU
```
## 使用 CloudWatch 监控 DPU 使用情况
Aurora DSQL 向 Amazon CloudWatch 发布使用情况指标，这样您就可以近乎实时地监控使用量。
### 可用 DPU 指标
**DPU 指标**
| CloudWatch 指标 | 说明 | 维度 |
| --- | --- | --- |
| WriteDPU | 写入使用量组成部分 | ClusterId |
| ReadDPU | 读取使用量组成部分 | ClusterId |
| ComputeDPU | 查询处理组成部分 | ClusterId |
| MultiRegionWriteDPU | 多区域复制（仅适用于多区域集群）。 | ClusterId |
| TotalDPU | 所有 DPU 组成部分之和 | ClusterId |
### 查看 DPU 指标
**在 CloudWatch 中查看 DPU 指标**
1. [打开 CloudWatch 控制台](https://console.aws.amazon.com/cloudwatch)。
1. 依次导航到**指标**、**AuroraDSQL** 和 **ClusterId**。
1. 选择要监控的集群和 DPU 指标。
**提示**
对于 DPU 指标，使用**总和**统计数据来查看一段时间内的总使用量。添加 **LAST** 标签以查看最新的值。
### 其他可观测性指标
有关 Aurora DSQL 指标和监控功能的完整列表，请参阅[Aurora DSQL 的监控和日志记录](monitoring-overview.md)。
**可观测性指标**
| 指标 | 说明 |
| --- | --- |
| ClusterStorageSize | 当前存储大小，以字节为单位 |
| TotalTransactions | 执行的事务总数 |
| ReadOnlyTransactions | 执行的只读事务数 |
| QueryTimeouts | 超过时间限制的查询数 |
| OccConflicts | 由于 OCC 冲突导致中止的事务数 |
| BytesWritten | 写入存储的原始字节数 |
| BytesRead | 从存储中读取的原始字节数 |
## 使用 EXPLAIN ANALYZE VERBOSE 了解成本
Aurora DSQL 对 `EXPLAIN ANALYZE VERBOSE` 进行了扩展，以便在输出末尾包含语句级 DPU 使用量估算值。这可让您即时了解查询成本，并帮助您识别工作负载成本驱动因素、优化查询性能，并更准确地预测资源使用量。
**注意**
您必须使用 `EXPLAIN ANALYZE VERBOSE`（带 VERBOSE）才能查看 DPU 估计值。只使用 `EXPLAIN ANALYZE` 而没有 VERBOSE 不会显示 DPU 信息。
### 示例 1：SELECT 查询
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
在此示例中，SELECT 语句执行了一次仅索引扫描，因此大部分成本来自读取 DPU（0.04312）和计算 DPU（0.01607），前者表示从存储中检索数据所使用的资源，后者反映处理并返回结果所使用的计算资源。由于该查询未修改数据，因此不存在写入 DPU。总 DPU（0.05919）为计算 DPU、读取 DPU 与写入 DPU 的总和。
### 示例 2：INSERT 查询
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
此语句主要执行写入操作，因此大部分成本与写入 DPU 相关。计算 DPU（0.01550）表示处理并插入值所使用的计算资源。读取 DPU（0.00307）反映系统轻量级读取操作（如目录查询或索引检查）所使用的资源。
请注意读取 DPU 和写入 DPU 旁边的括号中显示的事务最低计费标准。这些最低计费标准在事务级别应用，这意味着整个事务的总读取 DPU 或总写入 DPU 永远不会低于这些值。如果您使用 `EXPLAIN ANALYZE VERBOSE` 预测成本，并且这是事务中的唯一语句，请使用事务最低计费标准值而不是原始语句的估算值。如果事务包含多个语句，则最低计费标准适用于所有语句的总和。由于 `EXPLAIN ANALYZE VERBOSE` 报告语句级别的估算值，但系统根据事务级别的最低计费标准进行计费，因此这些值可能与 CloudWatch 指标或计费数据不完全一致。
### 利用 DPU 信息进行优化
单语句 DPU 估算为您提供了一种强大的查询优化方式，其价值不仅限于缩短执行时间。常见使用案例包括：
+ **成本感知：**了解某一查询相对于其他查询的成本高低。
+ **架构优化：**比较索引或架构变更对性能与资源效率产生的影响。
+ **预算规划：**基于观测到的 DPU 使用量来估算工作负载成本。
+ **查询比较：**根据相对 DPU 使用量来评估替代查询方法。
### 解释 DPU 信息
使用 `EXPLAIN ANALYZE VERBOSE` 中的 DPU 数据时，请记住以下最佳实践：
+ **定向地使用 DPU 数据：**将报告的 DPU 值视为了解查询*相对*成本的依据，而非与 CloudWatch 指标或计费数据完全一致的精确值。预计会出现差异，因为 `EXPLAIN ANALYZE VERBOSE` 报告的是语句级成本，而 CloudWatch 聚合的是事务级活动。此外，CloudWatch 还包括 `EXPLAIN ANALYZE VERBOSE` 有意排除的后台操作（例如异步 ANALYZE 或压缩）和事务开销（`BEGIN`/`COMMIT`）。
+ **使用代表性数据开展测试来进行概念验证：**在运行概念验证以评估成本时，请确保您的表包含与预期生产工作负载相似的数据量和数据分布。基于空表或稀疏填充的表的 DPU 估算值，无论是通过 `EXPLAIN ANALYZE VERBOSE` 还是 CloudWatch 指标得到，都无法反映实际成本。
+ 在分布式系统中，**DPU 在不同的运行间存在波动是正常现象**，并不表示出现错误。缓存、执行计划更改、并发性、后台操作（如异步 ANALYZE）或数据分布偏移等因素都可能导致同一查询在不同的运行时消耗的资源量存在差异。
+ **批量执行较小的操作**：如果您的工作负载发布大量的小语句，建议将这些语句合并成为单个事务中较大的写入操作来批量执行（每个事务的修改数据量不可超过 10 MB，虽然读取只受 5 分钟事务超时的限制）。这可以将事务最低计费标准分摊到更多的工作中，从而得出更有意义的成本估算值。
+ **用于调优，而非计费：**`EXPLAIN ANALYZE VERBOSE` 中的 DPU 数据专为成本感知、查询调优和优化设计，并非计费级指标。要获取权威的成本和使用量数据，请始终以 CloudWatch 指标或月度账单报告为准。
## 成本估算最佳实践
+ **在优化之前进行监控：**在做出优化决策之前，使用 CloudWatch 指标来了解您当前的使用模式。有关更多信息，请参阅 [使用 CloudWatch 监控 DPU 使用情况](#billing-cloudwatch-monitoring)。
+ **重视事务效率：**由于最低计费标准在事务级别应用，因此将相关的操作一起批量执行可以分摊最低费用。
+ **在开发过程中使用 EXPLAIN ANALYZE VERBOSE：**在开发过程中，对关键查询运行 `EXPLAIN ANALYZE VERBOSE` 以了解其成本特征。运行概念验证来评估成本时，请使用具有代表性数据量和数据分布的表进行测试，基于空表或稀疏填充的表得到的估算值无法反映生产成本。有关更多信息，请参阅 [使用 EXPLAIN ANALYZE VERBOSE 了解成本](#billing-explain-analyze)。
+ **设置 CloudWatch 警报：**根据 DPU 指标创建警报，以便在意外使用量激增时接收通知。