@clickzetta/cz-cli-darwin-x64 0.3.1

package/bin/skills/lakehouse-doc/references/cancel-job.md

@@ -0,0 +1,51 @@
+# 终止作业
+
+## 功能描述
+
+本功能允许用户终止正在运行的作业或取消某个虚拟集群下的所有作业。通过该功能，用户可以有效地管理作业进度，避免资源浪费。
+
+## 语法说明
+
+```
+-- 取消单个作业
+CANCEL JOB 'jobid';
+
+-- 取消某个VIRTUAL CLUSTER下所有作业
+ALTER VCLUSTER [ IF EXISTS ] vc_name CANCEL ALL JOBS;
+```
+
+## 参数说明
+
+1. `jobid`：作业运行的唯一标识符，字符串格式。作业运行时，日志会打印出jobid，同时在[show jobs](<show-jobs.md>)命令中也会显示相应的jobid。
+2. `vc_name`：指定的虚拟集群名称。如果虚拟集群不存在，使用`IF EXISTS`选项可以避免因找不到集群而产生错误。
+
+## 使用示例
+
+### 示例1：取消单个作业
+
+假设您需要取消一个作业，其jobid为`201xxxxxxxxxx`。您可以使用以下命令实现：
+
+```
+CANCEL JOB '201xxxxxxxxxx';
+```
+
+### 示例2：取消某个虚拟集群下所有作业
+
+假设您需要取消名为`my_vc`的虚拟集群下的所有作业。首先，使用以下命令取消该虚拟集群下的所有作业：
+
+```
+ALTER VCLUSTER my_vc CANCEL ALL JOBS;
+```
+
+如果担心虚拟集群不存在导致错误，可以使用`IF EXISTS`选项：
+
+```
+ALTER VCLUSTER IF EXISTS my_vc CANCEL ALL JOBS;
+```
+
+## 注意事项
+
+* 确保在执行终止作业操作时，输入正确的`jobid`或`vc_name`，以免影响其他作业或虚拟集群的正常运行。
+* 终止作业后，已使用的资源将被释放，但请注意，已消耗的时间和费用可能无法退回。
+
+^

package/bin/skills/lakehouse-doc/references/cardinality_array.md

@@ -0,0 +1,45 @@
+### 函数名称：CARDINALITY
+
+#### 功能描述
+`CARDINALITY` 函数用于计算数组中元素的数量或映射中键值对的数量。
+
+#### 语法
+```
+CARDINALITY(array)
+CARDINALITY(map)
+```
+
+#### 参数说明
+- `array`: 输入的数组，元素类型为 `T`。
+- `map`: 输入的映射，由键类型 `K` 和值类型 `V` 组成。
+
+#### 返回类型
+- 返回一个整型数值（`int`），表示数组中元素的个数或映射中键值对的个数。
+
+#### 使用示例
+1. 计算数组中元素的个数：
+```
+SELECT CARDINALITY(ARRAY(1, 2, 3, 4, 5)); -- 返回 5
+```
+2. 计算映射中键值对的个数：
+```
+SELECT CARDINALITY(MAP("a", 1, "b", 2, "c", 3)); -- 返回 3
+```
+3. 结合实际数据表进行操作：
+假设有一个名为 `students` 的表，其结构如下：
+```
+CREATE TABLE students (
+  id INT,
+  name VARCHAR,
+  hobbies ARRAY<VARCHAR>
+);
+```
+向 `students` 表中插入一条数据：
+```
+INSERT INTO students (id, name, hobbies) VALUES (1, 'Alice', ARRAY('reading', 'swimming', 'traveling'));
+```
+使用 `CARDINALITY` 函数计算该学生的爱好数量：
+```
+SELECT CARDINALITY(hobbies) FROM students WHERE id = 1; -- 返回 3
+```
+

package/bin/skills/lakehouse-doc/references/charge_analysis_with_lakehouse_mcp_server.md

@@ -0,0 +1,393 @@
+# 云器 Lakehouse MCP Server 用户案例：费用异常分析与问题定位
+
+## 💬 核心问答过程展示
+
+### 用户问题序列
+
+```
+👤 用户: "分析一下sys.information_schema.instance_usage表里的数据，看下九月4日，九月5日的费用"
+
+🤖 MCP Server: [自动分析表结构] → [生成智能查询] → [输出费用报告]
+   发现：9月4日费用¥85.77，9月5日费用¥66.65，主要来自GP计算集群
+
+👤 用户: "为什么这两天费用偏高很多呢？"
+
+🤖 MCP Server: [历史数据对比] → [异常模式识别] → [趋势分析]
+   发现：正常日费用¥1-6，异常期间激增15倍，GP集群使用时长异常
+
+👤 用户: "看下是哪个实例那个工作空间的集群"
+
+🤖 MCP Server: [多维度分析] → [责任方定位] → [作业历史追踪]
+   发现：实例270397的quick_start工作空间，mcp_test_daily_summary动态表频繁刷新导致
+```
+
+### 关键洞察
+
+* **问题定位时间**: <= '2025-09-08'
+   GROUP BY date(measurement_start)
+   ORDER BY usage_date
+   ```
+
+2. **异常模式识别**
+
+**历史费用趋势分析**：
+
+| 时间段        | 日均费用       | 费用范围              | 状态          |
+| ---------- | ---------- | ----------------- | ----------- |
+| 8月25日-9月2日 | ¥1.8       | ¥0.99-¥6.06       | ✅ 正常基线      |
+| 9月3日       | ¥25.13     | -                 | ⚠️ 首次异常     |
+| **9月4-5日** | **¥76.21** | **¥66.65-¥85.77** | 🚨 **严重异常** |
+| 9月6日后      | ¥0.73      | ¥0.53-¥1.05       | ✅ 恢复正常      |
+
+3. **使用模式变化分析**
+
+   ```sql
+   SELECT 
+       date(measurement_start) as usage_date,
+       sku_name,
+       count(*) as record_count,
+       sum(measurements_consumption) as total_consumption_hours,
+       avg(measurements_consumption) as avg_consumption_per_record,
+       sum(total_after_discount) as total_cost
+   FROM sys.information_schema.instance_usage 
+   WHERE sku_category = 'compute'
+   GROUP BY date(measurement_start), sku_name
+   ```
+
+**GP集群使用模式对比**：
+
+| 日期       | 平均每小时消费     | 记录数     | 总消费时长       | 单次费用     |
+| -------- | ----------- | ------- | ----------- | -------- |
+| 9月1-2日   | 0.03-0.04小时 | 14-20条  | 0.37-0.76小时 | ¥1-3     |
+| **9月4日** | **0.57小时**  | **42条** | **24.05小时** | **¥3.5** |
+| **9月5日** | **0.58小时**  | **32条** | **18.71小时** | **¥3.5** |
+| 9月6日后    | 0.02小时      | 12条     | 0.20小时      | ¥0.7     |
+
+**关键发现**：
+
+* GP集群从短时查询模式变为长时间运行模式
+* 每小时消费时长增加**15倍**（0.04 → 0.57小时）
+* 接近满1小时计费，说明集群持续运行
+
+### 第三步：精确责任方定位
+
+**用户继续询问**：
+
+```
+看下是哪个实例那个工作空间的集群
+```
+
+**MCP Server多维度分析**：
+
+1. **实例和工作空间费用分布**
+
+   ```sql
+   SELECT 
+       instance_id,
+       workspace_name,
+       sku_name,
+       sum(total_after_discount) as total_cost
+   FROM sys.information_schema.instance_usage 
+   WHERE date(measurement_start) IN ('2025-09-04', '2025-09-05')
+     AND sku_category = 'compute'
+   GROUP BY instance_id, workspace_name, sku_name
+   ORDER BY total_cost DESC
+   ```
+
+**责任方分析结果**：
+
+| 实例ID       | 工作空间                         | 9月4日费用     | 9月5日费用     | 异常程度         |
+| ---------- | ---------------------------- | ---------- | ---------- | ------------ |
+| **270397** | **quick\_start**             | **¥83.48** | **¥64.77** | 🚨 **主要责任方** |
+| 270397     | lakehouse\_quick\_experience | ¥0.71      | ¥0.71      | ✅ 正常         |
+| 270397     | ns227206                     | ¥0.17      | ¥0.17      | ✅ 正常         |
+
+2. **具体集群使用详情**
+
+   ```sql
+   SELECT 
+       date(measurement_start) as usage_date,
+       hour(measurement_start) as usage_hour,
+       measurements_consumption,
+       amount
+   FROM sys.information_schema.instance_usage 
+   WHERE workspace_name = 'quick_start' 
+     AND sku_name = 'GP类型计算集群'
+     AND amount >
+
+**GP集群运行时间分析**：
+
+**9月4日异常模式**：
+
+* **00:00-23:59**：24小时持续运行
+* **每小时消费**：~1.00小时（几乎满小时计费）
+* **单小时费用**：¥3.5左右
+
+**9月5日异常模式**：
+
+* **00:00-18:59**：19小时持续运行
+* **费用模式**：同样接近满小时计费
+
+**关键发现**：
+
+* 问题锁定在 `quick_start` 工作空间的GP集群
+* 集群呈现24小时近乎不间断运行状态
+* **非**正常的短时查询模式
+
+### 第四步：根本原因追踪
+
+**MCP Server自动深入调查**：
+
+1. **作业历史分析**
+
+   <= '2025-09-06 23:59:59'
+   ```
+
+**正常期间作业特征**：
+
+* 查询执行时间：几秒到几分钟
+* 集群自动挂起：查询完成后快速释放
+* 费用模式：按实际使用时间计费
+
+## 问题根源深度解析
+
+### 技术层面分析
+
+**1. 动态表配置错误**
+
+```sql
+-- 问题配置（推测）
+CREATE DYNAMIC TABLE mcp_test_daily_summary
+REFRESH_INTERVAL = '5 MINUTES'  -- ❌ 过于频繁
+AS SELECT ...
+```
+
+**2. 集群资源管理失效**
+
+* **正常模式**: 查询完成 → 集群空闲 → 自动挂起（几分钟内）
+* **异常模式**: 查询完成 → 5分钟后新查询 → 集群持续活跃 → 无法挂起
+
+**3. 费用计算逻辑**
+
+* **按小时计费**: GP集群按使用时长计费，¥3.5/小时
+* **最小计费单位**: 即使使用几分钟，活跃状态会累积计费时间
+* **累积效应**: 5分钟间隔刷新 → 24小时几乎满计费
+
+### 业务影响评估
+
+**1. 直接费用损失**
+
+* **异常期间**: 2天总费用¥152.42
+* **正常期间**: 2天预期费用¥2-12
+* **直接损失**: ¥140-150
+
+**2. 潜在风险**
+
+* **如未及时发现**: 每日额外费用¥80+
+* **月度影响**: 可能产生¥2400+额外费用
+* **资源浪费**: 集群资源未得到有效利用
+
+**3. 系统性问题**
+
+* **配置管理**: 动态表刷新策略缺乏合理性检查
+* **监控告警**: 费用异常未及时发现
+* **资源优化**: 集群自动管理策略需要优化
+
+## 解决方案与最佳实践
+
+### 立即修复措施
+
+**1. 动态表配置修正**
+
+```sql
+-- 检查当前配置
+DESC DYNAMIC TABLE mcp_test_daily_summary;
+
+-- 方案一：调整刷新间隔（推荐）
+ALTER DYNAMIC TABLE mcp_test_daily_summary 
+SET REFRESH_INTERVAL = '1 HOUR';
+
+-- 方案二：根据业务需求调整
+ALTER DYNAMIC TABLE mcp_test_daily_summary 
+SET REFRESH_INTERVAL = '4 HOURS';  -- 或其他合理间隔
+
+-- 方案三：暂停动态表（紧急情况）
+ALTER DYNAMIC TABLE mcp_test_daily_summary SUSPEND;
+```
+
+**2. 集群配置优化**
+
+```sql
+-- 检查集群自动挂起设置
+SHOW VIRTUAL_CLUSTERS;
+
+-- 确保合理的自动挂起时间
+ALTER VIRTUAL_CLUSTER your_gp_cluster 
+SET AUTO_SUSPEND_IN_SECOND = 300;  -- 5分钟自动挂起
+```
+
+### 预防性措施
+
+**1. 监控和告警**
+
+```sql
+-- 创建费用监控视图
+CREATE VIEW daily_cost_monitor AS
+SELECT 
+    date(measurement_start) as cost_date,
+    sum(total_after_discount) as daily_cost,
+    CASE 
+        WHEN sum(total_after_discount) >
+
+**2. 动态表最佳实践**
+
+* **刷新间隔建议**：根据数据更新频率设置，最短不低于30分钟
+* **资源考虑**：评估刷新对计算资源的影响
+* **业务对齐**：刷新频率应匹配实际业务需求
+
+**3. 资源管理策略**
+
+* **集群分离**：将定时任务和交互查询分离到不同集群
+* **时间窗口**：在低峰时段执行资源密集型任务
+* **成本预算**：设置工作空间级别的费用预算和告警
+
+## 案例价值与技术特色
+
+### 1. MCP Server智能分析能力
+
+**自然语言理解**
+
+* 无需用户掌握复杂的SQL语法
+* 智能理解分析意图并转换为精确查询
+* 支持多轮对话，逐步深入问题
+
+**自动化数据分析**
+
+```
+用户意图: "分析费用"→ 自动表结构识别→ 智能查询生成→ 多维度数据关联→ 异常模式识别→ 可视化结果展示
+```
+
+**上下文记忆能力**
+
+* 记住前序分析结果
+* 基于已有发现进行深入挖掘
+* 保持分析逻辑的连贯性
+
+### 2. 问题排查的系统性方法
+
+**层次化分析框架**
+
+1. **概览层**: 整体费用趋势识别
+2. **分解层**: 按维度拆解费用构成
+3. **定位层**: 精确定位责任方
+4. **根因层**: 追踪到具体技术原因
+
+**多维度关联分析**
+
+* 时间维度：历史对比、趋势分析
+* 空间维度：实例、工作空间、集群
+* 业务维度：作业类型、执行频率
+* 技术维度：资源使用、配置参数
+
+### 3. 实战价值
+
+**快速响应能力**
+
+* **问题发现到定位**：< 5分钟
+* **解决方案输出**: 立即可执行的SQL命令
+* **效果验证**: 实时查看修复结果
+
+**经济价值**
+
+* **直接节省**: ¥80+/天的费用节省
+* **避免损失**: 防止长期配置错误造成的持续损失
+* **效率提升**: 大幅减少人工排查时间
+
+**知识沉淀**
+
+* **可复用流程**: 分析方法可应用于其他类似问题
+* **最佳实践**: 形成标准化的问题排查流程
+* **预防指南**: 为其他用户提供经验参考
+
+## 结果验证与效果评估
+
+### 解决效果确认
+
+**费用恢复验证**
+
+```sql
+-- 创建费用监控视图
+CREATE VIEW daily_cost_monitor AS
+SELECT 
+    date(measurement_start) as cost_date,
+    sum(total_after_discount) as daily_cost,
+    CASE 
+        WHEN sum(total_after_discount) >
+
+**结果**：
+
+* 9月6日：¥1.05 ✅ 恢复正常
+* 9月7日：¥0.96 ✅ 持续正常
+* 9月8日：¥0.53 ✅ 更加优化
+
+**集群使用模式恢复**
+
+* 平均每次使用时长：0.02小时（恢复正常短查询模式）
+* 单次费用：¥0.02-0.7（回到合理范围）
+* 集群自动挂起：正常工作
+
+### 经验总结
+
+**技术层面经验**
+
+1. **动态表设计**: 刷新间隔应与业务需求和成本考虑平衡
+2. **资源监控**: 建立多层次的费用和资源使用监控
+3. **配置管理**: 重要配置变更应经过评估和测试
+
+**运维层面经验**
+
+1. **及时发现**：建立自动化的异常检测机制
+2. **快速定位**：掌握系统化的问题排查方法
+3. **预防为主**：通过最佳实践避免类似问题
+
+**业务层面经验**
+
+1. **成本意识**: 技术决策应考虑成本影响
+2. **需求评估**: 功能需求与资源消耗的平衡
+3. **持续优化**: 定期审查和优化资源使用
+
+## 总结
+
+这个真实案例完美展示了云器 Lakehouse MCP Server在企业级数据平台运维中的核心价值：
+
+### 🚀 技术创新
+
+* **AI驱动的自然语言分析**：让复杂的数据分析变得简单直观
+* **智能化问题诊断**：自动识别异常模式和根本原因
+* **多维度关联分析**：从海量数据中快速提取关键信息
+
+### 💰 商业价值
+
+* **立竿见影的成本节省**：单个案例节省¥80+/天
+* **运维效率显著提升**：问题排查时间从小时级降至分钟级
+* **风险预防能力**：避免配置错误导致的长期损失
+
+### 🛠️ 实用性
+
+* **零门槛使用**：无需SQL知识，自然语言即可完成复杂分析
+* **即时可执行方案**：不仅诊断问题，更提供具体解决方案
+* **知识传承**：分析过程和方法可复用于类似场景
+
+通过这个案例，我们看到了AI技术在数据平台运维中的巨大潜力。云器 Lakehouse MCP Server不仅是一个工具，更是一个智能的运维伙伴，帮助用户在复杂的数据环境中快速定位问题、优化成本、提升效率。
+
+***
+
+*本案例基于真实用户使用场景，数据已做脱敏处理，展示了云器 Lakehouse MCP Server在费用管理、问题排查和运维优化方面的实际应用价值。*
+
+^
+
+## 参考
+
+[实例级Information schema](instance-information_schema.md)
+
+[动态表](dynamic-table.md)

package/bin/skills/lakehouse-doc/references/clone-doc.md

@@ -0,0 +1,111 @@
+# CREATE ....CLONE
+
+> 【预览发布】本功能当前处于公开预览发布阶段。
+
+在 Lakehouse 中，克隆表操作创建了一个表的独立副本，该副本与原始表完全分离，互不影响。克隆表在创建时不占用额外的存储空间，因为它共享原始表的数据版本。但是，如果原始表数据发生变化并影响到克隆表中的数据，克隆表将需要为这些变化支付存储费用。克隆表具有与普通表相似的功能，包括查询、复制和删除等操作。Lakehouse 支持克隆普通表和动态表，并且允许创建克隆的克隆，即克隆一个已经是克隆的表。
+
+## 克隆表注意事项
+
+* 克隆操作不会复制原始表的权限，新克隆的表将具有独立的权限设置。
+* 克隆操作不会复制用户设置的属性，包括生命周期和数据时间旅行保留周期。
+* 实时写入且未提交的数据不会被克隆。因此，在克隆完成后，刚刚写入的数据将无法在克隆表中找到。
+* 不支持克隆外部表。
+
+## 普通表克隆
+
+```SQL
+CREATE TABLE [ IF NOT EXISTS ] table_name CLONE <source_object_name> [TIMESTAMP AS OF timestamp_expression]
+```
+
+* 可以使用 `TIMESTAMP AS OF timestamp_expression` 来克隆动态表在指定时间点的版本。只要该时间点在\*\*[数据保留周期](TIMETRAVEL.md)\*\*内（`data_retention_days`）。
+  * `timestamp_expression` 可以是以下任意一项：
+    * `'2024-10-18T22:15:12.013Z'`，即可以强制转换为时间戳的字符串
+    * `cast('2024-10-18 13:36:32 ' as timestamp)`
+    * `'2024-10-18'`，即日期字符串
+    * `current_timestamp() - interval 12 hours`
+    * `date_sub(current_date(), 1)`
+    * 本身就是时间戳或可强制转换为时间戳的任何其他表达式
+
+```
+CREATE TABLE normal_table_clone_version CLONE normal_table_base TIMESTAMP AS OF '2024-10-12 19:23:52.329';
+```
+
+## 动态表克隆
+
+```SQL
+CREATE DYNAMIC TABLE dt_name
+ [
+    refreshOption ::=
+    REFRESH [START WITH timestamp_expr] [interval_time] VCLUSTER vcname   
+ ]
+  CLONE <source_dynamic_table> [TIMESTAMP AS OF timestamp_expression]
+```
+
+* 克隆出的动态表默认暂停刷新，可以使用 `ALTER DYNAMIC TABLE table_name RESUME;` 来启动刷新任务。
+* `DYNAMIC TABLE dt_name`: 要创建的动态表的名称，`dt_name` 是一个占位符，您需要替换为实际的表名。
+* `REFRESH`：指定表的刷新选项。克隆动态表时可以指定刷新选项：
+  * 如果指定了刷新选项，则使用克隆表的刷新策略。
+  * 如果未指定刷新选项，则使用默认的刷新策略。
+* `START WITH timestamp_expr`: 可选子句，指定表开始刷新的时间点，`timestamp_expr` 是一个时间戳表达式。
+* `interval_time`: 指定刷新间隔的时间单位，这是一个 `INTERVAL` 类型，可以是以下任意一项：
+  * INTERVAL 1 year
+  * INTERVAL 2 month
+  * INTERVAL 3 day
+  * INTERVAL 4 hour
+  * INTERVAL 5 minute
+  * INTERVAL 30 second
+* `VCLUSTER vcname`: 指定计算集群的名称，`vcname` 是计算集群的实际名称。
+* `CLONE <source_dynamic_table>`: 从现有的动态表 `<source_dynamic_table>` 克隆。
+* `TIMESTAMP AS OF timestamp_expression`: 克隆动态表在指定时间点的版本，`timestamp_expression` 可以是多种时间戳表达式之一。只要该时间点在[数据保留周期](TIMETRAVEL.md)内（`data_retention_days`）。
+  * `timestamp_expression` 可以是以下任意一项：
+    * `'2024-10-18T22:15:12.013Z'`，即可以强制转换为时间戳的字符串
+    * `cast('2024-10-18 13:36:32 ' as timestamp)`
+    * `'2024-10-18'`，即日期字符串
+    * `current_timestamp() - interval 12 hours`
+    * `date_sub(current_date(), 1)`
+    * 本身就是时间戳或可强制转换为时间戳的任何其他表达式
+
+## 权限要求
+
+* 需要有当前 schema 下的 `CREATE TABLE` 权限来创建克隆表。
+* 需要有对原始表的 `SELECT` 权限。
+
+## 克隆表案例
+
+### 克隆普通表
+
+```SQL
+-- 创建普通表
+CREATE TABLE normal_table_base (id BIGINT, col STRING);
+
+-- 克隆普通表
+CREATE TABLE normal_table_clone CLONE normal_table_base;
+
+-- 指定基表的版本克隆
+CREATE TABLE normal_table_clone_version CLONE normal_table_base TIMESTAMP AS OF '2024-10-12 19:23:52.329';
+```
+
+### 克隆动态表
+
+```SQL
+-- 创建动态表
+CREATE DYNAMIC TABLE dt_table_base
+REFRESH INTERVAL 1 MINUTE
+VCLUSTER DEFAULT
+AS SELECT * FROM normal_table_base;
+
+-- 克隆动态表
+CREATE DYNAMIC TABLE dt_table_clone CLONE dt_table_base;
+
+-- 克隆时指定刷新间隔和计算集群
+CREATE DYNAMIC TABLE dt_table_clone_refresh
+REFRESH INTERVAL 2 MINUTE
+VCLUSTER DEFAULT
+CLONE dt_table_base;
+
+-- 克隆时指定动态表的版本
+CREATE DYNAMIC TABLE dt_table_clone_version
+CLONE dt_table_base TIMESTAMP AS OF '2024-10-12 20:25:32.247';
+```
+
+^

package/bin/skills/lakehouse-doc/references/cloud_object_storage.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/cluster-table-guide.md

@@ -0,0 +1,68 @@
+# 分桶键（Clustered Key）和排序键（Sorted Key）
+
+在大数据存储与分析领域，数据的组织方式对查询性能和存储效率具有重要影响。本文将详细介绍分桶键（Clustered Key）和排序键（Sorted Key）的概念、使用方法以及实际应用示例，帮助您更好地优化数据组织结构。
+
+## 分桶键（Clustered Key）
+
+分桶键是表数据分布的核心。通过指定分桶键，Lakehouse会根据这些键对数据进行Hash运算，并将数据分散到不同的数据分桶（buckets）中。这种分散有助于避免数据倾斜和热点问题，同时提高并行处理能力。
+
+### 选择分桶键的准则
+
+- 选择取值范围广、重复值少的列作为分桶键，以实现数据的均匀分布。
+- 在进行`JOIN`操作时，如果连接的键与分桶键一致，可以显著提高性能。
+- 适用于数据量大的场景，推荐的数据分桶大小约为128MB到1GB，具体取决于数据的压缩率和访问模式。
+- 如果没有指定分桶键，则默认使用256个分桶。
+
+### 注意事项
+
+- 避免指定过小的分桶数量，以免产生大量小文件，影响元数据管理和I/O操作效率。
+- 过多的小文件会导致数据局部性差，增加任务调度开销，降低处理效率。
+
+## 排序键（Sorted Key）
+
+排序键用于指定数据文件内字段的排序方式。对于需要按特定字段排序或进行范围查询的场景，预先将数据按排序键组织可以大幅提高查询性能。
+
+### 使用排序键的注意事项
+
+- 可以为排序键指定升序（ASC）或降序（DESC）。
+- 虽然排序键可以提高查询性能，但在对大量数据进行插入时，维护排序顺序可能会消耗较多计算和I/O资源。
+
+## 实际应用示例
+
+### 示例1：创建表并指定分桶键与排序键
+
+```sql
+CREATE TABLE sales_data (
+    sale_id INT,
+    product_id INT,
+    quantity_sold INT,
+    sale_date DATE,
+    ...
+) CLUSTERED BY (product_id)
+SORTED BY (sale_date DESC)
+INTO 50 BUCKETS;
+```
+
+在这个示例中，创建了一个名为`sales_data`的表，数据将根据`product_id`列的哈希值被分散到50个分桶中。同时，分桶内的数据将按照`sale_date`列的降序进行排序。
+
+### 示例2：优化数据仓库的查询性能
+
+假设您正在处理一个包含大量交易记录的数据仓库，可以通过以下方式优化查询性能：
+
+```sql
+CREATE TABLE transaction_records (
+    transaction_id INT,
+    customer_id INT,
+    transaction_date DATE,
+    amount DECIMAL(10,2),
+    ...
+) CLUSTERED BY (customer_id)
+SORTED BY (transaction_date ASC)
+INTO 128 BUCKETS;
+```
+
+在这个示例中，`transaction_records`表根据`customer_id`进行分桶，分桶内的数据按照`transaction_date`进行排序。这样的设计有助于提高按客户查询交易记录的效率。
+
+## 结语
+
+合理使用分桶键和排序键，可以有效优化数据的物理存储结构，提高查询性能，尤其是在处理大规模数据集时。这种方法特别适用于数据仓库和大数据分析场景，可以显著提升数据处理的效率。希望本文能帮助您更好地理解和应用分桶键与排序键，从而优化您的数据组织方式。