InnoDB

这里先贴我的另一篇文章 https://www.cnblogs.com/zhangfengshi/p/12167957.html 详细有诠释 死锁的相关概念。 笔者最近在生产环境错误日志上看到updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction 这样的日志 ，网上看了很多文章 发现这篇文章 跟自己的场景非常接近。也没像作者翻binlog日志 但综合分析我的情况应该是相同表记录行锁冲突 在我一次执行三个update table1 ,table2 set table.xx=table2.xx where .. update table1,table2 set table1.yy=table2.yy where ... update table1,table2 set table1.xx=table2.xx where ... update table1,table2 set table1.zz=table2.zz where ... 而且我的where 条件列是没有建立索引 所以锁住的是整表。 事务一直执行过程中

点击上方蓝色“ 方志朋 ”，选择“设为星标” 回复“ 666 ”获取独家整理的学习资料！ 来源：r6d.cn/qDxd Mysql 锁类型 一、锁类型介绍： MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般 算法： next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap Gap锁，不锁记录，仅仅记录前面的Gap Recordlock锁（锁数据，不锁Gap） 所以其实 Next-KeyLocks=Gap锁+ Recordlock锁 二、死锁产生原因和示例 1、产生原因： 所谓死锁 ：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是：让不同的session加锁有次序 2、产生示例： 案例一 需求

Java技术栈 www.javastack.cn 关注阅读更多优质文章 最近总结了一波死锁问题，和大家分享一下。 Mysql 锁类型和加锁分析 MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度 算法： next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap Gap锁，不锁记录，仅仅记录前面的Gap Recordlock锁（锁数据，不锁Gap） 所以其实 Next-KeyLocks=Gap锁+ Recordlock锁 死锁产生原因和示例 产生原因 所谓死锁 <DeadLock> ：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是：让不同的session加锁有次序 产生示例 案例一 需求

最近总结了一波死锁问题，和大家分享一下。 Mysql 锁类型和加锁分析 MySQL有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度 算法： next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap Gap锁，不锁记录，仅仅记录前面的Gap Recordlock锁（锁数据，不锁Gap） 所以其实 Next-KeyLocks=Gap锁+ Recordlock锁 死锁产生原因和示例 产生原因 所谓死锁 <DeadLock> ：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。 死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是：让不同的session加锁有次序 产生示例 案例一 需求：将投资的钱拆成几份随机分配给借款人。 起初业务程序思路是这样的： 投资人投资后

MySQL语句加锁分析 前言：锁是为了解决并发带来问题而设计的, 阅读本文需要知道数据页 和 B+tree的知识 可以参考这篇文章： Mysql索引调优 1. 锁的基本模式 1.1 共享锁S和排他锁X S -共享锁：又叫读锁，其它事务可以继续加共享锁，但是不能继续加排他锁 X -排他锁：又叫写锁，一旦加了写锁之后，其它事务不能加锁了 兼容性:是指事务A获得一个某行某种锁之后，事务B同样的在这个行上尝试获取某种锁，如果能立即获取，则称锁兼容，反之叫冲突。 锁模式的兼容性汇总在以下矩阵中： X S X 冲突 冲突 S 冲突 兼容 1.2 意向锁(表锁) 意向锁 是表级锁，指事务稍后对表中的行需要加哪种类型的锁（共享锁或排他锁） 有两种类型的 意向锁 ： 意向共享锁( IS )：指一个事务将在表中某行加共享锁 意向排他锁( IX )：指一个事务将在表中某行加排他锁 ​ InnoDB支持多种粒度锁，允许行锁和表锁并存。为了使多个粒度级别上的锁变得切实可行，InnoDB使用了 意向锁 。 ​ 加入意向锁的目的 ： 意向锁 仅仅用于表锁和行锁的共存使用， 意向锁 是为了提高锁的兼容性判断效率。如果我们的操作仅仅涉及行锁，那么意向锁不会对我们的操作产生任何影响。在任一操作给表A的一行记录加锁前，首先要给该表加意向锁，如果获得了意向锁，然后才会加行锁，并在加行锁时判断是否冲突

Mysql解决The total number of locks exceeds the lock table size错误 在本地UPDATE 一百万条数据的某个字段时，第一次正确修改了，第二次爆出 The total number of locks exceeds the lock table size 错误 引用下网上的解释 If you're running an operation on a large number of rows within a table that uses the InnoDB storage engine, you might see this error: ERROR 1206 (HY000): The total number of locks exceeds the lock table size MySQL is trying to tell you that it doesn't have enough room to store all of the row locks that it would need to execute your query. The only way to fix it for sure is to adjust innodb_buffer_pool_size and restart MySQL. By

使用Galera Cluster需要下载包含wsrep补丁的mysql版本； 官网下载地址：http://galeracluster.com/downloads/ 安装前要卸载之前安装的mariadb或者mysql；或者迁移也可以，不过就是另一套操作了！ 具体的安装过程官网描述的很完整，就不赘述了！ http://galeracluster.com/documentation-webpages/installmariadb.html#enabling-the-yum-repository https://downloads.mariadb.org/mariadb/repositories/#mirror=shanghai-university 配置文件： [galera] # Mandatory settings wsrep_provider= 指定galera的插件 wsrep_cluster_name="my_wsrep_cluster" 指定集群的名字 wsrep_node_name= 指定当前节点名称，一般同主机名 wsrep_node_address= 指定当前节点的地址 wsrep_cluster_address= 指定集群包含的节点 binlog_format=row 指定二进制日志的格式 default_storage_engine=InnoDB 指定默认存储引擎

一 mysqldump指令实现数据备份、mysql指令实现数据还原 　　经常有朋友问我，DBA到底是做什么的，百科上说：数据库管理员（Database Administrator，简称DBA），是从事管理和维护数据库管理系统(DBMS)的相关工作人员的统称，属于运维工程师的一个分支，主要负责业务数据库从设计、测试到部署交付的全生命周期管理。DBA的核心目标是保证数据库管理系统的稳定性、安全性、完整性和高性能。 　　百科出来的内容总是那么的专业，让人看完之后的感觉是很解释的很好，但是我没有看懂或者似懂非懂的模糊感。。哈哈，其实我认为，DBA主要做三件事情：1.保证公司的数据不丢失不损坏 2.提高数据库管理系统的工作性能 　　对于现在的公司来讲，数据变得尤为重要，可以说最重要，你的网站可以无法访问，服务器可以宕机，但是数据绝对不能丢，所以我们本节内容就冲着如果保护好数据而来的。本篇博客的内容并不是很深入，毕竟不是专业的DBA，只是作为超哥的讲课内容，让大家学一些数据备份的基本操作，入门级别咱们只讲一下mysqldump指令，至于如果做主从复制，双机热备，数据库高可用，数据库集群，大家可以去看我其他的博客，博客写完了，目前还在整理，整理好之后我就发出来供大家批评指正，共同学习~~~，因为毕竟咱们学的是开发，本篇内容就当作是拓展自己的知识领域吧，对你来讲都是很有好处的~~~大家加油吧 　

这是学习笔记的第 2253 篇文章 读完需要 5 分钟 速读仅需3分钟 关于发号器的使用，其实有一个大背景，那就是关于主键的一些设计问题，在MySQL中如果一张表没有主键，实际的数据处理就有点麻烦了。 因为在InnoDB存储引擎中，表都是按照主键的顺序进行存放的，我们叫做聚簇索引表或者索引组织表（IOT） （1）显式的创建主键Primary key。 （2）判断表中是否有非空唯一索引，如果有，则为主键。 （3）如果都不符合上述条件，则会生成UUID的一个隐式主键（6字节大） 可以使用类似的SQL来看到这个隐藏列，select _rowid from test ; 这和主键有什么关系？主要是因为有些时候我们创建主键就是为了创建而创建，没有实际的业务含义，所以会形成一种使用习惯，那就是启用自增列。 自增列的问题很多，有些几句话还说不清楚，大体有如下的一些问题 自增列没有业务含义 过度依赖自增列 自增列和状态值主键并存，反而影响业务逻辑和性能 MySQL历史遗留bug，在MySQL 8.0该问题才修复 到了这里，我们的需求也基本明确了，我们所说的发号 器其实就是要确保每次取到的ID号都是唯一的，当然也显而易见是趋势递增的。 我来说一个初版的发号器实现，假设我们创建一张表test_inc,假设按照业务逻辑，自增列的初始值为1000，则建表语句为： create table test_inc

一、相关名词 |--表级锁（锁定整个表） |--页级锁（锁定一页） |--行级锁（锁定一行） |--共享锁（S锁，MyISAM 叫做读锁） |--排他锁（X锁，MyISAM 叫做写锁） |--悲观锁（抽象性，不真实存在这个锁） |--乐观锁（抽象性，不真实存在这个锁） 二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储引擎，之后使用 InnoDB 。查看当前存储引擎： show variables like '%storage_engine%'; MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。 而 InnoDB 与 MyISAM 的最大不同有两点：一是 InnoDB 支持事务；二是 InnoDB 采用了行级锁。也就是你需要修改哪行，就可以只锁定哪行。 在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁