mysql:慢select无需地点和连接

发布于 2025-01-29 18:45:58 字数 4633 浏览 2 评论 0 原文

我有下表:

| ticket | CREATE TABLE `ticket` (
  `ticket_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `client_id` binary(16) NOT NULL,
  `owner_id` binary(16) DEFAULT NULL,
  `requester_id` binary(16) NOT NULL,
  `ticket_type` varchar(15) COLLATE utf8mb4_unicode_ci NOT NULL,
  `status` varchar(18) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `priority` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
  `subject` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `created` datetime(3) NOT NULL,
  `updated` datetime(3) NOT NULL,
  `eta` datetime(3) NOT NULL,
  `version` bigint(20) NOT NULL DEFAULT '0',
  `office_id` binary(16) DEFAULT NULL,
  `department_id` binary(16) DEFAULT NULL,
  `requester` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `requester_type` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'IPDEPLOY',
  `assignment_group_id` binary(16) DEFAULT NULL,
  PRIMARY KEY (`ticket_id`),
  KEY `idx_ticket_office_id` (`office_id`),
  KEY `idx_ticket_department_id` (`department_id`),
  KEY `idx_ticket_client_id` (`client_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3116172 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ENCRYPTION='Y';

mysql> select count(*) from ticket;
+----------+
| count(*) |
+----------+
|  1190895 |
+----------+
mysql> SHOW TABLE STATUS WHERE name LIKE 'ticket' \G
*************************** 1. row ***************************
           Name: ticket
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 1101291
 Avg_row_length: 375
    Data_length: 413089792
Max_data_length: 0
   Index_length: 153468928
      Data_free: 6291456
 Auto_increment: 3121563
    Create_time: 2022-05-18 09:51:06
    Update_time: 2022-05-19 12:06:18
     Check_time: NULL
      Collation: utf8mb4_unicode_ci
       Checksum: NULL
 Create_options: row_format=DYNAMIC ENCRYPTION="Y"
        Comment:
1 row in set (0.00 sec)

简单的查询间歇性地花费大量时间(此类查询的30%大约需要500毫秒以上(有些最多需要3秒)):

mysql> select * from ticket limit 20, 20;
...
20 rows in set (0.77 sec)

当分析时,所有时间都花在开始阶段:

mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=37 order by duration DESC limit 2 \G
*************************** 1. row ***************************
           QUERY_ID: 37
                SEQ: 2
              STATE: starting
           DURATION: 0.760068
           CPU_USER: NULL
         CPU_SYSTEM: NULL
  CONTEXT_VOLUNTARY: NULL
CONTEXT_INVOLUNTARY: NULL
       BLOCK_OPS_IN: NULL
      BLOCK_OPS_OUT: NULL
      MESSAGES_SENT: NULL
  MESSAGES_RECEIVED: NULL
  PAGE_FAULTS_MAJOR: NULL
  PAGE_FAULTS_MINOR: NULL
              SWAPS: NULL
    SOURCE_FUNCTION: NULL
        SOURCE_FILE: NULL
        SOURCE_LINE: NULL
*************************** 2. row ***************************
           QUERY_ID: 37
                SEQ: 11
              STATE: Sending data
           DURATION: 0.000234
           CPU_USER: NULL
         CPU_SYSTEM: NULL
  CONTEXT_VOLUNTARY: NULL
CONTEXT_INVOLUNTARY: NULL
       BLOCK_OPS_IN: NULL
      BLOCK_OPS_OUT: NULL
      MESSAGES_SENT: NULL
  MESSAGES_RECEIVED: NULL
  PAGE_FAULTS_MAJOR: NULL
  PAGE_FAULTS_MINOR: NULL
              SWAPS: NULL
    SOURCE_FUNCTION: exec
        SOURCE_FILE: sql_executor.cc
        SOURCE_LINE: 195

MySQL手册关于起始状态并不多:“声明执行开始时的第一阶段。”。我该如何找出MySQL在这种状态下实际在做什么?这种行为的原因可能是什么?

MySQL 5.7.27-30-57-log在Centos Linux上运行7.7.1908在Azure的容器中。 DB根本没有加载。

Innodb_buffer_pool_size设置为12G

爱意和普罗米修斯指标:

​/I.SSTATIC.NET/paspy.png“ alt =”在此处输入图像描述”>

“

​href =“ https://i.sstatic.net/ymqj9.png” rel =“ nofollow noreferrer”>

”在此处输入图像描述”

I have the following table:

| ticket | CREATE TABLE `ticket` (
  `ticket_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `client_id` binary(16) NOT NULL,
  `owner_id` binary(16) DEFAULT NULL,
  `requester_id` binary(16) NOT NULL,
  `ticket_type` varchar(15) COLLATE utf8mb4_unicode_ci NOT NULL,
  `status` varchar(18) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `priority` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
  `subject` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `created` datetime(3) NOT NULL,
  `updated` datetime(3) NOT NULL,
  `eta` datetime(3) NOT NULL,
  `version` bigint(20) NOT NULL DEFAULT '0',
  `office_id` binary(16) DEFAULT NULL,
  `department_id` binary(16) DEFAULT NULL,
  `requester` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `requester_type` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'IPDEPLOY',
  `assignment_group_id` binary(16) DEFAULT NULL,
  PRIMARY KEY (`ticket_id`),
  KEY `idx_ticket_office_id` (`office_id`),
  KEY `idx_ticket_department_id` (`department_id`),
  KEY `idx_ticket_client_id` (`client_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3116172 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC ENCRYPTION='Y';

mysql> select count(*) from ticket;
+----------+
| count(*) |
+----------+
|  1190895 |
+----------+
mysql> SHOW TABLE STATUS WHERE name LIKE 'ticket' \G
*************************** 1. row ***************************
           Name: ticket
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 1101291
 Avg_row_length: 375
    Data_length: 413089792
Max_data_length: 0
   Index_length: 153468928
      Data_free: 6291456
 Auto_increment: 3121563
    Create_time: 2022-05-18 09:51:06
    Update_time: 2022-05-19 12:06:18
     Check_time: NULL
      Collation: utf8mb4_unicode_ci
       Checksum: NULL
 Create_options: row_format=DYNAMIC ENCRYPTION="Y"
        Comment:
1 row in set (0.00 sec)

Simple queries intermittently take considerable amount of time (around 30% of such queries take more than 500 ms (some take up to 3 sec)):

mysql> select * from ticket limit 20, 20;
...
20 rows in set (0.77 sec)

when profiling, all the time is spent in starting phase:

mysql> SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID=37 order by duration DESC limit 2 \G
*************************** 1. row ***************************
           QUERY_ID: 37
                SEQ: 2
              STATE: starting
           DURATION: 0.760068
           CPU_USER: NULL
         CPU_SYSTEM: NULL
  CONTEXT_VOLUNTARY: NULL
CONTEXT_INVOLUNTARY: NULL
       BLOCK_OPS_IN: NULL
      BLOCK_OPS_OUT: NULL
      MESSAGES_SENT: NULL
  MESSAGES_RECEIVED: NULL
  PAGE_FAULTS_MAJOR: NULL
  PAGE_FAULTS_MINOR: NULL
              SWAPS: NULL
    SOURCE_FUNCTION: NULL
        SOURCE_FILE: NULL
        SOURCE_LINE: NULL
*************************** 2. row ***************************
           QUERY_ID: 37
                SEQ: 11
              STATE: Sending data
           DURATION: 0.000234
           CPU_USER: NULL
         CPU_SYSTEM: NULL
  CONTEXT_VOLUNTARY: NULL
CONTEXT_INVOLUNTARY: NULL
       BLOCK_OPS_IN: NULL
      BLOCK_OPS_OUT: NULL
      MESSAGES_SENT: NULL
  MESSAGES_RECEIVED: NULL
  PAGE_FAULTS_MAJOR: NULL
  PAGE_FAULTS_MINOR: NULL
              SWAPS: NULL
    SOURCE_FUNCTION: exec
        SOURCE_FILE: sql_executor.cc
        SOURCE_LINE: 195

MySQL manual doesn't say much about starting state: "The first stage at the beginning of statement execution.". How can I find out what MySQL is actually doing in this state? What might be the cause of such behaviour?

MySQL 5.7.27-30-57-log running on CentOS Linux release 7.7.1908 inside a container in Azure. DB is not loaded at all.

innodb_buffer_pool_size is set to 12G

IOwait and prometheus metrics:
enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

enter image description here

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

踏雪无痕 2025-02-05 18:45:58

最后,我们通过将WSREP_SYNC_WAIT设置为0来解决此问题。

Finally we fixed this by setting wsrep_sync_wait to 0.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文