select COLUMN_NAME from information_schema.COLUMNS where table_name = xxx耗时长

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】select COLUMN_NAME from information_schema.COLUMNS where table_name = xxx耗时长

【背景】创建1个单表,然后通过视图查询某些字段,查询视图的元数据时,有时候耗时长,达到3924毫秒。
【业务影响】 查询元数据表耗时长
【StarRocks版本】2.5.4
【集群规模】3fe+3be
【机器信息】公有云 ,fe:8C16G3,be:8C32G3
【联系方式】StarRocks社区群8
【附件】

  • Profile信息,
    Query:
    Summary:
    • Query ID: 42b4bbad-246d-11ee-be7c-0242a2c4de0d
    • Start Time: 2023-07-17 14:43:38
    • End Time: 2023-07-17 14:43:38
    • Total: 13ms
    • Query Type: Query
    • Query State: EOF
    • StarRocks Version: 2.5.4-1021a92
    • User: app_user
    • Default Db: data_service
    • Sql Statement: /* tid = 1689573300104 */ select COLUMN_NAME from information_schema.COLUMNS where table_name = ‘data_view_v2’
    • QueryCpuCost: 0
    • QueryMemCost: 0.000
    • Variables: parallel_fragment_exec_instance_num=1,max_parallel_scan_instance_num=-1,pipeline_dop=0,enable_adaptive_sink_dop=false
    • Collect Profile Time: 0
      Planner:
    • Analyzer: 0ms / 1
    • CoordDeliverExec: 1ms / 1
    • CoordPrepareExec: 0ms / 1
    • ExecPlanBuild: 0ms / 1
    • Optimizer: 0ms / 1
    • Total: 0ms / 1
      Optimizer:
      • CostBaseOptimize: 0ms / 1
      • PhysicalRewrite: 0ms / 1
      • RuleBaseOptimize: 0ms / 1
      • preprocessMvs: 0ms / 1
        Execution Profile 42b4bbad-246d-11ee-be7c-0242a2c4de0d:(Active: 12.341ms[12341839ns], % non-child: 100.00%)
        Fragment 0:
        Instance 42b4bbad-246d-11ee-be7c-0242a2c4de0e (host=TNetworkAddress(hostname:10.9.2.61, port:9060)):(Active: 9.562ms[9562051ns], % non-child: 0.00%)
        • Address: 10.9.2.61:9060
        • MemoryLimit: 2.00 GB
        • PeakMemoryUsage: 13.27 KB
        • RowsProduced: 78
          DataBufferSender (dst_fragment_instance_id=42b4bbad-246d-11ee-be7c-0242a2c4de0e):
          • AppendChunkTime: 13.717us
            • ResultRendTime: 40.381us
            • TupleConvertTime: 12.186us
          • NumSentRows: 78
            PROJECT_NODE (id=1):(Active: 9.589ms[9589255ns], % non-child: 0.84%)
          • CommonSubExprComputeTime: 426ns
          • ExprComputeTime: 858ns
          • PeakMemoryUsage: 0.00
          • RowsReturned: 78
          • RowsReturnedRate: 8.134K /sec
            SCHEMA_SCAN_NODE (id=0):(Active: 9.486ms[9486057ns], % non-child: 76.86%)
            • BytesRead: 0.00
            • FERPC: 9.379ms
            • FillChunk: 20.547us
            • FilterTime: 11.911us
            • NumDiskAccess: 0
            • PeakMemoryUsage: 0.00
            • RowsRead: 0
            • RowsReturned: 78
            • RowsReturnedRate: 8.222K /sec
            • ScannerThreadsInvoluntaryContextSwitches: 0
            • ScannerThreadsTotalWallClockTime: 0ns
              • MaterializeTupleTime(*): 0ns
              • ScannerThreadsSysTime: 0ns
              • ScannerThreadsUserTime: 0ns
            • ScannerThreadsVoluntaryContextSwitches: 0
            • TotalRawReadTime(*): 0ns
            • TotalReadThroughput: 0.0 /sec

看您的发的profile耗时是ms级别的,集群中其他查询也会慢么?

其他SQL查询不慢

可以稳定复现么?请提供一个慢查询耗时3000ms时的profile

不好复现,平时用也是偶现,压测的时候或者高并发的时候就很明显

并发高时其他查询不受影响么?这种慢查询需要profile能好定位一下。并发上来时集群资源是不是打满了

请问解决了吗 我也遇到了同样 的问题