如何操作DeleteRow
行为：
删除一行数据。
请求消息结构：message DeleteRowRequest {
required string table_name = 1;
required bytes primary_key = 2; // Plainbuffer编码为二进制
required Condition condition = 3;
optional ReturnContent return_content = 4;
}
table_name：
类型：string
是否必要参数：是
请求更新数据的表名。
primary_key
类型：bytes
是否必要参数：是
删除行的主键，Plainbuffer格式，编码详见Plainbuffer编码。
condition:
类型: Condition
是否必要参数: 是
在数据更新前是否进行存在性检查，可以取下面两个值：
IGNORE：表示不做行存在性检查。
EXPECT_EXIST：表示期望行存在。
若期待该行存在，但实际该行不存在，则本次删除操作会失败, 返回错误；若忽视该行是否存在，则无论该行实际是否存在，都不会因此导致操作失败。
return_content:
类型：ReturnContent
是否必要参数：否
写入成功后返回的数据类型。目前仅支持返回主键，主要用于主键列自增功能中。
响应消息结构：
message DeleteRowResponse {
required ConsumedCapacity consumed = 1;
optional bytes row = 2;
}consumed：
类型：ConsumedCapacity
本次操作消耗的服务能力单元。
服务能力单元消耗:
如果该行不存在：
若指定条件检查为 IGNORE，消耗写服务能力单元的数值为该行主键数据大小除以 4 KB 向上取整。
若指定条件检查为 EXPECT_EXIST，删除该行失败，消耗 1 单位的写 CU 和 1 单位的读 CU。
如果该行存在：
若指定条件检查为 IGNORE，消耗写服务能力单元的数值为该行主键数据大小除以 4 KB 向上取整。
若指定条件检查为 EXPECT_EXIST，除了消耗该行主键数据大小除以 4 KB 向上取整的写 CU，还需消耗该行主键数据大小除以 4 KB 向上取整的读 CU。
关于数据大小的计算请参见产品定价。
如果返回内部错误（HTTP 状态码：5XX），则此次操作不消耗服务能力单元；其他错误情况消耗 1 个写服务能力单元。
如果请求超时，结果未定义，服务能力单元有可能被消耗，也可能未被消耗。
row：
类型：bytes
当设置了return_content后，返回的数据。
如果没有设置return_content或者没有返回值，此处为NULL。
Plainbuffer格式，编码详见Plainbuffer编码。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
您提到的是在使用阿里云表格存储（Table Store，原OTS）时进行删除一行数据的操作细节。下面是对您描述的请求消息结构、参数含义以及响应消息结构的解析和补充说明：
请求消息结构
-
table_name：这是要操作的表的名称，是必填项。确保您提供的是正确的表名，因为这直接决定了数据操作的目标。
-
primary_key：用于指定要删除的行的主键。主键必须以Plainbuffer编码格式提供，这是一种高效的二进制序列化格式，用于减少网络传输和存储开销。您需要根据实际数据结构对主键进行编码。
-
condition：这是一个重要的参数，用来控制删除前是否检查行的存在性。如果设置为
IGNORE，则无论目标行是否存在都会尝试执行删除操作，并且不会因行不存在而失败；若设为EXPECT_EXIST，则只有当目标行存在时删除操作才会成功，否则操作失败并返回错误。 -
return_content：这是一个可选参数，用于指定在删除操作成功后是否需要返回某些数据。如果希望获取被删除行的主键信息（例如，在自增列场景中），可以设置此选项。注意，返回的数据也是Plainbuffer编码的。
响应消息结构
-
consumed：表示本次删除操作消耗的服务能力单元（Capacity Unit, CU）。CU是衡量和计费的基本单位，包括读CU和写CU。具体消耗量依据操作类型、数据大小及是否存在性检查条件而定。
-
row：仅当请求中设置了
return_content并且有数据可返回时，这里会包含返回的数据，同样是以Plainbuffer编码。如果没有设置或没有数据返回，则该字段为NULL。
注意事项
- 在设计条件检查(
condition)时，需根据业务逻辑决定是否需要确认行的存在性，以避免不必要的读CU消耗或操作失败。 - 了解并监控CU消耗对于成本控制和性能优化至关重要，特别是在高并发或大数据量操作的场景下。
- 对于超时或内部错误情况下的CU消耗，虽然定义上可能不计费，但实际应用中应尽量避免这些异常情况，以确保操作的确定性和成本效率。
通过上述详细说明，您可以更准确地构造和理解针对阿里云表格存储的删除行操作请求及其响应，从而高效地管理您的数据。
