Cassandra debug日志出现带LIMIT 5000的非应用SELECT *慢超时查询来源咨询

这类带固定LIMIT 5000子句、针对业务表的SELECT *异常查询，并非Cassandra内部触发。
Cassandra的所有后台内部任务（含compaction、hint回放、repair、读修复、一致性校验、节点间数据传输），均通过节点间私有内部协议交互完成，不会以标准CQL用户查询的形式记录到慢查询/操作超时日志中，更不会针对具体业务主键值（如日志中出现的abcd、efgh这类业务ID）逐点发起查询，完全可以排除Cassandra内核自发触发的可能。

• 公共依赖层的内置探测逻辑
  gocql核心协议层本身不会自动拼接这类固定参数的全字段查询，但大量基于gocql二次封装的通用组件（连接池探活、可用性熔断、ORM启动预热、观测埋点），为快速验证表连通性，通常会拼接无明确字段指定、带固定LIMIT值的查询语句。这类逻辑属于公共基础设施层，不会写在业务代码的具体业务逻辑中，很容易被遗漏排查。
• 集群其他共用访问方
  排查范围不要局限于自身应用代码，需要覆盖同集群下的所有访问主体：同环境的其他服务、临时接入的运维排查脚本、数据对账/迁移组件、第三方监控采集工具。很多这类工具的默认逐主键扫描逻辑，会自动生成格式为SELECT * FROM <表名> WHERE <主键>=? LIMIT 5000的扫描语句，和日志中的查询特征完全匹配。

• 开启Cassandra审计日志，筛选所有携带LIMIT 5000的查询记录，直接定位请求来源IP、认证账号
• 在gocql连接层添加全局请求拦截钩子，打印所有通过当前驱动实例发出的CQL语句，核对是否存在异常SQL拼接逻辑
• 临时收紧业务表权限，仅给业务应用开放指定字段的SELECT权限，不开放全字段查询权限。这类SELECT *语句会直接触发权限拒绝，对应的请求来源会直接记录在权限拒绝日志中。

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