我们可以创建一张表，表中每条记录代表一个共享资源的锁，其中有个status字段代表锁的状态，L代表锁已经被获取Locked，U代表锁未被获取Unlocked。
假设现在有一个线程要更新商品库存，它会先根据商品id找到代表该共享资源的锁，然后执行如下语句：
update T t set t.status = 'L' where t.resource_id = '123456' and t.owner = 'new owner' and t.status = 'U';
-
如果这条语句执行成功，代表获取到了锁，然后就可以进行扣减库存的操作，释放锁时，将U改为L即可。
-
如果这条语句执行不成功，代表锁已经被别人获取了。
那么此时该线程只能等待，但如何等待呢？数据库和我们的应用程序之间，除了发出执行语句和返回结果，基本就没有其他交互了，它很难给应用程序发出通知，这样就很难做到通过事件监听机制来获取到释放锁的事件，所以程序只能轮询地去尝试获取锁。
这种类似自旋锁的阻塞方式，对数据库资源消耗极大，原本数据库的性能相对较差，即便加上连接池，性能也远无法跟一些缓存中间件相比，而现在程序为了抢锁拼命发出update语句，对数据库性能来说更是雪上加霜，而在分布式环境中，尤其需要使用分布式锁的场景，基本上都是要求支持高并发的，这就出现一个悖论了，这一点基本上也宣告了数据库在大部分需要分布式锁的场景中都用不上。
