mysql存储过程出现锁表锁行的情况怎么解决
只有分配到行锁的事务才有权力操作该数据行，直到该事务结束，才释放行锁，而其他没有分配到行锁的事务就会产生行锁等待。如果等待时间超过了配置值（也就是 innodb_lock_wait_timeout 参数的值，个人习惯配置成 5s，MySQL 官方默认为 50s），则会抛出行锁等待超时错误。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。（3） 不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。（4） 循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。
MySQL有两种死锁处理方式：死锁检测 （默认开启） 死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。回滚 检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。
锁还有多种粒度，比如可以在表上加锁，也可以在记录上加锁。 产生死锁的原因主要是：（1）系统资源不足。（2） 进程运行推进的顺序不合适。（3）资源分配不当等。如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。
gap lock 导致了并发处理的死锁 在mysql默认的事务隔离级别（repeatable read）下，无法避免这种情况。只能把并发处理改成同步处理。或者从业务层面做处理。
深入理解MySQL数据库各种锁(总结)
总结，理解Mysql的锁机制是保证高并发环境稳定的关键。在编写业务代码时，应避免直接的删除-插入操作，尤其是对不存在的id，同时要考虑隔离级别的设置，以及利用Next-Key Locks来降低死锁的风险。通过合理的锁策略，我们可以确保在并发操作下，数据库性能的稳定和业务的正常运行。
深入理解MySQL InnoDB存储引擎的锁机制与死锁解析 在MySQL Server 0.33的平台上，InnoDB存储引擎的锁机制主要包括latch（如mutex和rwlock）和事务锁（lock），它们确保了并发操作对数据一致性至关重要的临界区的正确访问。
共享锁：排他锁：https：// 乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改（天真）， 操作数据时不会上锁 ，但是 更新时会判断在此期间有没有别的事务更新这个数据，若被更新过，则失败重试 ；适用于读多写少的场景。
MySQL数据库中的锁有共享锁，排他锁，行锁，表级锁，行级锁以及页面锁。共享锁（Shared Lock，也叫S锁）共享锁（S）表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。
全局锁 顾名思义，全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是Flushtableswithreadlock（FTWRL）。
MySQL的这些操作中哪些操作会产生锁?
MySQL数据库中的锁有共享锁，排他锁，行锁，表级锁，行级锁以及页面锁。共享锁（Shared Lock，也叫S锁）共享锁（S）表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。
在实际操作中，SQL语句的加锁策略取决于多种因素，如索引类型、隔离级别和锁定模式。例如，对主键或唯一索引的更新操作会加写锁，而读操作在RC和RR隔离级别下通常不加锁。无索引情况下，全表扫描可能导致大量锁竞争，MySQL通过semi-consistent read优化来缓解。
MySQL中的锁，按照锁的粒度分为：全局锁，就锁定数据库中的所有表。表级锁，每次操作锁住整张表。行级锁，每次操作锁住对应的行数据。全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将阻塞。
在可重复读级别下，update和delete操作会自动应用Next-Key Locks，同时，Insert Intention Locks为INSERT操作预先锁定间隙。在实际操作中，比如session 1在id=25加幻读锁，session 2和3在id=26尝试插入时会因gap锁而阻塞，直到session 1释放。
这时候就会因为持有对方需要的锁，而又等待对方释放自己需要的锁，导致死锁。比如两个账户记录转账，两个事务，一个事务是从a转账给b，一个事务是从b转账给a。如果如果都是先给转出账户（或转入账户）加锁，然后给转入账户（或转出账户）加锁。就可能出现死锁。
mysql锁定了数据库表只能写,为什么还可以读?
如果另一个写入会话进入并启动新事务并获取针对父表的写锁定，则即使会话 3 完成，ALTER 仍将被阻止。只要我保持一个对父表打开元数据锁定的活动事务，子表上的 ALTER 将永远不会完成。
兄弟，锁的作用，就是把权限归为私有，其它人用不了。你自已把表锁了，自已当然还能用。你起另外一个客户端试试。而且写锁和读锁，是有区别的。
MySQL中的锁，按照锁的粒度分为：全局锁，就锁定数据库中的所有表。表级锁，每次操作锁住整张表。行级锁，每次操作锁住对应的行数据。全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将阻塞。
简单说，就是lock table，不让别人动 锁分共享锁和排它锁。共享锁时，别人能读，不能改变量表数据 排它锁时，别人既不能读，也不能改表数据 根据以上特点，应该就知道何时使用锁了。不想让别人变更数据，对自己产生影响，就加锁。
没有权限吧，如果可以，换成root，肯定没问题。
共享锁（Shared Lock，也叫S锁）共享锁（S）表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。产生共享锁的sql语句：select * from ad_plan lock in share mode；排他锁（Exclusive Lock，也叫X锁）排他锁表示对数据进行写操作。
mysql表锁为什么不会出现死锁
1、、如果出现异常，可以减少数据的丢失。因为一次可以只回滚一行或者几行少量的数据。行级锁的缺点如下：1）、比页级锁和表级锁要占用更多的内存。2）、进行查询时比页级锁和表级锁需要的i/o要多，所以我们经常把行级锁用在写操作而不是读操作。3）、容易出现死锁。
2、会产生死锁的，只是没有满足产生死锁的条件。
3、MySQL有三种锁的级别：页级、表级、行级，这3种锁的特性可大致归纳如下：表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
4、锁机制的实现方式，事务隔离级别的差异。锁机制的实现方式：MySQL和Oracle在锁机制的实现上有所不同。MySQL使用的是基于锁的并发控制，Oracle使用的是多版本并发控制。事务隔离级别的差异：MySQL和Oracle在默认的事务隔离级别上也有差异。
5、表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。
6、mysql一般不会死锁，除非程序有问题。性能优先事务不优先的数据库（设置）不要追求可靠性万无一失。网站性能问题主要是数据库量大了以后，查询扫描硬盘而产生的。其它性能不要太在意。编写代码的时候不要坚持性能原则，而是坚持可用性原则。
MySQL—Update和Insert操作是锁表还是锁行
但是有一种情况下，select和insert相互不干涉，当Concurrent _Insert参数为2时，无论MYISAM存储引擎的表数据文件的中间部分是否存在因为删除数据而留下的空闲空间，都允许在数据文件尾部进行。innodb引擎没这特性，他的锁机制基于索引。
通常用在DML语句中，如INSERT， UPDATE， DELETE等。InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。
行锁或者叫record lock记录锁，锁定单个行记录的锁，防止其他事物对次行进行update和delete操作，在RC，RR隔离级别下都支持。间隙锁Gap lock，锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事物在这个间隙进行insert操作，产生幻读，在RR隔离级别下都支持。
