mysql请求阻塞

背景

我们提供了容器化的mysql给业务组使用， 容器化的意义在于技术栈统一，提供了标准的账号权限体系、配置文件优化、定时备份、主从切换、指标监控、异常告警。

这次的问题就出在配置文件优化上，以下是我们提供在2核4G环境下的一个模板，参考了一些mysql调优的案例和文章

  [mysqld]
    character_set_server            = utf8mb4
    datadir                         = /var/lib/mysql
    expire_logs_days                = 1
    explicit_defaults_for_timestamp = 1
    general_log                     = ON
    general_log_file                = /var/log/mysql/general_log_file.log
    innodb_buffer_pool_size         = 2G
    innodb_flush_log_at_trx_commit  = 2
    innodb_flush_method             = O_DIRECT
    innodb_flush_neighbors          = 0
    innodb_io_capacity              = 1000
    innodb_io_capacity_max          = 2000
    innodb_large_prefix             = 1
    innodb_lock_wait_timeout        = 30
    innodb_print_all_deadlocks      = 1
    innodb_thread_concurrency       = 4
    join_buffer_size                = 20M
    log-error                       = /var/log/mysql/error.log
    log_queries_not_using_indexes   = 0
    log_slow_admin_statements       = 1
    log_slow_slave_statements       = 1
    log_timestamps                  = system
    long_query_time                 = 10
    max_connect_errors              = 10
    pid-file                        = /var/run/mysqld/mysqld.pid
    read_rnd_buffer_size            = 8388608
    slow_query_log                  = 1
    slow_query_log_file             = /var/log/mysql/slow_query_log_file.log
    socket                          = /var/run/mysqld/mysqld.sock
    sort_buffer_size                = 4194304
    tmp_table_size                  = 67108864
    wait_timeout                    = 600
    binlog-ignore-db                = mysql
    enforce-gtid-consistency        = ON
    gtid-mode                       = ON
    log-bin                         = mysql-bin
    log-slave-updates               = ON
    innodb_log_file_size            = 256M
    lower_case_table_names          = 1
    max_connections                 = 512
    server-id                       = 1

问题描述

原来的数据库在虚拟机上运行，8核16G，需要迁移到容器上来， 在迁移测试的过程中， 突然发现所有的表都打不开了，执行 show full processlist发现有四个视图语句在执行，询问得知数仓会在这个时间抽数，并发执行这几个视图语句，但是之前在虚拟机上跑是没问题的

排查

磁盘

刚开始以为是磁盘的问题，容器化的mysql，磁盘是挂载的pv、pvc，用的ceph的这一套分布式存储，通过ceph的性能测试和控制面板看起来是没有任何问题的，我们每天上亿的日志采集走的也是ceph，但是为了宁杀错不放过，将容器化的mysql磁盘挂载到了虚拟机上的固态硬盘， 还是没有解决这个问题

网络

磁盘没有问题，从网络入手，视图的查询，走的是k8s的nodeport，怀疑可能是网络传输过程中丢包导致的，于是将视图的查询搬到了容器内，走容器内部的service网络，结果还是没有解决

cpu、内存

磁盘和网络都没有问题，怀疑可能是docker的cpu和内存的资源加载的不及时？这是之前的配置

      resources:
        limits:
          cpu: '4'
          memory: 4000Mi
        requests:
          cpu: 100m
          memory: 1000Mi

于是将request和limit调整一致，均为4核4G，结果还是没有解决

mysql指标

连接数、锁表都很正常

mysql性能分析

好吧，从mysql自身入手， 通过开启show profiles，观察下一个简单的查询语句是阻塞到哪里了，结果是sending data

当执行一个查询时，MySQL会按照查询计划逐步执行不同的阶段。当MySQL完成了读取数据的阶段（例如扫描表、使用索引等），并且需要将结果发送给客户端时，就会出现"Sending data"阶段

好吧，到这无果了，对比一下和迁移前的差距，问题可能还是在配置文件上，于是去逐个阅读配置文件背后的原理，终于找到了一条可疑的配置

innodb_thread_concurrency=4

这个配置大概意思是限制了innodb并发的线程为4，当有四个线程正在并发执行查询或者事务的时候，其他的sql想要执行，就会放到一个等待队列，等待前面的线程释放资源后，才会获得一个执行线程去执行，等待队列按照FIFO的策略来执行， 这一点和java的线程池倒是设计的一样

之前为什么可以？

之前是使用的默认值，默认值为0

当innodb_thread_concurrency参数设置为0时，表示未启用并发度限制，InnoDB存储引擎会根据系统负载和资源情况自动评估并发度。

InnoDB会根据以下几个因素来评估并发度：

硬件资源：InnoDB会检测系统的硬件资源情况，包括CPU核心数、内存大小和磁盘I/O能力。根据可用的资源情况，它会决定是否创建新的执行线程。

系统负载：InnoDB会监视当前的系统负载，包括并发查询和事务数量。如果系统负载较低，InnoDB可能会创建更多的执行线程来并发执行查询和事务。反之，如果系统负载较高，InnoDB可能会推迟或拒绝创建新的执行线程，以避免资源争用和性能下降。

动态调整：InnoDB会根据实时的负载情况和资源利用率进行动态调整。它会监控执行线程的活动情况，并根据需要增加或减少执行线程的数量，以适应系统负载的变化。

通过这些评估和动态调整，InnoDB能够自动优化并发度，以最大程度地利用系统资源并提高性能。然而，由于每个系统的配置和负载模式都不同，最佳的并发度可能会因情况而异。因此，对于特定的系统，可能需要根据实际情况进行调整和优化。

为什么设置为4

对mysql了解不足， 这个值最早大家的建议都是设置为cpu的核数

应该怎么做？

依据percona.com的文档给出的合理值应该是活跃用户线程小于64的时候使用默认值， 大于64的时候设置为128，然后根据测试情况逐步下调或上涨