问些事务和锁定的一些常识

事务 锁定事务mysql锁定断电

解决方案 »

  1.   

    还是过一段时间，mysql会自动回滚A创建的事务？有没什么地方可以设置这个一段时间的长度？有一个connection time out 的参数。
      

  2.   

    只有一个参数可控制
    wait - timeout ：线程没活动的最大秒数。
     默认是28800秒， 即8小时后，这个没有客户端活动的线程会被服务器杀死。8小时太长了， 但你也不能将wait -timeout 设为太小，否则会误杀很多空闲正常的线程最好的方法是手动杀死那个线程。“A重启后，该如何建立连接才能继续原来的事务？”--不行的。
      

  3.   

    我试验了，A连接mysql并且for update后，拔掉网线。B再连接mysql对T1执行for update，将是卡住的，直到wait - timeout。
    wait - timeout并不表示B执行成功了，而是表示执行失败。
    此后无论谁，包括A自己，如果对T1执行for update都将是以失败(wait - timeout)告终的。也就是说记录被永远锁定了。。
    话说此时我该如何手动解锁？
      

  4.   

    锁，是建立在会话的基础上的，会话没有了，锁自然也就没有了。会话S1 ，锁定了表 TA ，又写数据又删除数据，但是没有提交，断电了。来电重启服务器和数据库服务，会自动回滚这些操作，就当什么也没发生过一样。
      

  5.   

    show processlist
    kill xxx
      

  6.   

    show processlist
    kill xxx

    Good，要的就是这个。美中不足的是，无法发现哪个线程是有没结束的事务的，都是显示Sleep。
    你有什么好办法没？
      

  7.   

    最不科学的是，我拔网线，关闭有事务的SQL管理工具，再接网线，再用另一个SQL管理工具查询。
    这时有事务的那个线程的连接应该已经断开了才对，这么严重的状态，show processlist却貌似对此一无所知。
      

  8.   

    拔掉网线,    运行在TCP/IP应用层的mysql检测不到这个链路层的故障, 它还以为这个线程正sleep状态， 最坏的情况的是在事务过程中断开。 所以为了避免这个原因导致程序并发故障， 一个事务持续尽可能短的时间，最好把事务放在存储过程中。确实有这问题,  我平常是看IP地址猜测的.  
      

  9.   

    应该不是 connect_timeout 吧 , 应该是这两个参数
    innodb_lock_wait_timeout 等待多长时间判定为死锁 以及
    innodb_rollback_on_timeout 在超时 ( 判定为死锁 ) 后是否回滚事务 
    connect_timeout 是一段时间没有动作后 , mysql 会自动断开连接 , 这个 ... 百度一下 , 不一定准