• 首页
  • css3教程
  • html5教程
  • jQuery手册
  • vue手册
  • php手册
  • MySQL手册
  • apache手册
  • redis手册
  • p_thread_group_stats表

    注意

    从MySQL 8.0.14开始,此处描述的性能架构表可用。在MySQL 8.0.14之前,请改用相应的INFORMATION_SCHEMA表。请参见“ INFORMATION_SCHEMA TP_THREAD_GROUP_STATS表”。

    tp_thread_group_stats表报告每个线程组的统计信息。每组一行。

    tp_thread_group_stats表包含以下列:

    • TP_GROUP_ID

      线程组ID。这是表中的唯一键。

    • CONNECTIONS_STARTED

      启动的连接数。

    • CONNECTIONS_CLOSED

      关闭的连接数。

    • QUERIES_EXECUTED

      执行的语句数。语句开始执行时(而不是执行结束时),此数字增加。

    • QUERIES_QUEUED

      已排队等待执行的语句数。这不计算线程组能够立即开始执行而无需排队的语句,这可能在“线程池操作”中所述的条件下发生。

    • THREADS_STARTED

      启动的线程数。

    • PRIO_KICKUPS

      已根据thread_pool_prio_kickup_timer系统变量的值从低优先级队列移至高优先级队列的语句数。如果该数字迅速增加,请考虑增加该变量的值。快速增加的计数器意味着优先级系统不会阻止事务开始得太早。对于InnoDB,这很可能意味着由于过多的并发事务而导致性能下降。

    • STALLED_QUERIES_EXECUTED

      由于执行时间超过thread_pool_stall_limit系统变量的值,已被定义为停顿的语句数。

    • BECOME_CONSUMER_THREAD

      线程被分配给使用者线程角色的次数。

    • BECOME_RESERVE_THREAD

      线程被分配备用线程角色的次数。

    • BECOME_WAITING_THREAD

      为线程分配了等待线程角色的次数。当语句排队时,即使在正常操作中,这种情况也经常发生,因此在语句排队的高负载系统中,此值的快速增加是正常的。

    • WAKE_THREAD_STALL_CHECKER

      停顿检查线程决定唤醒或创建一个线程以处理某些语句或担当服务线程角色的次数。

    • SLEEP_WAITS

      THD_WAIT_SLEEP等待。这些发生在线程进入睡眠状态时(例如,通过调用SLEEP()函数)。

    • DISK_IO_WAITS

      THD_WAIT_DISKIO等待。当线程执行磁盘I / O可能不会命中文件系统缓存时,就会发生这些情况。当缓冲池向磁盘读取和写入数据时发生这种等待,而不是对文件的正常读取和写入发生这种等待。

    • ROW_LOCK_WAITS

      THD_WAIT_ROW_LOCK等待另一个事务释放行锁的等待次数。

    • GLOBAL_LOCK_WAITS

      THD_WAIT_GLOBAL_LOCK等待释放全局锁的等待次数。

    • META_DATA_LOCK_WAITS

      THD_WAIT_META_DATA_LOCK等待元数据锁释放的等待次数。

    • TABLE_LOCK_WAITS

      THD_WAIT_TABLE_LOCK语句需要访问的等待表解锁的等待次数。

    • USER_LOCK_WAITS

      THD_WAIT_USER_LOCK等待用户线程构造的特殊锁的次数。

    • BINLOG_WAITS

      THD_WAIT_BINLOG_WAITS等待二进制日志成为自由。

    • GROUP_COMMIT_WAITS

      THD_WAIT_GROUP_COMMIT等待。当组提交必须等待其他方完成其事务部分时,就会发生这种情况。

    • FSYNC_WAITS

      THD_WAIT_SYNC等待文件同步操作。

    tp_thread_group_stats表具有以下索引:

    • TP_GROUP_ID)上的唯一索引

    TRUNCATE TABLE不允许用于该tp_thread_group_stats表。