InnoDB

MySQL 加锁处理分析 本文来自： 何登成的技术博客 一、背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 1.1 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中

打算写一系列死锁分析的例子，将平时遇到的死锁例子记录下来，做好记录，也当做积累。 死锁输出 2017 -10 -10 17 :07:21 7f45a5104700InnoDB: transactions deadlock detected, dumping detailed information. 2017 -10 -10 17 :07:21 7f45a5104700 *** (1) TRANSACTION: TRANSACTION 47225424098 , ACTIVE 0 sec starting index read mysql tables in use 1 , locked 1 LOCK WAIT 6 lock struct(s), heap size 1184 , 3 row lock(s), undo log entries 1 MySQL thread id 40396441 , OS thread handle 0x7f569a68e700 , query id 9746347697 10.200 .181 .72 trade updating update table_b set updated_at = now(), price = 36900 , where id = 1 and sku_id = 36171933 AND goods_id = 2

ALTER FUNCTION 语句 此语句可用于更改存储函数的特性。一个ALTER FUNCTION语句中可以指定多个更改。但是，不能使用此语句更改存储函数的参数或主体；要进行此类更改，必须使用DROP FUNCTION 和 CREATE FUNCTION删除并重新创建函数。 必须具有该函数的ALTER ROUTINE权限才能执行（该权限自动授予函数创建者）。如果启用了二进制日志记录，ALTER FUNCTION 语句可能还需要SUPER权限。 ALTER INSTANCE 语句 ALTER INSTANCE定义了适用于MySQL服务器实例的操作。语句支持以下操作： ●ALTER INSTANCE {ENABLE | DISABLE} INNODB REDO_LOG 此操作启用或禁用InnoDB 重做日志记录。默认情况下启用重做日志记录。此功能仅用于将数据加载到新的MySQL实例中。语句不会写入二进制日志，这个语句在MySQL8.0.21中引入。 警告 请勿在生产系统上禁用重做日志记录。虽然允许在禁用重做日志记录时关闭并重新启动服务器，但禁用重做日志记录时意外的服务器停止可能会导致数据丢失和实例损坏。 ALTER INSTANCE [ENABLE|DISABLE] INNODB REDO_LOG 操作需要一个独占备份锁，这会阻止其他ALTER INSTANCE操作并发执行

行转列： 多行转多列 列转行：多列转多行 以下转自：https://www.cnblogs.com/xiaoxi/p/7151433.html 一、行转列 即将原本同一列下多行的不同内容作为多个字段，输出对应内容。 建表语句 DROP TABLE IF EXISTS tb_score; CREATE TABLE tb_score( id INT(11) NOT NULL auto_increment, userid VARCHAR(20) NOT NULL COMMENT '用户id', subject VARCHAR(20) COMMENT '科目', score DOUBLE COMMENT '成绩', PRIMARY KEY(id) )ENGINE = INNODB DEFAULT CHARSET = utf8; 插入数据 INSERT INTO tb_score(userid,subject,score) VALUES ('001','语文',90); INSERT INTO tb_score(userid,subject,score) VALUES ('001','数学',92); INSERT INTO tb_score(userid,subject,score) VALUES ('001','英语',80); INSERT INTO tb_score(userid

转载自： https://blog.csdn.net/sinat_27406925/article/details/77507478 coderpwh mysql 行列转换 ，在项目中应用的极其频繁，尤其是一些金融项目里的报表。其中最为头痛的就是多行转多列，动态的列行转换。最近在研究这些行里转换，还是从最为简单的行列转换开始。 sql 脚本： -- 创建表 学生表 CREATE TABLE `student` ( `stuid` VARCHAR(16) NOT NULL COMMENT '学号', `stunm` VARCHAR(20) NOT NULL COMMENT '学生姓名', PRIMARY KEY (`stuid`) ) COLLATE='utf8_general_ci' ENGINE=InnoDB; -- 课程表 CREATE TABLE `courses` ( `courseno` VARCHAR(20) NOT NULL, `coursenm` VARCHAR(100) NOT NULL, PRIMARY KEY (`courseno`) ) COMMENT='课程表' COLLATE='utf8_general_ci' ENGINE=InnoDB; -- 成绩表 CREATE TABLE `score` ( `stuid` VARCHAR(16) NOT

http://blog.csdn.net/sinat_27406925/article/details/77507478 mysql 行列转换 ，在项目中应用的极其频繁，尤其是一些金融项目里的报表。其中最为头痛的就是多行转多列，动态的列行转换。最近在研究这些行里转换，还是从最为简单的行列转换开始。 sql 脚本 -- 创建表 学生表 CREATE TABLE `student` ( `stuid` VARCHAR( 16 ) NOT NULL COMMENT ' 学号 ' , `stunm` VARCHAR( 20 ) NOT NULL COMMENT ' 学生姓名 ' , PRIMARY KEY (`stuid`) ) COLLATE = ' utf8_general_ci ' ENGINE = InnoDB; -- 课程表 CREATE TABLE `courses` ( `courseno` VARCHAR( 20 ) NOT NULL, `coursenm` VARCHAR( 100 ) NOT NULL, PRIMARY KEY (`courseno`) ) COMMENT = ' 课程表 ' COLLATE = ' utf8_general_ci ' ENGINE = InnoDB; -- 成绩表 CREATE TABLE `score` ( `stuid`

统计表的结果是以党员为分组,将所有的活动前部已列的形式展示,统计每一个党员参与的各个活动的次数,没有参与为0次 需要的最终统计结果预览如下 姓名 支部名称 活动1 活动2 活动3 活动4 党员1 党支部名称 1 1 1 1 党员2 党支部名称 0 0 0 1 党员3 党支部名称 0 0 0 2 表结构和数据 CREATE TABLE `t_party_event` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '党员活动名称', `event_time` datetime DEFAULT NULL COMMENT '活动时间', `user_name` varchar(255) COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '党员名称', `branch_id` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '支部id', `branch_name` varchar(255) CHARACTER SET utf8mb4 COLLATE

原文链接：http://hedengcheng.com/?p=525 问题背景 今天，看到Twitter的DBA团队发布了其最新的MySQL分支： Changes in Twitter MySQL 5.5.28.t9 ，此分支最重要的一个改进，就是修复了MySQL 的Bug #67718： InnoDB drastically under-fills pages in certain conditions 。关于此Bug的详细描述，以及如何重现此问题，可以阅读以上的Bug链接，以下简单描述下此Bug对应的问题： InnoDB的索引分裂策略，在特定的情况下，索引页面的分裂存在问题，导致每个分裂出来的页面，仅仅存储一条记录，页面的空间利用率极低。 此Bug引起了我的兴趣，因此准备跟大家简单聊聊B+树索引的结构、B+树的分裂、B+树分裂操作的优化、Bug #67718的成因，以及个人对如何修复此Bug的一些建议等。 B+树索引结构 传统关系型数据库(Oracle/MySQL/PostgreSQL…)，其主要的索引结构，使用的都是B+树。更有甚者，InnoDB引擎的表数据，整个都是以B+树的组织形式存放的。下图，是一个经典的B+树组织结构图(2层B+树，每个页面的扇出为4)： 注意： 此B+树，以InnoDB实现的B+树结构为准； 此B+树，有5条用户记录，分别是1，2，3，4，5； B

前言 　　换了工作之后，接近半年没有发博客了（一直加班），emmmm.....今天好不容易有时间，记录下工作中遇到的一些问题，接下来应该重拾知识点了。因为新公司工作中MySQL库经常 出现查询慢，锁等待，节点挂掉........等一系列问题 。导致每个程序员头都很大，一味抱怨“ 为什么我就查一条数据这么卡”，"我TM加了索引的啊，怎么还怎么慢 "...........我想默默说的是，大部分MySQL出现锁等待， 查询奇慢的情况基本都是因为SQL写的不好（有坑），或者数据表设计的不完善 。对，不用想！这些所有的坑很大一部分都是自己造成的。那么是什么原因造成的，大部分只是抱怨，而不去关注MySQL的一些细节问题，比如： MySQL行锁的细节，什么情况下会使用表锁等 。所以今天先讨论记录下InnoDB特有的行锁的一些细节，加强认识。 　　 InnoDB不同于MyISAM最大的两个特点就是：一是支持事务，二是支持行锁 ；毋庸置疑，因为这两个特性大部分都采用InnoDB引擎，其中的支持行锁就是InnoDB适合多并发优势所在，但是行锁的一些细节没有深入理解过的话，可能会造成一定的误解，造成“ 看似命中索引，走行锁，结果却是表锁，最终导致锁等待情况 ”。 一、 InnoDB行锁的实现方式 　　 通过给索引上的索引项加锁来实现的，也就意味着： 只有通过索引条件检索数据， InnoDB 才使用行级锁

数据库 以下是对面试常见面试题整理，来自知乎大神分享的pdf，引用部分链接已给出，如果有没有标注的，纯属意外，希望提醒。这篇主要整理出来给自己看的 B/B+树 B/B+ 一、B树： 定义：B 树又叫平衡多路查找树。一棵m阶的B 树 的特性如下： 树中每个结点最多含有m个孩子（m>=2）； 除根结点和叶子结点外，其它每个结点至少有[ceil(m / 2)]个孩子（其中ceil(x)是一个取上限的函数）； 若根结点不是叶子结点，则至少有2个孩子（特殊情况：没有孩子的根结点，即根结点为叶子结点，整棵树只有一个根节点）； 所有叶子结点都出现在同一层， 叶子结点不包含任何关键字信息 每个非终端结点中包含有n个关键字信息： (n，P0，K1，P1，K2，P2，......，Kn，Pn)。其中： Ki (i=1...n)为关键字，且关键字按顺序升序排序K(i-1)< Ki Pi为指向子树根的接点，且指针P(i-1)指向子树种所有结点的关键字均小于Ki，但都大于K(i-1)。 关键字的个数n必须满足： [ceil(m / 2)-1]<= n <= m-1。如下图所示： B树中的每个结点根据实际情况可以包含大量的关键字信息和分支(当然是不能超过磁盘块的大小，根据磁盘驱动(disk drives)的不同，一般块的大小在1k~4k左右)；这样树的深度降低了