1樓：Ethan
確實提了乙個好問題，加鎖的範圍確實有問題，可以將 MySQL 的版本更新到 8.0.19 之後版本，有同學說目前已經 Fix 了該問題。
就我個人而言，在分析 MySQL 加鎖範圍時，確實容易出現各種令人無法理解的情況出現。
就先拿你舉得第二個例子來說：
begin;
select * from t where c <= 15 for update;
我這裡是 5.7.29 ，對應的加鎖範圍和你還不一致：
TABLE LOCK table `my_test`.`t` trx id 1339989 lock mode IX
RECORD LOCKS space id 251 page no 3 n bits 80 index PRIMARY of table `my_test`.`t` trx id 1339989 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000000; asc ;;
1: len 6; hex 0000001471d7; asc q ;;
2: len 7; hex c2000001620110; asc b ;;
3: len 4; hex 80000000; asc ;;
4: len 4; hex 80000000; asc ;;
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000005; asc ;;
1: len 6; hex 0000001471d7; asc q ;;
2: len 7; hex c200000162011d; asc b ;;
3: len 4; hex 80000005; asc ;;
4: len 4; hex 80000005; asc ;;
Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 8000000a; asc ;;
1: len 6; hex 0000001471d7; asc q ;;
2: len 7; hex c200000162012a; asc b *;;
3: len 4; hex 8000000a; asc ;;
4: len 4; hex 8000000a; asc ;;
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 8000000f; asc ;;
1: len 6; hex 0000001471fa; asc q ;;
2: len 7; hex 5e00000a812aff; asc3: len 4; hex 8000000f; asc ;;
4: len 4; hex 8000000f; asc ;;
Record lock, heap no 6 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000014; asc ;;
1: len 6; hex 0000001471d7; asc q ;;
2: len 7; hex c2000001620144; asc b D;;
3: len 4; hex 80000014; asc ;;
4: len 4; hex 80000014; asc ;;
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000019; asc ;;
1: len 6; hex 0000001471f6; asc q ;;
2: len 7; hex 5c00000a9b263b; asc \ &;;;
3: len 4; hex 80000019; asc ;;
4: len 4; hex 80000019; asc ;;
可以看到，這裡加的鎖範圍是 (-無窮，25] 的 next-key lock. 這就意味著在 c 索引上，遍歷到 25 才停下來。這時更新 c=25 都不行。
如果真的想要理解為什麼，確實需要扒一下原始碼，查一下遍歷的原則，按照正常的思路無法理解很正常。
想想在工作中，為了一些特殊的業務，加上一些不合理的邏輯是很正常的。
就目前情況來說，遇到這種不能理解的問題，先查查日誌，定位出問題，FIX 掉就可以。如果真的是 bug，後面會修正的。
mysql的MEMORY引擎為什麼應用沒有redis的應用廣泛？
Abby Chau 我自己寫的論壇中的online 表就是用memory 引擎的。作為kv 查詢是夠用了，但有乙個很嚴重的limit，就是表總容量很小。不像redis 和memcache 那樣可以一直新增。同一時間我也有redis 去處理更加煩心的快取問題。 eechen MySQL的記憶體表 me...
IEEE754中真正的指數值e範圍為什麼是 126 127？
Ehco 在IEEE754標準中進行了單精度浮點數 float 和雙精度數浮點數 double 的定義。float有32bit，double有64bit。它們的構成包括符號位 指數字和尾數字。這些位的構成如下 種類 符號位 指數字 尾數字 float 第31位 佔1bit 第30 23位 佔8bit...
為什麼mysql的redo日誌不直接記錄sql語句
零五 題主所說的日誌是binlog，而不是redo log，因為binlog是二進位制形式的，所以你不能直觀地看到insert，alter之類的語句。redolog和undolog是對資料庫事務的日誌，它們的物件是資料，而不是操作日誌。innodb引擎下，對資料的修改的步驟是這樣 1 將操作記錄 完...