ITPub博客

例子1：trx1trx2begin;select * from testalter table test add col1 int;(堵塞)delete from test limit 1;(死锁)例子2：trx1trx2begin;delete from test limit 1;或者for update语句alter table test add col1 int;(堵塞)delete fro

因为这里描述全部是Innodb的行锁，为了方便描述，这里将语句需要的锁资源描述为请求行锁，而已经获取或者等待的行锁描述为当前行锁。其次锁结构对于行锁来讲和page绑定，一个锁结构可以用多个bit位表示一个page的多行记录锁，每个bit代表一行记录。但是这需要满足一定的条件，下面描述。这里讨论也是慢速加锁(lock_rec_lock_slow)的情况，不考虑快速加锁。一、 问题所在和BUG修复这个

一、问题描述最近遇到问题，版本5.7线上访问is.columns出现大量的警告，我们进行了模拟，当然模拟只模拟了一个警告，如下，image.png二、问题分析从报错来看其中有字节 \xBA\xC3 也就是0XBAC3无法被解析(这个码点实际上是GBK的'好'字)，而对于 information_schema.columns的字段COLUMN_COMMENT字符集为UTF8类型，因此

一、问题这个问题大概是这样。当前主从状态如下有2个半同步从库，如果停掉1个半同步从库是是否会堵塞主库，堵塞时间大概是多久？mysql> show global status like '%semi%';+--------------------------------------------+-----------+|&nbs

首先，这里不考虑innodb行锁，仅仅考虑MDL LOCK和DML/select 语句。我们知道到了8.0.28(包含)以后，记录慢查询的标准有变化，主要依赖的实际执行时间，而不是以前去掉了锁的时间(包含MDL LOCK和行锁)作为判定标准，具体参考，https://www.jianshu.com/p/27547eb97d6a以前通常通过lock_time来判断是否可能出现过innodb行锁堵塞和

一、故障介绍最近遇到一个案例，以前从来没遇到过，环境为5.7，从库在执行optimize table语句的时候，出现了MTS hang死的情况，并且无法自动解锁，只能是重启整个数据库(kill -9)，然后才可能恢复。模拟的截图如下，19df8442819b2c360f120ad73d7e17a.png当然线上MTS线程堵塞的比较多，但是模拟我只需要2个worker线程堵塞就可以了。这种堵塞状态视

数位数据库专家/ACEDirector/ACE赞誉推荐，凝结数百次故障诊断经验，从主库端到从库端带你深入解析MySQL主从构架的运行原理

公众号 MySQL学习 这个问题很简单，稍微看看mysql客户端的代码上下文即可 一、问题相关有返回了笛卡尔积数据，导致mysql客户端吃光了内存 这种这个mysql客户端线程将会oom导致kill。 二、问题分析对于select语句来讲，对于mysql客户端而言是交互式模式而不是batch模式。 #9 0x000000000041b2ed in cli_read_rows (mysql=0xaf476

官方版本测试到8.0.21依旧存在这个问题，Percona已经修复了，修复如下https://www.percona.com/blog/2018/03/27/analyze-table-is-no-longer-a-blocking-operation/ 能力有限简单记录。一、问题描述问题如下： mysql> show processlist; +----+------------

简单记录static bool login_connection(THD *thd) { int error; DBUG_TRACE; DBUG_PRINT("info", ("login_connection called by thread %u", thd->thread_id())); /

码版本：5.7.29 简单记录信号如何生效的。poll收到信号后如何中断后如何处理的，需要确认。一初始化信号处理方式，设置信号的处理的处理方式，屏蔽某些信号，并且继承到子线程(pthread_sigmask)，主要屏蔽的为SIGTERM、SIGQUIT、SIGHUP、SIGTSTP四个。其他信号按照默认处理方式，但是处理前打印crash栈，handle_fatal_signal 对于sigus

公众号 MySQL学习 随便记录点 5.7.22代码 MySQL工具主要分为 交互式和非交互式 交互式就是我们平时用的交互式命令方式非交互式（batch mode）主要用于解析binlog和批量导入sql，每次都会读取1行数据到buffer如果是binlog，那么每次大约读取的原始数据为76字节，及mysqlbinlog解析出来的一行AAAAAAAAAP4AAAAAAAAAAP4AAAAAAAAAAP4AAA

简单记录未做代码验证 hex(col) 返回字符集直接从database charset拿，跳过了转换，直接返回二进制，可以用于测试数据库存储的是什么字符集。（需要后期代码验证）hex(‘去’) 在client charset和connect charset设置一致的情况下，不需要转换，hex直接返回输入字符的二进制，可以用于测试终端到底是字符集。（需要后期代码验证）set name

简单记录可能还理解，做个笔记，不深入： http://mysql.taobao.org/monthly/2015/06/01/ buf_dblwr_init_or_load_pages 初始化dblwr从double write中，写入到内存 Recovering partial pages from the parallel doublewrite buffer at /opt

本文主要讲述MySQL 5.7.29，也会加入和8的对比 一、问题起源我们在运维MySQL的过程中，肯定多多少少遇到过Innodb row lock的问题，如果在线上遇到我们可能会看到一大片的session处于堵塞状态通常我们在show processlist中会看到如下： select for update语句处于sending data状态update/delete语句处于up

一、mysql.server启动方式basedir=/opt/mysql/mysql3315 datadir=/opt/mysql/mysql3315/data 进行查找，在解析参数文件的时候会带入 -e进行解析 /opt/mysql/mysql3315/bin/my_print_defaults -e /opt/mysql/mysql3315/my.cnf mysqld server my

RR隔离级别，简单记录如下 1、session 1开启read viewmysql> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Databa

一、问题来源问题来自一位朋友，如下：mysql客户端无法登陆，查看服务器负载没有发现高负载信息。通过pstack查看线程栈信息，没有发现异常信息。 二、问题诊断和解决一般来讲出现这种情况，我们会使用pstack看看新建立的线程为在什么函数上卡主了，然后很容易就能找到原因。但是出现这个问题过后，当mysql发起连接后卡主后，使用pstack查看mysqld服务端的进程，发现根本就没有线程与之进行交

一、问题来源这是一位客户的提供的案例如下，show processlist截图如下： 出现这种问题除非手动干预，杀掉FTWRL的session主从方可以进行。版本社区版5.7.26 二、堵塞图如果分析上面的堵塞可以画图如下： 三、关于woker线程w1和w3的等待这里我们需要重点关注参数slave_preserve_commit_order，在我将要出版的《深入理解MySQL主从原理》一

水平有限，如有错误请谅解。源码版本8.0.21。 在处理一个故障的时候怀疑大量的删除数据导致了查询比较慢，但是自己对purge线程的工作流程一直不太清楚，本文不做深入解析，只做工作流程解析，带着如下问题进行： del flag记录是否能够及时清理为什么History list length持续不为0，是否代表del flag记录没有清理purge线程触发的规则是什么 一、purg