MySQL:关于RR模式下insert..selcet sending data状态说明
一、案例由来最近看到有人在问如下: 其中的sending data是什么意思。隔离级别为RR,语句为insert..select。 二、关于sending data以前就说过这个问题,实际上sending data可能包含如下: Innodb 层数据的定位返回给MySQL 层Innodb 层数据的查询返回给MySQL 层Innodb 层数据的修改(如果是insert..select)In
MySQL:ERROR 1286 (42000): Unknown storage engine 'MyISAM'
一、错误演示如下: root@localhost:test:09:49:03>create table ttt(id int) engine=myisam ; ERROR 1286 (42000): Unknown storage engine 'MyISAM' 二、相关参数 enforce_storage_engine:建表进行引擎检查,是否满足设置的引擎值。sql_mode(NO
MySQL:关于ICP特性的说明(未完)
ICP特性是我们DBA在实际的SQL优化过程中经常能够遇到的,但是某些出现ICP的地方看起来并不那么直观,为我们产生了一定的困扰。本文通过MySQL 5.7.22 和Innodb引擎来解释一下各种情况下ICP到底下推了什么条件到引擎层。 一、ICP简述ICP:全称为Index Condition Pushdown,是MySQL 5.6引入的一项优化策略。简单的来说就是将本该在MySQL进行过
MySQL:pt-online-schema-change原理及注意点(未完)
欢迎关注我的《深入理解MySQL主从原理 32讲 》 一、pt-online-schema-change 原理简析首先要说明pt-online-schema-change工具并不是说修改表结构的时候不上锁,通常我们说的锁一般包含innodb 行锁和MDL lock。而pt-online-schema-change工具就是将某些使用COPY算法的DDL操作使用DML操作来代替,换句话说就是
MySQL:Table_open_cache_hits/Table_open_cache_misses/Table_open_cache_overflows
欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 这3个值的均和函数open_table有关,且他们均和table cache和table share有关,下面是一个粗略的解释,具体解释参考其他书籍: table cache:会话实例化(instance),通过table share表定义实例化,持有文件的文件描述符。table share:内存中表的定义。 一、Ta
MySQL:5.6 大事务show engine innodb status故障一例
今天遇到一个朋友的线上问题,大概意思就是说,我有一个线上的大事务大概100G左右,正在做回滚,当前看起来似乎影响了线上的业务,并且回滚很慢,是否可以减轻对线上业务的影响。并且朋友已经取消了双1设置,但是没有任何改观。版本MySQL 5.6 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 首先我们需要知道的是,MySQL并不适合大事务,大概列举一些MySQL中大事务
MySQL:理解MDL Lock
本文基于源码版本5.7.14水平有限,有误请谅解笔者已经将加好MDL 获取过程和释放过程的版本放到了github如下:https://github.com/gaopengcarl/percona-server-locks-detail-5.7.22供参考 一、MDL Lock综述MySQL中MDL锁一直是一个比较让人比较头疼的问题,我们谈起堵塞一般更加倾向于InnoDB层的row loc
随笔:MySQL 普通3表join顺序
只考虑nest loop,不考虑hash join 条件如下:a,b,c where a.id=b.id and a.id=c.id where a.name=’gaopeng’,b.name=’gaopeng’,c.name=’gaopeng’ 假设a为驱动表,先连接b,再连接c ,且b,c表 id均有索引。流程如下: loop: 1、访问驱动表a,过滤条件a.name='gaope
MySQL:排序(filesort)详细解析
能力有限有误请指出。本文使用源码版本:5.7.22 引擎为:Innodb 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 如果图片不能显示可查看下面链接:https://www.jianshu.com/p/d636215d767f 排序(filesort)作为DBA绕不开的话题,也经常有朋友讨论它,比如常见的问题如下: 排序的时候,用于排序的数据会不会如Inn
第20节 从库MTS多线程并行回放(二)
从库MTS多线程并行回放(二) 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 本节包含一个笔记如下:https://www.jianshu.com/p/e920a6d33005 这一节会先描述MTS的工作线程执行Event的大概流程。然后重点描述一下MTS中检查点的概念。在后面的第25节我们可以看到,MTS的异常恢复很多情况下需要依赖这个检查点,从检查点位置开始扫描r
第19节 从库MTS多线程并行回放(一)
从库MTS多线程并行回放(一) 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 本节包含一个笔记如下:https://www.jianshu.com/p/8706d7422d89 之所以将MTS的相关知识放到这里讲解,是因为后面的几节会用到这部分知识,如果不先讲解后面几节将没有办法进行描述。 一、综述与单SQL线程的回放不同,MTS包含多个工作线程,原有的SQL线程蜕
MySQL:count(*) count(字段) 实现上区别
水平有限如有误请指出源码版本:5.7.22欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 继上一篇文章:https://www.jianshu.com/p/ce063e2024ad MySQL:查询字段数量多少对查询效率的影响 我们继续来讨论一下count(*) count(字段) 实现上的区别。注意我们这里都使用Innodb做为存储引擎,不讨论其他引擎。因为了有了前
随笔:MySQL setup_instruments中关于部分信息不能修改
朋友告诉我如下操作不能修改 mysql> update setup_instruments set enabled='no' where name='memory/performance_schema/table_handles'; Query OK, 1 row affected (2.61 sec) Rows matched: 1 Changed: 1 Warnings
MySQL:查询字段数量多少对查询效率的影响
欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 水平有限如有误请指出 源码版本:5.7.22 这个问题是最近一个朋友问我的。刚好就好好看了一下,留下这样的记录。本文给出一些函数接口,末尾给出一些调用堆栈,为感兴趣的朋友做一个参考,也为自己做一个笔记。 一、问题由来我们知道执行计划的不同肯定会带来效率的不同,但是在本例中执行计划完全一致,都是全表扫描,不同的只有
第12节 巧用Event发现问题
巧用Event发现问题 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 有了前面对Event的了解,我们就可以利用这些Event来完成一些工作了。我曾经在学习了这些常用的Event后,使用C语言写过一个解析Event的工具,我叫它‘infobin’,意思就是从binary log提取信息的意思。据我所知虽然这个工具在少数情况下会出现BUG但是还是有些朋友在用。我这里并不是要推
MySQL:show processlist Time负数的思考
欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 如果图片不能显示可查看下面链接:https://www.jianshu.com/p/d636215d767f 一、问题来源这是一个朋友问我的一个问题,问题如下,在MTS中Worker线程看到Time为负数是怎么回事,如下: 二、关于show processlist中的Time实际上show processlist中的信息基
随笔:MySQL中'' ' ' NULL在Innodb存储的区别
欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 如果图片不能显示可查看下面链接:https://www.jianshu.com/p/d636215d767f 一、测试环境mysql> create table testn(a varchar(20),b varchar(20)); Query OK, 0 rows affected (0.43 sec) mysq
深入理解MySQL主从原理(32讲)重点及目录
本文是我的系列 深入理解MySQL主从原理(32讲) 中的重点及目录情况。欢迎大家订阅如下: 第1节:GTID的基本概念 1.1 GTID的作用1.2 GTID的基本表示1.3 server_uuid的生成1.4 GTID的生成1.5 GTID_LOG_EVENT和PREVIOUS_GTIDS_LOG_EVENT简介1.6 gtid_executed表的作用 第2节:my
MySQL:timestamp时区转换导致CPU %sy高的问题
水平有限,如果有误请谅解。 这个问题是一个朋友遇到的@风云,并且这位朋友已经得出了近乎正确的判断,这位下面进行一些描述。 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 一、问题展示下面是问题当时的系统负载如下: 我们可以看到40.4%sy 正是系统调用负载较高的表现,随即朋友采集了perf如下: 接下来朋友采集了pstack给我,我发现大量的线程处于如
随笔:sending data状态包含了使用内部临时表
这是一个我的随笔记录,这些过程非常有用,也非常明显。 欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下: 语句如下: mysql> desc select id,count(*) from t110 group by id; +----+-------------+-------+------------+------+---------------+------