同一用户并发读取同一条数据，不会出现什么问题，因为读取不会修改数据，但是如果某个用户正在读取某张表，而同一时刻另一用户正在修改这张表的id为1的数据，会产生什么后果？
答案是不确定的，读的用户可能会报错退出，也可能读到不一致的数据。
解决这类经典问题的就是并发控制。在处理并发读写的时候，可以通过实现一个由两种类型的锁组成锁系统来解决问题。这两种锁就是读锁(共享锁)和写锁(排他锁)。
读锁（共享锁）是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。
写锁（排他锁）如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。
事务可以通过以下语句给sql加共享锁和排他锁：
共享锁：select …… lock in share mode;
排他锁：select …… for update;
共享锁：
排它锁：
读锁和写锁都是行级锁，InnoDB的行锁是通过给索引上的索引项加锁来实现的，如果没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁，InnoDB行锁分为3中情形：
1. Record Lock：对索引项加锁。
2. Gap Lock：对索引项之间的“间隙”、第一条记录前的“间隙”或最后一条记录后的“间隙”加锁。
3. Next-key Lock：前两种的结合，对记录及其前面的间隙加锁。
InnoDB这种行锁的实现特点意味着，如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟锁表一样。
---------------------
原文：https://blog.csdn.net/u014316026/article/details/78726459
悲观锁的业务流程（以商品表和SKU表减库存并进行其它操作为类）：
---事务开始
1，查询商品表、锁定表：for update
2，判断商品库存是否大于购买数据，
3，如果库存满足，减少商品表库存。（不满足就回滚事务了。）
4，减少商品SKU表库存
5，记录订单操作记录等
--事务提交（事务提交时即释放锁）。
可见上面的流程中整个被锁的周期是比较长的。如果改为乐观锁呢：
----事务开始
1，查询商品表
2，判断商品库存是否大于购买数据，
3，如果库存满足，减少商品表库存（条件是商品表的库存=1中查询出的库存）
比如：update product set store = store - {$count} where store = {$product->store} ($product->store为1查询得到的库存)
4，减少商品SKU表库存（同样需要判断条件）
5，记录订单操作记录等
--事务提交（事务提交时即释放锁）。
可以看到乐观锁整个过程中实际并未执行任何加锁，我也不知道为什么会有这样的称呼。实际它是一种判断冲突的有效手段。
在上面的乐观锁的执行流程中，如果3、4、5这三步中的任何一步发生异常，都会因滚事务。这样就不会出现减库存冲突导致库存脏数据了。
-------------------------------------------------------------
在使用乐观锁时，要考虑进一步，就是在乐观锁时如果发现数据被修改，更新失败时，要考虑再重新获取数据，重新判断重新更新。这样就不会因为更新失败导致此笔业务失败，而相当于把它立即加进到下一步的队列而在同步请求中即能得到解决。
两种锁各有各的好，建议电商网站起步时访问量不大，不会造成压力时使用悲观锁。因为这时没有什么高并发，但也要好好检查代码防止出现死锁。
对于成熟的电商网站，必须面对高并发的情况下，应该使用乐观锁。
参考：https://blog.csdn.net/resilient/article/details/81412145
更详细的参考
浅谈Mysql共享锁、排他锁、悲观锁、乐观锁及其使用场景https://blog.csdn.net/localhost01/article/details/78720727