InnoDB事务会阻塞读取或影响ORDER BY排序吗？

嘿，我来帮你理清楚这个问题——核心其实取决于数据库的隔离级别，以及你执行的是哪种读取操作，咱们拆开来聊：

一、更新时该行能否被读取？会不会阻塞？ #

这个问题的答案直接和数据库隔离级别以及读取类型绑定：

• 读未提交（READ UNCOMMITTED）：这种级别下，读取操作完全不会被阻塞，能直接读到事务未提交的更新值，但这会带来脏数据问题，一般生产环境不会用。
• 读已提交（READ COMMITTED，多数数据库默认）：普通的SELECT是快照读（比如MySQL InnoDB用多版本并发控制MVCC），读取的是该行更新前的快照数据，完全不会被更新事务阻塞。只有当你用SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE这种当前读时，才会因为更新事务持有该行的排他锁而被阻塞，直到更新事务提交或回滚。
• 可重复读（REPEATABLE READ）：和读已提交类似，普通读取都是快照读，而且整个事务周期内会一直读取事务开始时的快照版本，不管其他事务怎么更新，都不会被阻塞，也不会读到新值，直到自己的事务结束。
• 串行化（SERIALIZABLE）：这是最严格的级别，普通读取也会加共享锁，如果更新事务已经给该行加了排他锁，读取操作就会被阻塞，必须等更新事务完成才能继续。

二、更新索引列对ORDER BY查询的影响？ #

当你更新索引列的值时，数据库需要维护索引：删除旧的索引条目，插入新的条目。这时候分两种情况：

• 普通快照读的ORDER BY：因为读的是更新前的快照数据，ORDER BY会基于旧的索引值排序，完全不受更新事务的影响，既不会阻塞，也不会读到未提交的新值。
• 当前读的ORDER BY：如果你的查询用了FOR UPDATE这类锁读，并且ORDER BY依赖这个索引，数据库可能会在索引的相关范围加锁。如果更新事务已经持有该行的排他锁，这个锁读查询就会被阻塞。另外，有些数据库（比如InnoDB）在更新索引列时，会对旧的索引记录加排他锁，要是有其他查询在扫描索引的这个范围，也可能触发锁等待，但普通快照读完全不受影响。

举个实际的例子：假设你用MySQL InnoDB，默认读已提交隔离级别，你开一个事务更新某行的索引列和其他字段，同时另一个会话执行SELECT * FROM table ORDER BY index_col，这个SELECT会直接返回更新前的数据，完全不会等更新事务完成，也不会有阻塞。

内容的提问来源于stack exchange，提问作者James Smith