发生故障时，应先确定问题范围和阶段，再收集AMS、Optimizer、计算引擎、元数据服务和存储侧证据。避免在状态不明时删除临时文件或反复重启服务。

AMS启动失败

1、查看 AMS 日志中的首个异常，区分端口占用、配置格式、数据库、插件、依赖、jvm内存配置值超出机器可用量等问题。

2、检查 config.yaml 缩进、数据库驱动 JAR、JDBC 地址和账号权限。

3、检查 1260、1261 和 1630 端口是否被占用。

4、启用高可用时检查 ZooKeeper 地址、ACL、cluster-name 和网络。

5、修复后重启，并分别验证 WebUI、Table Service 和 Optimizing Service。

Catalog未加载出预期库/表

1、在 AMS 节点验证 HMS、HDFS 或 S3 的 DNS、端口和 TLS。

2、核对 principal、keytab、krb5.conf 或 AK/SK 是否有效，检查用户是否有目录/表权限。

3、检查 warehouse、站点 XML 和自定义 catalog-impl JAR。

4、确认 database-filter 和 table-filter的正则表达式正确、没有误排除目标对象。

5、查看 AMS 日志中是否有异常报错，定位问题原因。

6、先执行只读操作，再逐步验证写入和自优化。

自优化积压或失败

1、确认表的 self-optimizing.enabled 为 true，且绑定正确的 Optimizer Group。

2、检查 Group 是否有 RUNNING Optimizer，以及 Pending、Executing 和 Committing 状态。

3、在 Optimizer 日志中定位权限、内存、网络、文件冲突或计算引擎异常。

4、检查 1261 连接、心跳超时和 AMS 主备切换。

5、必要时先扩容，并临时降低非关键表 quota，再处理根因。

查询变慢或文件数量异常

1、检查目标表的文件数量、平均文件大小和最近一次优化时间。

2、判断 Optimizer 是否存在长期积压或频繁失败。

3、检查自优化 target-size、fragment-ratio、quota 和调度策略。

4、检查底层存储吞吐、请求限流和计算引擎扫描计划。