具體情況
引擎 innodb
長查詢日志
# Query_time: 2.582698 Lock_time: 0.000039 Rows_sent: 0 Rows_examined: 1
16871 SET timestamp=1509850570;
16872 update `u_user` set `bonus_stone` = 19 , `bonus_point` = 371 where `id` = 7609;
# Query_time: 2.016371 Lock_time: 0.000039 Rows_sent: 0 Rows_examined: 1
16876 SET timestamp=1509850585;
16877 update `u_user` set `bonus_stone` = 20 , `bonus_point` = 391 where `id` = 7609;
業務，用戶在答題的時候會頻發更新用戶表的經驗和石頭數量。
用戶表一定時期會有很多update的操作
業務處理的邏輯是
先用id查詢出某一條資料，再根據主鍵更新
uj5u.com熱心網友回復：
通常是并發導致的等待uj5u.com熱心網友回復：
更新的時候遇到鎖等待？可以在程式端 一定時期合并這些操作 再提交到資料庫
uj5u.com熱心網友回復：
其實update 陳述句的瓶頸還是要看where條件后的陳述句，個人微信公眾號《andyqian》上，最近更新了一系列MySQL文章，歡迎來撩uj5u.com熱心網友回復：
update陳述句有沒有做全域掃掃碼？該加的索引加了沒有？索引有效沒有？資料量本身是不是很多很多？分庫分表？轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/105110.html
標籤：MySQL