这个问题是因为批量执行DDL（删除/创建表/物化视图）操作失败后，Cassandra的系统schema表损坏，导致某个表的元数据丢失了分区键定义。下面是针对单节点环境的修复步骤：

修复步骤 #

• 第一步：停止Cassandra服务
  如果Cassandra还在尝试启动或处于异常状态，先彻底停止它：

  sudo service cassandra stop
  # 若服务命令无效，可使用kill命令
  sudo pkill -f cassandra
  

• 第二步：备份系统表数据
  先备份system_schema.tables对应的data目录，防止操作失误导致更严重的问题。默认路径一般是：

  sudo cp -r /var/lib/cassandra/data/system/schema_tables /var/lib/cassandra/data/system/schema_tables_backup
  

  注意：请根据你的Cassandra实际安装路径调整上述命令中的路径。

• 第三步：启动Cassandra到单用户模式
  单用户模式允许本地超级用户连接并修复schema问题，启动命令如下：

  cassandra -Dcassandra.superuser_setup_delay_ms=0 -Dcassandra.initial_token= -Dcassandra.skip_wait_for_gossip_to_settle=0 -Dcassandra.enable_single_user_mode=true
  

• 第四步：连接到Cassandra并修复损坏的表
  用本地cqlsh连接（使用超级用户账号，默认账号密码为cassandra/cassandra，若你修改过请用自定义账号）：

  cqlsh -u cassandra -p cassandra
  

  然后执行以下操作：

  1. 确认损坏表的状态：

     SELECT table_name, partition_keys FROM system_schema.tables WHERE keyspace_name = 'keyspace' AND table_name = 'table';
     

     把keyspace和table替换成报错中提到的具体名称，你会看到partition_keys字段为空或者异常。
  2. 删除这个损坏的表（因为它的schema已经无法正常加载，数据也大概率不可用）：

     DROP TABLE keyspace.table;
     

     如果是物化视图损坏，就用DROP MATERIALIZED VIEW keyspace.view_name;

• 第五步：重启Cassandra到正常模式
  退出cqlsh，停止Cassandra服务，然后正常启动：

  sudo service cassandra stop
  sudo service cassandra start
  

预防建议 #

• 避免一次性批量执行大量DDL操作（尤其是删除和创建混合的操作），Cassandra的DDL虽然是原子操作，但批量执行容易引发schema同步问题，建议分批次执行，每执行完一批等待几秒再执行下一批。
• 定期备份Cassandra的schema和数据，避免出现类似问题时无法恢复。
• 考虑升级到更高版本的Cassandra（3.9.0是比较老旧的版本），后续版本修复了很多schema相关的bug，稳定性更好。

内容的提问来源于stack exchange，提问作者usman