mysql锁

1 .innodb 共享锁(lock in share mode)演示 会话1 会话2 SET autocommit=0; SELECT cityname FROM city WHERE city_id=14; city_id country_id cityname CityCode 14 2 22 001 SET autocommit=0; SELECT cityname FROM city WHERE city_id=14; city_id country_id cityname CityCode 14 2 22 001 -- 对 city_id=14加共享锁 SELECT * FROM city WHERE city_id=14 LOCK IN SHARE MODE; city_id country_id cityname CityCode 14 2 22 001 -- 也对 city_id=14加共享锁 SELECT * FROM city WHERE city_id=14 LOCK IN SHARE MODE; city_id country_id cityname CityCode 14 2 22 001 -- 当前会话对锁定的记录进行更新操作，等待锁。等待中.... UPDATE city SET cityname='深圳' WHERE city_id =14; --

MySQL锁 三类锁 全局锁 表级锁 行锁 全局锁 全局锁就是对整个数据库加锁 Flush tables with lock（FTWRL）全局读锁 使用场景，给全库做逻辑备份 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆； 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟。 全局读锁期间只能读，不能更新是个问题 mysqldump工具 官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数–single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。 你一定在疑惑，有了这个功能，为什么还需要 FTWRL 呢？一致性读是好，但前提是引擎要支持这个隔离级别。比如，对于 MyISAM 这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时，我们就需要使用 FTWRL 命令了。所以，single-transaction 方法只适用于所有的表使用事务引擎的库。 如果有的表使用了不支持事务的引擎，那么备份就只能通过 FTWRL 方法。这往往是 DBA 要求业务开发人员使用 InnoDB 替代 MyISAM 的原因之一。 表级锁 MySQL 里面表级别的锁有两种：一种是表锁

InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题 1．事务（Transaction）及其ACID属性 事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。 银行转帐就是事务的一个典型例子。 //https://blog.csdn.net/bigtree_3721/article/details/77417518 2．并发事务处理带来的问题 相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量

文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。 锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中数据其实是一种供大量用户共享的资源，所以在并发访问时我们需要保证数据的一致性和有效性，而锁冲突是影响数据库并发性能最关键的因素之一。所以本篇文章主要讨论Mysql中锁机制的特点。Mysql的锁机制包含多种：行锁，表锁，读锁，写锁等，其实就是使用不同的存储引擎会支持不同的锁机制。而我主要是针对InnoDB存储引擎下的7种类型的锁进行介绍。 InnoDB引擎锁类型： 共享/排它锁 记录锁 间隙锁 临键锁 自增锁 意向锁 插入意向锁 MySQL中InnoDB存储引擎与MyISAM存储引擎锁机制其实有两个比较显著的不同点： InnoDB支持事务操作。 InnoDB默认采用行级锁。 InnoDB锁机制实现原理 InnoDB存储引擎其实是通过给索引上的索引项添加锁，也正是由于给索引项加锁，所以只有通过索引条件查询数据，InnoDB引擎才会选择使用行级锁，否则会使用表锁。行级锁与表级锁本身有许多不同之处，事务的引入也带来了一些新问题。 事务 说到事务，四个最基本的特性我想大多数人再清楚不过了： 原子性: 事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性：在事务开始和完成时，数据都必须保持一致状态。 隔离性

--查询表锁争用情况 show status like 'ord%'; --查看数据库中表的状态，是否被锁； SHOW PROCESSLIST; --脏读 读未提交 --A事务读取了B事务修改但未提交的数据 B稍后时候进行了回滚，那么A就发生了脏读 --不可重复读 读不回去了 --A事务在进行相同条件查询的时候，（两次或者两次以上）出现了每次结果不一样，因为在查询期间有其他事务进行了update操作，导致结果不一致 --幻读 读多了 --A事务在进行相同条件查询的时候，因为在查询期间发现记录数不一样了 ，因为进行了insert操作，导致结果不一致 --隔离级别 --1. 1 Read uncommitted 脏读 --2. 2 Read committed 避免脏读 会有重复读和幻读 --3. 4 repeatable read 可重复读 避免不可重复读 --4. 8 serializable 避免幻读 这样性能会低 --1关闭A自动提交 set autocommit =0; --3开启事务 start transaction; --4执行更新 update tableA set nane='je' where id='1'; --6回滚 rollback； --2设置B隔离级别 读到A的未提交的数据uncommitted --Read uncommitted(脏读)Read

一、为什么需要锁（并发控制）？ 在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。 典型的冲突有： 1.丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。 2.脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。 为了解决这些并发带来的问题。 我们需要引入并发控制机制。 二、 并发控制机制 锁,即给我们选定的目标数据上锁，使其无法被其他程序修改。 1.悲观锁：指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态 2.乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。 三、乐观锁的实现 使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为 数据库 表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候

mysql的锁机制 含义：锁是计算机协调多个进程或线程并发访问某一资源的机制 在数据库中，除了传统的计算资源（如CPU,RAM,I/O等）的争用之外，数据也是一种用户共享的资源。如何保证数据并发访问的一直型、有效性是所有数据库必须解决的问题，锁冲突也是影响数据库并发访问性能的一个重要因素。因而，锁对数据库很重要。 分类 按照操作来分：读/写锁 读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会相互影响。 写锁（排他锁）：当前写操作没有完成前，他会阻断其他写锁和读锁。 #查看表上加着的锁 show open tables; #手动增加表锁 lock table 表名1 read(write), 表名2 read(write),其他； #释放锁 unlock tables; #加了读锁（共享锁）之后 lock table 表1 read; 在加锁的session1中： 1.可以读自己吗？ 可以 2.可以修改表的内容吗？ 不可以！！！！！！！！！！！！会报错error 3.可以读别人吗？ 不可以！！！！！！！！！！！ 在另外一个session2中： 1.可以读session1中的读锁表吗？ 可以 2.可以修改表的内容吗？ 不可以！！！！！！！！！！！！会出现阻塞（一直等待） 3.可以读别人吗？ 可以！ #加了写锁（排他锁）之后 lock table 表1 write;

事务acid原则 原子性 隔离性 一致性 持久性 事务的概念 把需要保证原子性、隔离性、一致性和持久性的一个或者多个数据库操作称为事务。 事务的使用 语法 begin;//开启一个事务 some sql;//需要执行的语句 savepoint bussiness1;//事务保存点 some sql; roll back to bussiness1;//回滚 commit;//提交事务 rollback;//如果需要手动回滚的话在提交之前删除这句 事务的自动提交 通常情况下mysql默认自动提交事务。既每一个语句都都会直接提交事务，可以通过 set autocommit=off 来实现手动提交。 隐式提交 在一些操作下，哪怕在事务中也可能会自动把事务进行提交。 定义或者修改数据库对象的数据定义语言，指对数据库、表、视图、存储过程等进行修改。 隐式使用或者修改mysql数据库中的表：当我们使用ALTER USER、CREATE USER、DROP USER、GRANT、RENAME USER、SET PASSWORD等语句时也会隐式的提交前边语句所属于的事务。 事务控制或关于锁定的语句：前一个事务尚未完成又开启事务时上一个会自动提交。使用lock tables、unlock tables等关于锁定的语句也会隐式提交之前的事务。 加载数据的语句：如果使用load

锁的基本类型 　　数据库上的操作可以归纳为两种：读和写。 　　多个事务同时读取一个对象的时候，是不会有冲突的。同时读和写，或者同时写才会产生冲突。因此为了提高数据库的并发性能，通常会定义两种锁：共享锁和排它锁。 使用的是innodb数据库, 两种锁 1.共享锁 (s锁)：表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。（如果试衣间的门还没被锁上，顾客都能够同时进去参观） 产生共享锁的sql： begin； sql：select * from ad_plan lock in share mode; commit sequelize: try { 　　 const transaction = await this.ctx.model.transaction({ autocommit: true, isolationLevel: 'SERIALIZABLE' }); const platformResult = await this.ctx.model.PlatformInfo.findOne( { where: { platform_id, }, transaction, lock: transaction.LOCK.SHARE, } ); await transaction.commit(); } catch(error) { await transaction

原文链接： http://blog.csdn.net/soonfly/article/details/70238902 锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。