A question has been puzzling for a long time, about the design of MySQL table

I now have a business need, is the account balance problem, how to design This account balance of the table?
Simple update updates the balance is obviously not working.
If the user on the PC side, the mobile operation balance, it is very likely that an error occurred
Do you have to use business?

Reply content:

I now have a business need, is the account balance problem, how to design This account balance of the table?
Simple update updates the balance is obviously not working.
If the user on the PC side, the mobile operation balance, it is very likely that an error occurred
Do you have to use business?

Transactions are not required, but transactions are the simplest, clearest, and most convenient way to implement them. You can use some other state transitions to achieve the correctness of the balance operation, but the whole state transition is quite complicated and troublesome, and even if you get out of the state conversion process, you are actually doing a transaction system.

This has nothing to do with business, you should be talking about locks. In fact
There is only one problem you need to solve: synchronous security, Solution two:

1. Using the locks provided by the database
After each operation of the balance to lock the balance (row lock, for update), and then you can operate at will, remember to commit the last transaction (will automatically release the lock, note that MySQL does not turn on autocommit transactions)

2. The application provides its own lock
If the operation of the balance is on the same interface as the PC or the mobile, the request for the balance operation is locked by using a separate lock (one lock per user) directly in the interface.
If it is not the same interface, then you need a distributed lock, Redis has a solution to provide a distributed lock, you can refer to the Redis official scheme: Build a distributed lock with Redis

