With spring's transaction made a simple practice high concurrency grab a red envelope, mysql5.7, rc isolation level,
Transaction process: how much is left query red envelope didn't rob - & gt; Have the rest of the insert a grab a red envelope record and update the remaining red envelopes, involves the two tables, a red table and a grab a red envelope form, red table is a record, the red envelope into 20000 shares of 200000,

 
/* red table records, the primary key id used AutoIncrease automatically generated */
Insert into concurrenttest. Red_packet (user_id, amount, send_date, total, unit_amount, stock, note) 
Values (3, 200000.00, now (), 20000, 10.00, 20000, "2 w $10 little red packets, a total of two hundred thousand"); 
/* grab bag records omitted, a convenient statistical package time elapsed time */

And then use javascript to write a 30000 times the cycle of asynchronous request grab a red envelope,
The problem is that I have used two SQL statements: do not add the for - update (no lock control) and the for - the update test respectively, the material (16 years published when mysql5.7) said add the for - the update after the lock won't appear concurrency issues, but took almost than before (more than 30 seconds) twice as much (more than 50 seconds), but when I actually run is added for - update (8 to 10 seconds) than in those without locking (10 minute 30 seconds) a little faster, run a few times is such, want to ask why is this?

CodePudding user response:

Add for update of execution is the current read, can directly read the result, don't lock is consistency of transaction read and if there are other threads between open transaction and read data to the data of concurrent operation, will lead to need to perform the undo log, so there will be a longer time,

CodePudding user response:

reference 1st floor jslqa67 response:

add for update of execution is the current read, can directly read the result, don't lock is read consistency of the transaction, if there are other threads between open transaction and read data to the data of concurrent operation, cause need to perform the undo log, so there will be a longer time,

So, I feel that I can explain a sense,
He quickly because machine performance is good, fast executing a transaction, undo - log was low; So hung thread overhead is much bigger than undo - log costs; My performance is poor, lead to a lot of transactions performed together undo - log particularly big, so with the current reading to avoid undo - instead, log a little faster,