谁能帮忙解释一些 tidb 的内部 sql 语句?

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:2.1.14
  • 【问题描述】:

系统内不定时的会出现一些慢查

然后出现慢查时,慢查日志里,总是有一堆 TiDB 内部的 sql,能帮忙解释一下它们的原因吗?

比如:

select table_id, hist_id, is_index, feedback from mysql.stats_feedback order by table_id, hist_id, is_index;

Total keys 有 4,957,461

还有

select HIGH_PRIORITY * from mysql.global_variables where variable_name in (‘autocommit’, ‘sql_mode’, ‘max_allowed_packet’, ‘time_zone’, ‘block_encryption_mode’, ‘max_execution_time’, ‘tidb_skip_utf8_check’, ‘tidb_index_join_batch_size’, ‘tidb_index_lookup_size’, ‘tidb_index_lookup_concurrency’, ‘tidb_index_lookup_join_concurrency’, ‘tidb_index_serial_scan_concurrency’, ‘tidb_hash_join_concurrency’, ‘tidb_projection_concurrency’, ‘tidb_hashagg_partial_concurrency’, ‘tidb_hashagg_final_concurrency’, ‘tidb_backoff_lock_fast’, ‘tidb_constraint_check_in_place’, ‘tidb_opt_insubquery_unfold’, ‘tidb_distsql_scan_concurrency’, ‘tidb_max_chunk_size’, ‘tidb_retry_limit’, ‘tidb_disable_txn_auto_retry’);

建议根据慢查询看下是否是 热点读导致变慢的。可参考 TiDB慢日志解析源码解读 TiDB 常见问题处理 - 热点

“select table_id, hist_id, is_index, feedback from mysql.stats_feedback order by table_id, hist_id, is_index;” 这个是统计信息模块需要读取一些数据。

“select HIGH_PRIORITY * from mysql.global_variables where variable_name in (‘autocommit’, ‘sql_mode’, ‘max_allowed_packet’, ‘time_zone’, ‘block_encryption_mode’, ‘max_execution_time’, ‘tidb_skip_utf8_check’, ‘tidb_index_join_batch_size’, ‘tidb_index_lookup_size’, ‘tidb_index_lookup_concurrency’, ‘tidb_index_lookup_join_concurrency’, ‘tidb_index_serial_scan_concurrency’, ‘tidb_hash_join_concurrency’, ‘tidb_projection_concurrency’, ‘tidb_hashagg_partial_concurrency’, ‘tidb_hashagg_final_concurrency’, ‘tidb_backoff_lock_fast’, ‘tidb_constraint_check_in_place’, ‘tidb_opt_insubquery_unfold’, ‘tidb_distsql_scan_concurrency’, ‘tidb_max_chunk_size’, ‘tidb_retry_limit’, ‘tidb_disable_txn_auto_retry’);” 这是连接建立的时候需要读取全局变量的值,它是一个内部语句的方式读取的。

至于为什么慢日志里面会出现内部 SQL,这里尝试从两个维度回答:

  1. 内部 SQL 有一些会读取的数据量比较多,所以有可能会超过慢日志的阈值(默认 300ms)
  2. 内部 SQL 出现在慢日志中也不一定因为该 SQL 是慢的,有可能当时的集群状态是比较忙的,这个还需要查看系统监控中的其他指标。你能看看集群的资源使用情况吗

感谢回复,我再看看集群的监控。

:+1::handshake: