mysql事务未提交导致锁等待如何解决
、实验环境
Myql版本5.7.17-log
实验表结构
(root@localhost)[apex]> show create table test;+-------+-----------------------------------------------------------------------------------------------------------------------------------+| Table| Create Table |+-------+-----------------------------------------------------------------------------------------------------------------------------------+|test | CREATE TABLE `test` ( `x` int(11) NOT NULL, `y` int(11) DEFAULT NULL, PRIMARY KEY (`x`))ENGINE=InnoDB DEFAULT CHARSET=gbk |+-------+-----------------------------------------------------------------------------------------------------------------------------------+1 row inset (0.01 sec)
插入数据
(root@localhost)[apex]> insert into test values(1,1);(root@localhost)[apex]> insert into test values(2,2);(root@localhost)[apex]> insert into test values(3,3);2、锁产生步骤
会话一：开启事务，更新数据，不提交
(root@localhost)[apex]> begin;QueryOK, 0 rows affected (0.00 sec)(root@localhost)[apex]> update test set y=y+1 where x=1;QueryOK, 1 row affected (0.00 sec)Rowsmatched: 1 Changed: 1 Warnings: 0
查看当前连接id号（线程id号）
(root@localhost)[apex]> select connection_id();+-----------------+|connection_id() |+-----------------+| 4 |+-----------------+1 row inset (0.00 sec)
会话二：开启另一个事务，更新同一行数据，
(root@localhost)[apex]> begin;QueryOK, 0 rows affected (0.00 sec) (root@localhost)[apex]> update test set y=y+1 where x=1;ERROR1205 (HY000): Lock wait timeout exceeded; try restarting transaction
执行update test set操作时，会卡在那边，不执行，经过50秒后，会报错；
（上面的卡住现象，是由于锁，可以通过查看表information_schema.innodb_lock，获取锁的状态）
(root@localhost)[information_schema]> select * from information_schema.innodb_locks;+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+|lock_id | lock_trx_id | lock_mode| lock_type | lock_table | lock_index| lock_space | lock_page | lock_rec | lock_data |+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+|757082:3279:3:2 | 757082 | X | RECORD | `apex`.`test` | PRIMARY | 3279 | 3 | 2 | 1 ||757081:3279:3:2 | 757081 | X | RECORD | `apex`.`test` | PRIMARY | 3279 | 3 | 2 | 1 |+-----------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+2 rowsin set, 1 warning (0.00 sec)
查看当前连接id号（线程id号）
(root@localhost) [apex]> selectconnection_id();+-----------------+|connection_id() |+-----------------+| 5 |+-----------------+1 row inset (0.00 sec)
以上说的50秒，是系统参数innodb_lock_wait_timeout决定的
(root@localhost)[apex]> show variables like ‘innodb_lock_wait_timeout‘;+--------------------------+-------+|Variable_name | Value |+--------------------------+-------+| innodb_lock_wait_timeout| 50 |+--------------------------+-------+1 row inset (0.00 sec)3、mysql 如何查看未提交的事务
方法一：
(root@localhost)[performance_schema]> SELECT * FROMinformation_schema.INNODB_TRXG***************************1. row *************************** trx_id: 756996 trx_state: RUNNING trx_started: 2017-05-08 15:08:07 trx_requested_lock_id: NULL trx_wait_started: NULL trx_weight: 3 trx_mysql_thread_id: 4 trx_query: NULL trx_operation_state: NULL trx_tables_in_use: 0 trx_tables_locked: 1 trx_lock_structs: 2 trx_lock_memory_bytes: 1136 trx_rows_locked: 1 trx_rows_modified: 1 trx_concurrency_tickets: 0 trx_isolation_level: REPEATABLE READ trx_unique_checks: 1 trx_foreign_key_checks: 1trx_last_foreign_key_error:NULL trx_adaptive_hash_latched: 0 trx_adaptive_hash_timeout: 0 trx_is_read_only: 0trx_autocommit_non_locking:01 row inset (0.00 sec)
通过以上可看出线程id为4 一直未提交，事务开始的时间为2017-05-08 15:08:07。
方法二：通过 show engine innodb statusG
其中有一段关于事务的描述
TRANSACTIONS------------Trx idcounter 756998Purgedone for trx‘s n:o < 0 undo n:o < 0 state: running but idleHistorylist length 0LIST OFTRANSACTIONS FOR EACH SESSION:---TRANSACTION421519065333360, not started0 lockstruct(s), heap size 1136, 0 row lock(s)---TRANSACTION421519065332448, not started0 lockstruct(s), heap size 1136, 0 row lock(s)---TRANSACTION756996, ACTIVE 914 sec2 lockstruct(s), heap size 1136, 1 row lock(s), undo log entries 1MySQL thread id 4, OS thread handle 140041791522560, query id25 localhost root
从以上也可以看出线程id号为4的事务一直未提交。
4、如何解决未提交的事务方法一：如果能知道哪个用户在执行这个操作，让他提交一下（这种可能性很小）
方法二：kill掉这个线程id号，让事务回滚，
(root@localhost)[information_schema]> show processlist;+----+-----------------+------------------+--------------------+---------+------+------------------------+------------------+| Id |User | Host | db | Command | Time | State | Info |+----+-----------------+------------------+--------------------+---------+------+------------------------+------------------+| 1 | event_scheduler | localhost | NULL | Daemon | 4469 | Waiting on empty queue | NULL || 4 | root | localhost | apex | Sleep | 871| | NULL || 5 | root | localhost | apex | Sleep | 82| | NULL || 6 | root | localhost | information_schema | Query | 0| starting | showprocesslist || 7 | root | 192.168.1.1:3708 | NULL | Sleep | 3221 | | NULL |+----+-----------------+------------------+--------------------+---------+------+------------------------+------------------+5 rowsin set (0.00 sec) (root@localhost)[information_schema]> kill 4;QueryOK, 0 rows affected (0.01 sec)
本文出自 “corasql” 博客，请务必保留此出处http://corasql.blog.51cto.com/5908329/1923427
mysql事务未提交导致锁等待如何解决
标签：mysql q锁
小编还为您整理了以下内容，可能对您也有帮助：
mysql事务未commit
如果一个连接中开启事务且未显式提交或回滚，在不考虑其他因素的前提下，确实应该是只有在连接断开的时候才会回滚。
如果出现锁等待，则是根据innodb_rollback_on_timeout参数进行下一步动作，如果此参数是off，则会回滚上一条语句，不会提交或回滚，直到显式提交或回滚（事务一直存在，直到连接断开）。如果此参数是on，在超时后会回滚整个事务。
方法一：
通过以上可看出线程id为4一直未提交，事务开始的时间为2022-02-08 15:08:07。
方法二：通过 show engine innodb status
其中有一段关于事务的描述
从以上也可以看出线程id号为4的事务一直未提交。
方法一：如果能知道哪个用户在执行这个操作，让他提交一下（这种可能性很小）。
方法二：kill掉这个线程id号，让事务回滚。
mysql事务未commit
如果一个连接中开启事务且未显式提交或回滚，在不考虑其他因素的前提下，确实应该是只有在连接断开的时候才会回滚。
如果出现锁等待，则是根据innodb_rollback_on_timeout参数进行下一步动作，如果此参数是off，则会回滚上一条语句，不会提交或回滚，直到显式提交或回滚（事务一直存在，直到连接断开）。如果此参数是on，在超时后会回滚整个事务。
方法一：
通过以上可看出线程id为4一直未提交，事务开始的时间为2022-02-08 15:08:07。
方法二：通过 show engine innodb status
其中有一段关于事务的描述
从以上也可以看出线程id号为4的事务一直未提交。
方法一：如果能知道哪个用户在执行这个操作，让他提交一下（这种可能性很小）。
方法二：kill掉这个线程id号，让事务回滚。
MySQL数据库表被锁、解锁,删除事务
在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量操作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！
用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。
用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。
查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。
下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？
想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？
首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！
重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。
下面来看看不用跑路的解决方案：
遇到数据库阻塞问题，首先要查询一下表是否在使用。
如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。
如果查询结果不为空，比如出现如下结果：
则说明表（test）正在被使用，此时需要进一步排查。
查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。
执行命令：
该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。
在上述实践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法操作另外一个用户的线程。
如果情况紧急，此步骤可以跳过，主要用来查看核对：
如果情况紧急，此步骤可以跳过，主要用来查看核对：
看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。
搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。
执行kill命令：
对应的线程都执行完kill命令之后，后续事务便可正常处理。
针对紧急情况，通常也会直接操作第一、第二、第六步。
这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。
表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。
另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。
常见的一种锁表场景就是有事务操作处于：Waiting for table metadata lock状态。
MySQL在进行alter table等DDL操作时，有时会出现Waiting for table metadata lock的等待场景。
一旦alter table TableA的操作停滞在Waiting for table metadata lock状态，后续对该表的任何操作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。
通过show processlist可以看到表上有正在进行的操作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。
通过show processlist看不到表上有任何操作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。
处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。
通过show processlist看不到表上有任何操作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的操作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。
处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。
总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在操作之前要确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句。
如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。
关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。
MySQL数据库表被锁、解锁,删除事务
在程序员的职业生涯中，总会遇到数据库表被锁的情况，前些天就又撞见一次。由于业务突发需求，各个部门都在批量操作、导出数据，而数据库又未做读写分离，结果就是：数据库的某张表被锁了！
用户反馈系统部分功能无法使用，紧急排查，定位是数据库表被锁，然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程，建议点赞收藏，以备不时之需。
用户反馈某功能页面报502错误，于是第一时间看服务是否正常，数据库是否正常。在控制台看到数据库CPU飙升，堆积大量未提交事务，部分事务已经阻塞了很长时间，基本定位是数据库层出现问题了。
查看阻塞事务列表，发现其中有锁表现象，本想利用控制台直接结束掉阻塞的事务，但控制台账号权限有限，于是通过客户端登录对应账号将锁表事务kill掉，才避免了情况恶化。
下面就聊聊，如果当突然面对类似的情况，我们该如何紧急响应？
想象一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：原本运行正常的程序，某一天突然数据库的表被锁了，业务无法正常运转，那么我们该如何快速定位是哪个事务锁了表，如何结束对应的事物？
首先最简单粗暴的方式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于后果如何，你能不能跑了，要你自己三思而后行了！
重启是可以解决表被锁的问题的，但针对线上业务很显然不太具有可行性。
下面来看看不用跑路的解决方案：
遇到数据库阻塞问题，首先要查询一下表是否在使用。
如果查询结果为空，那么说明表没在使用，说明不是锁表的问题。
如果查询结果不为空，比如出现如下结果：
则说明表（test）正在被使用，此时需要进一步排查。
查看数据库当前的进程，看看是否有慢SQL或被阻塞的线程。
执行命令：
该命令只显示当前用户正在运行的线程，当然，如果是root用户是能看到所有的。
在上述实践中，阿里云控制台之所以能够查看到所有的线程，猜测应该使用的就是root用户，而笔者去kill的时候，无法kill掉，是因为登录的用户非root的数据库账号，无法操作另外一个用户的线程。
如果情况紧急，此步骤可以跳过，主要用来查看核对：
如果情况紧急，此步骤可以跳过，主要用来查看核对：
看事务表INNODB_TRX中是否有正在锁定的事务线程，看看ID是否在show processlist的sleep线程中。如果在，说明这个sleep的线程事务一直没有commit或者rollback，而是卡住了，需要手动kill掉。
搜索的结果中，如果在事务表发现了很多任务，最好都kill掉。
执行kill命令：
对应的线程都执行完kill命令之后，后续事务便可正常处理。
针对紧急情况，通常也会直接操作第一、第二、第六步。
这里再补充一些MySQL锁相关的知识点：数据库锁设计的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则，而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。MySQL中表级别的锁有两种：一种是表锁，一种是元数据锁（metadata lock，MDL)。
表锁是在Server层实现的，ALTER TABLE之类的语句会使用表锁，忽略存储引擎的锁机制。表锁通过lock tables… read/write来实现，而对于InnoDB来说，一般会采用行级锁。毕竟锁住整张表影响范围太大了。
另外一个表级锁是MDL（metadata lock），用于并发情况下维护数据的一致性，保证读写的正确性，不需要显式的使用，在访问一张表时会被自动加上。
常见的一种锁表场景就是有事务操作处于：Waiting for table metadata lock状态。
MySQL在进行alter table等DDL操作时，有时会出现Waiting for table metadata lock的等待场景。
一旦alter table TableA的操作停滞在Waiting for table metadata lock状态，后续对该表的任何操作（包括读）都无法进行，因为它们也会在Opening tables的阶段进入到Waiting for table metadata lock的锁等待队列。如果核心表出现了锁等待队列，就会造成灾难性的后果。
通过show processlist可以看到表上有正在进行的操作（包括读），此时alter table语句无法获取到metadata 独占锁，会进行等待。
通过show processlist看不到表上有任何操作，但实际上存在有未提交的事务，可以在information_schema.innodb_trx中查看到。在事务没有完成之前，表上的锁不会释放，alter table同样获取不到metadata的独占锁。
处理方法：通过 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然后kill掉，让其回滚。
通过show processlist看不到表上有任何操作，在information_schema.innodb_trx中也没有任何进行中的事务。很可能是因为在一个显式的事务中，对表进行了一个失败的操作（比如查询了一个不存在的字段），这时事务没有开始，但是失败语句获取到的锁依然有效，没有释放。从performance_schema.events_statements_current表中可以查到失败的语句。
处理方法：通过performance_schema.events_statements_current找到其sid，kill 掉该session，也可以kill掉DDL所在的session。
总之，alter table的语句是很危险的（核心是未提交事务或者长事务导致的），在操作之前要确认对要操作的表没有任何进行中的操作、没有未提交事务、也没有显式事务中的报错语句。
如果有alter table的维护任务，在无人监管的时候运行，最好通过lock_wait_timeout设置好超时时间，避免长时间的metedata锁等待。
关于MySQL的锁表其实还有很多其他场景，我们在实践的过程中尽量避免锁表情况的发生，当然这需要一定经验的支撑。但更重要的是，如果发现锁表我们要能够快速的响应，快速的解决问题，避免影响正常业务，避免情况进一步恶化。所以，本文中的解决思路大家一定要收藏或记忆一下，做到有备无患，避免突然状况下抓瞎。
mysql数据库表锁等待超时怎么解决
mysql数据库死锁解决方法如下：
1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在系统中实现，来自外部系统的用户更新操作不受系统的控制，因此可能会造 成脏数据被更新到数据库中。
3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统， 当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。
mysql数据库表锁等待超时怎么解决
mysql数据库死锁解决方法如下：
1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在系统中实现，来自外部系统的用户更新操作不受系统的控制，因此可能会造 成脏数据被更新到数据库中。
3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统， 当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。
win7系统打开MySQL报错Lock wait timeout exceeded如何解决
最近有用户到本站反馈说碰到这样一个问题，就是在打开MySQL的时候，报错Lock wait timeout exceeded，导致无法打开MySQL，该怎么解决呢，为此小编这就给大家讲解一下win7系统打开MySQL报错Lock wait timeout exceeded的具体解决方法。
1、登录到mysql后，输入命令：show processlist；
查看当前会话列表，左边红框是会话执行的命令，右边红框是会话的时间。通常会话时间太长的多半是因为锁等待活死锁造成的，但也不排除一些慢查询。
我们删除那些时间过长的会话。
2、输入命令：kill 1110；
删除会话列表中等待时间最长的会话
3、依次删除其他等待时间过长的会话。
服务器大量锁等待如何解决
前段时间遇到线上报大量的锁等待的错误
如下图
首先需要说明一下锁等待错误是怎么产生的.官方的错误编码表有这个的相关解释
工欲善其事必先利其器.你得有好的工具帮助到你.由于种种原因,线上的监控不是那么完备,导致报错解决起来比较困难.所以自己有几件趁手的工具就很重要了.这里便说一下我这次解决问题用到的.
1.查询锁等待的语句,
具体字段解释百度
2.本地开发环境配置显示执行sql
这样你可以看到一个接口执行了哪些sql方便你去快速查看原因
3.本地mysql服务端配置显示执行sql
可以参考这位大佬的配置
如何配置mysql 执行log
4.修改超时等待的值,就是 去设置 innodb_lock_wait_timeout这个变量的值,设置的短一点就会更容易复现.因为线上的是会产生大量事务的,而你本地服务器没有线上那种很忙的情况,可以压测本地的mysql,也可以通过设置更短的时间来快速报错.
5.本地最好把日志级别调低,方便看到更详细的错误
其实自己解决也花了不少时间,有些事情还是想的太过于深入最后发现对自己解决问题没什么用,应该也给自己设置一个思考超时时间和行动超时时间,比如都设置半个小时,如果没有任何进展要么去尝试其他的,要么去短暂的休息一下,说不定你会产生更好的思路.