READ COMMITTED跟REPEATABLE READ是不是就这点差别？还有一个锁的问题…

看完文档，我觉得是不是就是READ COMMITTED在SELECT FOR UPDATE和lock in share mode的时候会对所有情况进行索引的行锁定，而REPEATABLE READ只在查询条件中有索引的时候才进行索引行锁定（SELECT FOR UPDATE和lock in share mode）？还有，这个锁是什么时候加的啊？在事务中一运行update和select语句就加锁，一直加到事务提交？还是只在update的时候加，然后运行完这句就释放？还是全在commit的时候一块加啊？还有一个小问题，删除表的时候，所有在表上的触发器也会被删掉吧？

解决方案 »

  1.   

    在5.1。31下测试，删除表会删除 TRIGGER
      

  2.   


    哦，是删掉的，只是mysqldump的文件里有trigger，恢复的时候把trigger给恢复了，我还以为没删掉呢……
      

  3.   

    默认情况下(autocommit=1)应该都是:只在update的时候加，然后运行完这句就释放;
    READ COMMITTED 级别,在没有利用索引的情况下也会出现锁表.
      

  4.   

    1 READ COMMITTED别的事物在未提交事务前，别的事务时不能访问这个事务
    REPEATABLE READ是在读事务提交前，别的事务可以更改数据，但不可以插入数据
    2 一个事务一旦开始就加锁，提交后释放锁
      

  5.   

    事务中一运行update和select.. for update语句就加锁，一直加到事务提交
      

  6.   

    那普通的SELECT是会放个共享锁上去直到事务结束吗？
      

  7.   


    在AUTO_COMMIT=ON的情况下，任何一条语句都默然是一个事务。
      

  8.   


    那AUTO_COMMIT=off的时候呢？这个锁是怎么加的？
      

  9.   

    AUTO_COMMIT=off 的时候，你可以自己控制事务的进程，如COMMIT或者ROLLBACK。事务提交或回滚，都会释放锁。锁什么时候加上，视情况而定。
      

  10.   

    恩，那没有for update和in share lock mode的select也会加锁直到事务结束吗？
      

  11.   

    就想问问这个SELECT是个怎么的锁表方式……
      

  12.   

    那没有for update和in share lock mode的select也会加锁直到事务结束吗？没有这2个,纯粹的select是不会影响到其他session的,只放一个共享锁.
      

  13.   


    SELECT 加的是共享锁，别的SESSION可以在上面再加排他锁。
    你问的锁表的方式，这个论题范围太广泛了，涉及到很多的知识点。。