在开发电商系统时，你可能遇到过这样的场景：两个用户同时抢购最后一件商品，结果库存被扣成负数。这种并发问题，靠简单的代码逻辑很难解决，得靠数据库的锁机制来控制。常见的就是乐观锁和悲观锁，名字听起来有点玄，其实原理并不复杂。
悲观锁：先占住再说
悲观锁就像一个谨慎的人，总觉得别人随时会来改数据，所以一上来就先把数据锁住，不让别人碰。在数据库里，通常是用 SELECT ... FOR UPDATE 实现的。比如你要修改订单状态，先锁住这条记录，处理完再提交事务，期间别人想动这条数据，就得等着。
START TRANSACTION;
<-- 查询并加锁 -->
SELECT * FROM orders WHERE id = 1001 FOR UPDATE;
<-- 更新操作 -->
UPDATE orders SET status = 'paid' WHERE id = 1001;
COMMIT;这种方式简单直接，但代价也明显：如果锁的时间长，或者并发量大，很多人就得排队等，系统响应就慢了。就像食堂打饭，一个人端着盘子不走，后面的人只能干等。
乐观锁：相信不会撞车
乐观锁则相反，它假设大多数时候大家不会冲突，所以不加锁，只在更新的时候检查一下数据有没有被别人改过。通常做法是在表里加个版本号字段（version），每次更新时判断版本是否匹配。
UPDATE products SET stock = stock - 1, version = version + 1
WHERE id = 1002 AND version = 3;如果更新影响的行数是0，说明版本对不上，数据已经被别人改了，这时候可以重试或提示用户。这种方式不阻塞别人，适合读多写少的场景，比如文章浏览、商品详情页，大家看看没关系，真要下单才去校验。
怎么选？看场景
如果你的系统写操作频繁，冲突概率高，比如金融交易、库存扣减，悲观锁更稳妥，虽然慢点，但不容易出错。如果是社交平台、内容管理系统，大部分是查看和点赞，偶尔编辑，用乐观锁更高效，用户体验也更好。
举个例子：两个人同时编辑一篇文档，乐观锁的做法是允许各自编辑，保存时提示“内容已变更，请确认合并”；而悲观锁则是谁先打开谁锁住，别人连编辑按钮都点不了。哪种好？取决于你们是不是经常同时改同一个文件。