.jpg)
避免全表掃描、控制事務(wù)粒度、合理使用索引是提升mysql更新性能的核心做法。1. 合理使用索引，避免全表掃描，where條件中使用的字段應(yīng)盡量加索引，避免使用函數(shù)或表達(dá)式導(dǎo)致索引失效，并通過explain檢查執(zhí)行計(jì)劃；2. 控制事務(wù)大小，減少鎖持有時間，將大事務(wù)拆分為小事務(wù)處理，顯式控制事務(wù)邊界，避免非數(shù)據(jù)庫操作占用事務(wù)時間；3. 批量更新優(yōu)于單條更新，可通過in或case when實(shí)現(xiàn)一次更新多條記錄，減少網(wǎng)絡(luò)開銷和鎖競爭；4. 注意隱式類型轉(zhuǎn)換和字符集問題，確保參數(shù)與字段類型匹配，保持字符集一致，優(yōu)先用數(shù)值代替字符串存儲枚舉值。
mysql優(yōu)化更新性能，關(guān)鍵在于減少鎖競爭、提升IO效率以及合理使用索引。直接說重點(diǎn)：避免全表掃描、控制事務(wù)粒度、適當(dāng)添加索引但不過度使用，是提升更新性能的核心做法。
1. 合理使用索引，避免全表掃描
更新操作如果命中索引，就能快速定位到目標(biāo)數(shù)據(jù)行，否則就會觸發(fā)全表掃描，嚴(yán)重影響性能。特別是當(dāng)表數(shù)據(jù)量大時，這種影響會非常顯著。
建議：
- 在WHERE條件中使用的字段盡量加上合適的索引。
- 避免在WHERE中使用函數(shù)或表達(dá)式，這樣會導(dǎo)致索引失效。
- 使用EXPLaiN語句檢查執(zhí)行計(jì)劃，確認(rèn)是否走到了正確的索引。
例如：
UPDATE users SET status = 1 WHERE id = 100;
如果id字段有主鍵索引，這個更新很快；但如果改成：
UPDATE users SET status = 1 WHERE YEAR(create_time) = 2023;
create_time即使有索引也可能不會被使用，導(dǎo)致大量掃描。
2. 控制事務(wù)大小，減少鎖持有時間
更新操作通常涉及行鎖或表鎖（InnoDB是行鎖），事務(wù)越長，鎖的持有時間就越久，容易造成并發(fā)阻塞。
建議：
- 盡量把一次批量更新拆成多個小事務(wù)，而不是一個大事務(wù)。
- 不要在事務(wù)中做太多非數(shù)據(jù)庫操作（比如復(fù)雜計(jì)算、網(wǎng)絡(luò)請求等）。
- 使用BEGIN; … COMMIT;顯式控制事務(wù)邊界。
舉個例子，如果你要更新幾萬條記錄，可以分頁處理：
UPDATE users SET status = 1 WHERE status = 0 LIMIT 1000;
每次更新1000條，循環(huán)執(zhí)行直到全部完成，這樣能有效釋放鎖資源。
3. 批量更新優(yōu)于多次單條更新
頻繁發(fā)起單條更新語句，不僅增加了網(wǎng)絡(luò)往返開銷，也更容易引起鎖競爭和事務(wù)日志壓力。
建議：
- 能合并就合并，比如用IN或者CASE WHEN實(shí)現(xiàn)一次更新多條記錄。
- 如果業(yè)務(wù)允許，可以將多個更新操作合并為一條sql語句。
示例：
UPDATE users SET status = CASE id WHEN 1 THEN 2 WHEN 2 THEN 3 WHEN 3 THEN 1 END WHERE id IN (1, 2, 3);
這種方式比三次獨(dú)立的UPDATE語句更高效。
4. 注意隱式類型轉(zhuǎn)換和字符集問題
有時候看似簡單的更新語句，因?yàn)樽侄晤愋筒黄ヅ浠蜃址灰恢拢矔?dǎo)致索引失效甚至報(bào)錯。
常見現(xiàn)象：
- 字段是VARCHAR類型，卻傳入int值進(jìn)行比較，可能導(dǎo)致索引失效。
- 查詢條件中的字符串編碼與字段字符集不一致，也可能引發(fā)性能問題。
建議：
- 確保查詢參數(shù)與字段類型嚴(yán)格匹配。
- 檢查表和字段的字符集設(shè)置，保持統(tǒng)一。
- 對于枚舉類字段，優(yōu)先使用數(shù)值代替字符串存儲。
基本上就這些。MySQL的更新優(yōu)化其實(shí)不難，但細(xì)節(jié)很多，尤其在高并發(fā)場景下，一個小疏忽可能就會拖垮整個系統(tǒng)。
.png)
