TiDB 是否支持 select for update？

支持，但语义上和 MySQL 有区别，TiDB 是分布式数据库，采用的乐观锁机制，也就说 select for update 不在事务开启就锁住数据，而是其他事务在提交的时候进行冲突检查，如有冲突，会进行回滚。

TiDB 采用了乐观锁机制，在事务的并发处理中，TiDB 会自动重试提 交时遇到冲突而发生退避的事务；而在使用了 select for update 或关闭 tidb_disable_txn_auto_retry 变量时，这种退避机制会失效，后提交的事务会被回滚。 select for update 被使用于计数器，秒杀，公用账户、理财产品、国债的余额扣减等场 景，技术特点是并发的对同一行数据进行修改。传统的单机 DBMS 多使用悲观锁来实现 select for update，在事务开始的时候即进行锁检查，如果事务所需要的锁和数据上当前的锁不 兼容，就会发生锁等待，等当前的锁释放后本事务才能执行。TiDB 在执行 select for update 时 相当于悲观锁系统中将锁等待时间设置为 0，遇到锁冲突的事务会执行失败。 综上，TiDB 不适合用于处理高并发的对同一行数据进行修改，事务使用了 select for update 语句，可以保证数据的一致性，但并发执行的事务中，只有最先提交的事务会成功，其 余的并发请求都会被回滚。 处理计数器场景的最佳实践是将计数器功能转移到缓存（redis，codis 等）中实现，如 购买国债产品场景中，将国债余额读取到缓存中，在缓存中根据余额与购买额度对请求队列进 行控制，向合格的请求发放访问数据库的令牌，向购买额度超过余额的请求返回余额不足的错 误，拿到令牌的请求可以并发去修改数据库中的产品余额。 在应用了悲观锁的 DBMS 中，并发的 select for update 事务实际上是被排成队列以串行 的方式执行的，因此性能不高，而使用缓存来处理计数器场景也有着较大的性能优势。