到批量更新與踩坑指南)
在 .NET 服務(wù)端開發(fā)里ORM 框架的選擇一直是個(gè)熱鬧話題。從 EF Core 到 Dapper 再到 SqlSugar每家都有自己的忠實(shí)用戶。SqlSugar 能在大量老項(xiàng)目和中小團(tuán)隊(duì)里扎根不是靠概念包裝而是靠那套貼合業(yè)務(wù)直覺的更新語法——尤其 Update 系列寫法簡單、直接、一眼看懂又能覆蓋絕大多數(shù)更新場景。如果你正在用 .NET 寫增刪改查或者正從別的 ORM 遷到 SqlSugar這篇把 Update 的常用語法、參數(shù)含義和踩坑點(diǎn)全部理一遍可以直接當(dāng)字典查。我最早接觸 SqlSugar 是做幾個(gè)運(yùn)營后臺系統(tǒng)剛開始天天手拼 SQL一個(gè)“改用戶資料”的需求寫了快兩百行條件分支后來換成db.Updateable(...)之后代碼量至少減了一半。這篇文章把這些年用過的 update 場景整理成合集不保證覆蓋所有偏門 API但日常開發(fā)里你能遇到的更新需求基本都能從這里面找到對應(yīng)的姿勢。老手可以直接跳到第三章新手建議從頭看因?yàn)樵角懊娴闹R點(diǎn)越容易被忽略而忽略的代價(jià)往往是線上數(shù)據(jù)被批量改壞。1. 先把 Update 語法的全局邏輯講清楚1.1 為什么 SqlSugar 值得單獨(dú)整理一份更新合集很多開發(fā)會覺得ORM 不都是根據(jù)實(shí)體生成 SQL 嗎Update 有什么好講的實(shí)際上更新操作和 Insert、Select 有本質(zhì)區(qū)別插入關(guān)心“插哪些字段”查詢關(guān)心“篩哪些條件”而更新必須同時(shí)處理好“賦值”和“條件”兩層邏輯。條件寫寬了整張表被改賦值列寫多了無關(guān)字段被覆蓋。這兩個(gè)問題在業(yè)務(wù)代碼里一旦出現(xiàn)往往是事故級別。SqlSugar 的UpdateableAPI 恰恰就是圍繞這兩層邏輯設(shè)計(jì)的。它的鏈?zhǔn)椒椒ò迅虏鸪扇龎K表是誰、要給哪些列賦值、在什么條件下生效。理解了這套模型之后你不需要去背每個(gè)方法的簽名而是自然知道去哪里查賦值相關(guān)的方法叫SetColumns或UpdateColumns條件相關(guān)的方法叫Where或WhereColumns執(zhí)行方法只有一個(gè)叫ExecuteCommand。這套設(shè)計(jì)還有一個(gè)好處是貼近業(yè)務(wù)表達(dá)。我經(jīng)常給團(tuán)隊(duì)里不太熟悉 SQL 的初級開發(fā)看代碼他們讀SetColumns(it it.Name 張三)的時(shí)候第一反應(yīng)是“這是個(gè)比較表達(dá)式”其實(shí)是賦值敲過一次之后就能記住。這種“把 SQL 語義翻譯成鏈?zhǔn)椒椒ā钡淖龇ㄗ尭逻壿嬜兊每勺x、可拼裝、可動態(tài)控制也是我愿意持續(xù)用它的原因。適合什么人看這篇合集一種是項(xiàng)目里已經(jīng)在用 SqlSugar但老是記不住更新 API 的另一種是剛接觸 .NET ORM想對比一下更新寫法的。如果你是后者建議先打開 SqlSugar 官方文檔的更新章節(jié)配合這篇一起看效果會好很多。1.2 從一條 SQL 到一行鏈?zhǔn)秸{(diào)用Updateable 封裝了什么先回顧最原始的 SQL 更新長什么樣UPDATE user SET name 張三, phone 13800138000, update_time NOW() WHERE id 10086;這條 SQL 一共干三件事指定表user設(shè)置三列的新值限定id 10086這一行。SqlSugar 的Updateable做的就是把這三件事分別映射到對應(yīng)的鏈?zhǔn)椒椒ㄉ媳碛煞盒蚒pdateableUser()決定也可以用.AS(表名)改表名。賦值由實(shí)體對象本身或者SetColumns、UpdateColumns決定。條件由Where、WhereColumns決定或者依賴實(shí)體主鍵自動生成。執(zhí)行ExecuteCommand()發(fā)送 SQL返回受影響行數(shù)。我經(jīng)常和一個(gè)比喻Updateable像一個(gè)裝修隊(duì)泛型是房子的地址賦值是“你要翻新哪些區(qū)域”條件就是“只翻新幾號房其他房間別碰”最后ExecuteCommand是簽字驗(yàn)收。ExecuteCommand不調(diào)用前面的鏈?zhǔn)脚渲迷俣嘁膊粫嬲龍?zhí)行更新這個(gè)特性也讓開發(fā)者可以像拼積木一樣動態(tài)構(gòu)造更新語句。還有一點(diǎn)容易忽略SqlSugar 生成更新語句時(shí)會使用參數(shù)化查詢。比如剛才那條 SQL最終發(fā)給數(shù)據(jù)庫的可能是name name這樣的參數(shù)形式。這樣做有兩個(gè)好處一是能有效避免 SQL 注入二是數(shù)據(jù)庫可以緩存執(zhí)行計(jì)劃。很多開發(fā)從手拼 SQL 轉(zhuǎn)過來之后最不適應(yīng)的就是這一點(diǎn)但實(shí)際上這恰恰是 ORM 框架幫你兜底的地方。1.3 主鍵SqlSugar 默認(rèn)用什么決定更新范圍更新操作最怕“不知道更新了誰”。SqlSugar 在實(shí)體更新時(shí)默認(rèn)會嘗試使用實(shí)體主鍵作為更新條件。也就是說如果你的User類里有一個(gè)標(biāo)了IsPrimaryKey true的屬性并且實(shí)體對象里的主鍵值有值那么db.Updateable(user).ExecuteCommand()會自動生成帶主鍵條件的WHERE。但這里有一個(gè)必須警惕的點(diǎn)如果實(shí)體沒有主鍵或者主鍵值沒有賦值SqlSugar 的行為就不是那么“安全”了。不同版本的策略會有差異有些情況會嘗試把所有列都拼到 WHERE 里做全列匹配導(dǎo)致一條都更新不中有些情況可能生成沒有條件的更新語句直接全表覆蓋。無論哪種結(jié)果都是業(yè)務(wù)災(zāi)難。所以我給自己的團(tuán)隊(duì)定了一條鐵律沒有配置主鍵的實(shí)體絕對不允許裸調(diào)ExecuteCommand()必須先寫WhereColumns或Where顯式指定更新條件。在下面的章節(jié)我會反復(fù)強(qiáng)調(diào)這一點(diǎn)因?yàn)樗档每淘谀X門上。2. 最基本的實(shí)體更新與批量更新2.1 單實(shí)體更新確定主鍵之后直接調(diào)最基礎(chǔ)的用法是傳入一個(gè)實(shí)體對象。假設(shè)你的User類長這樣public class User { [SqlSugar.SugarColumn(IsPrimaryKey true)] public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } public DateTime UpdateTime { get; set; } }那么更新單條記錄只需要var user new User { Id 1, Name 張三, Age 18, UpdateTime DateTime.Now }; var rows db.Updateable(user).ExecuteCommand();這個(gè)操作生成的 SQL 大致是UPDATE user SET name name, age age, update_time update_time WHERE id id;這里有幾個(gè)容易被坑的地方。第一Updateable(user)默認(rèn)會把實(shí)體里所有非空字段都放進(jìn) SET 語句具體哪些列會更新取決于列是否允許為空以及版本行為。我見過很多人在實(shí)體更新時(shí)把不想動的字段也賦了舊值結(jié)果白白產(chǎn)生一次無意義的寫操作。第二ExecuteCommand返回的rows是影響行數(shù)如果更新前后值一模一樣很多數(shù)據(jù)庫返回的影響行數(shù)是 0不代表更新失敗。后面常見問題里再詳細(xì)說。如果實(shí)在不放心主鍵會不會被識別可以顯式指定更新條件列var rows db.Updateable(user) .WhereColumns(it it.Id) .ExecuteCommand();WhereColumns的意思是“用 Id 這一列的值作為每一行的定位條件”即使實(shí)體沒有配置主鍵這個(gè)寫法也能正常更新。2.2 批量更新別在 foreach 里逐條 Update新手最常見的錯(cuò)誤是拿到一個(gè)ListUser之后在循環(huán)里調(diào)用db.Updateable(single).ExecuteCommand()。數(shù)據(jù)量小的時(shí)候確實(shí)能跑但幾百上千條之后性能直線下降還容易把事務(wù)邊界搞亂。SqlSugar 直接支持傳集合var list new ListUser { new User { Id 1, Name 張三, Age 18 }, new User { Id 2, Name 李四, Age 22 }, new User { Id 3, Name 王五, Age 25 } }; var rows db.Updateable(list).ExecuteCommand();這個(gè)操作并不是生成一條“一個(gè) UPDATE 更新多行”的 SQL而是框架內(nèi)部逐條生成更新語句并在一個(gè)事務(wù)包裹下執(zhí)行。好處是具備基本的原子性中間只要有一條失敗整個(gè)批量更新都會回滾。壞處是數(shù)據(jù)量大了之后性能依然不理想所以 SqlSugar 提供了PageSize方法來分批執(zhí)行這個(gè)我放到性能優(yōu)化小節(jié)細(xì)講。批量更新還有一個(gè)注意點(diǎn)如果列表里的實(shí)體帶有主鍵默認(rèn)按主鍵更新如果主鍵缺失或者你想按照業(yè)務(wù)字段去定位就要使用WhereColumns。比如按照 用戶編號區(qū)域編號 來更新var rows db.Updateable(list) .WhereColumns(it new { it.RegionId, it.UserId }) .ExecuteCommand();這段代碼的意思是同一個(gè)RegionId和UserId對應(yīng)的記錄會被更新為該實(shí)體中攜帶的其他列值。這個(gè)寫法在處理 Excel 導(dǎo)入后修正數(shù)據(jù)時(shí)尤其常用。2.3 異步方法與受影響行數(shù)ASP.NET Core 項(xiàng)目里我基本都會用異步版本。SqlSugar 的更新方法基本都有對應(yīng)異步版本var rows await db.Updateable(user).ExecuteCommandAsync();為什么要強(qiáng)調(diào)異步Web 應(yīng)用在高并發(fā)下如果線程池里的線程都阻塞在數(shù)據(jù)庫操作上吞吐量會明顯下降。而且 SqlSugar 的異步 API 不只是包一層 Task內(nèi)部會正確處理連接和異步 IO所以能用 async 就用 async。rows這個(gè)返回值也別把它當(dāng)擺設(shè)。我習(xí)慣在更新用戶狀態(tài)這類關(guān)鍵操作后判斷返回值if (rows 0) { // 不能直接認(rèn)定失敗但可以單獨(dú)處理 }為什么不能直接認(rèn)定失敗因?yàn)椤坝绊懶袛?shù)為 0”可能有三種情況記錄不存在、條件不滿足、數(shù)據(jù)值沒有變化。如果業(yè)務(wù)要求嚴(yán)格應(yīng)該再查一次數(shù)據(jù)或者用更高階的樂觀鎖方案來判斷到底有沒有沖突。3. 按條件更新與局部列控制3.1 SetColumns只更新你指定的字段而不是整個(gè)實(shí)體實(shí)體更新雖然方便但最大的問題是“不可控”。比如編輯用戶資料時(shí)前端只會傳過來姓名和年齡但實(shí)體里還有手機(jī)號、狀態(tài)、積分等字段。如果直接用實(shí)體更新就必須先把舊實(shí)體查出來整個(gè)賦一遍否則會把自己的字段覆蓋掉。更優(yōu)雅的方案是SetColumns它可以做到只更新指定字段db.UpdateableUser() .SetColumns(it it.Name 張三) .SetColumns(it it.Age 18) .SetColumns(it it.UpdateTime DateTime.Now) .Where(it it.Id 10086) .ExecuteCommand();這里的不是比較而是“賦值的意思”。it.Name 張三被解析成SET name 張三。第一次看到的人很容易懵這個(gè)語法是 SqlSugar 獨(dú)有的習(xí)慣寫多了反而覺得很順因?yàn)樗选敖o哪個(gè)列賦值”寫得很顯式。我實(shí)際項(xiàng)目里最喜歡用這個(gè) API 做“動態(tài)更新”。接口入?yún)⒖赡苤挥胁糠肿侄斡兄祩鹘y(tǒng)做法是寫一大堆 if 去拼接 SQL用 SqlSugar 可以這樣var upd db.UpdateableUser().Where(it it.Id request.Id); if (!string.IsNullOrEmpty(request.Name)) { upd upd.SetColumns(it it.Name request.Name); } if (request.Age.HasValue) { upd upd.SetColumns(it it.Age request.Age.Value); } var rows await upd.ExecuteCommandAsync();這樣既避免了把 null 更新進(jìn)數(shù)據(jù)庫也避免了覆蓋前端沒有提交的字段。而且SetColumns方法支持鏈?zhǔn)秸{(diào)用像拼積木一樣條件滿足就多拼一塊不滿足就不拼非常靈活。3.2 UpdateColumns 與 IgnoreColumns局部列控制的速查對比除了SetColumnsSqlSugar 還提供了兩個(gè)從實(shí)體更新出發(fā)的列控制方法。一個(gè)是UpdateColumns指定“只更新這些列”另一個(gè)是IgnoreColumns指定“除了這些列都要更新”。先說UpdateColumns它適合實(shí)體已經(jīng)完整賦值但不想更新某些無關(guān)字段的場景var user new User { Id 1, Name 張三, Age 18, UpdateTime DateTime.Now, CreateTime DateTime.Now // 這個(gè)字段不該被更新 }; db.Updateable(user) .UpdateColumns(it new { it.Name, it.Age, it.UpdateTime }) .ExecuteCommand();生成的 SQL 只會包含name、age、update_time三個(gè) SET 字段不管實(shí)體里CreateTime有沒有值都不會碰它。再看IgnoreColumns它是反著來默認(rèn)全字段更新但把指定的列排除在外db.Updateable(user) .IgnoreColumns(it new { it.CreateTime, it.RowVersion }) .ExecuteCommand();這在處理“某些列只能由數(shù)據(jù)庫維護(hù)”的場景時(shí)非常好用比如自增主鍵、創(chuàng)建時(shí)間、行版本號等。我建議把這兩個(gè)方法區(qū)分開來記UpdateColumns 是白名單IgnoreColumns 是黑名單。不要把兩者混用否則容易造成理解混亂。另外如果用SetColumns已經(jīng)明確指定了賦值列就不要再疊加UpdateColumns了那樣會讓代碼邏輯變得難以維護(hù)。3.3 Where 與 WhereColumns更新條件到底怎么寫Where是大家最熟悉的條件方法它生成的是整個(gè)更新的全局過濾條件和普通查詢里的Where幾乎一樣db.UpdateableUser() .SetColumns(it it.Status -1) .Where(it it.Id 10086 it.OrganizationId 5) .ExecuteCommand();對應(yīng)的 SQL 就是UPDATE user SET status -1 WHERE id 10086 AND organization_id 5;Where適合“所有行共用同一個(gè)條件”的批量更新比如把某個(gè)組織下的所有用戶停用。而WhereColumns之前已經(jīng)出現(xiàn)過它的作用相對特殊批量更新時(shí)用它指定“每一行要攜帶哪些列作為更新條件”。它的語義更像“把實(shí)體里這些列的值作為 SQL 參數(shù)放進(jìn) WHERE”。看一個(gè)例子var list new ListUser { new User { Id 1, Name 張三, RegionId 10 }, new User { Id 2, Name 李四, RegionId 20 } }; db.Updateable(list) .WhereColumns(it new { it.Id, it.RegionId }) .ExecuteCommand();這條會生成兩條更新語句第一條是WHERE id 1 AND region_id 10第二條是WHERE id 2 AND region_id 20。Where和WhereColumns可以組合使用但絕大多數(shù)業(yè)務(wù)場景只需要其中一種。記住Where 是靜態(tài)全局條件WhereColumns 是逐行動態(tài)條件。這個(gè)區(qū)別搞清楚了批量更新基本不會寫錯(cuò)。4. 復(fù)雜更新場景與 SqlSugar 高階玩法4.1 用 SQL 表達(dá)式做自增、減庫存、字符串拼接業(yè)務(wù)里經(jīng)常遇到“瀏覽量加 1”“庫存減 1”這樣的需求。新手容易寫出這種代碼先查出來再內(nèi)存里加一再更新回去。這個(gè)寫法在并發(fā)下一定會丟更新因?yàn)橹虚g有“查出來”和“寫回去”的間隙。正確做法是讓數(shù)據(jù)庫自己在 SQL 里做加減。SqlSugar 的SetColumns支持表達(dá)式右側(cè)引用數(shù)據(jù)庫字段本身db.UpdateableProduct() .SetColumns(it it.Stock it.Stock - 1) .Where(it it.Sku A10086 it.Stock 1) .ExecuteCommand();生成的 SQL 類似UPDATE product SET stock stock - 1 WHERE sku A10086 AND stock 1;這么做有兩個(gè)好處第一整個(gè)過程在數(shù)據(jù)庫內(nèi)部完成不存在查詢再回寫的并發(fā)窗口第二Where 里加stock 1天然防止了庫存扣成負(fù)數(shù)比在業(yè)務(wù)代碼里判斷可靠得多。同理字符串拼接、時(shí)間追加都可以用表達(dá)式db.UpdateableUser() .SetColumns(it it.Name it.Name _新后綴) .SetColumns(it it.LoginCount it.LoginCount 1) .SetColumns(it it.UpdateTime DateTime.Now) .Where(it it.Id 1) .ExecuteCommand();SetColumns右側(cè)如果出現(xiàn)it.某字段它會被翻譯成字段引用而不是參數(shù)值。這一點(diǎn)非常重要因?yàn)樗恰皵?shù)據(jù)庫內(nèi)部計(jì)算”還是“外部參數(shù)覆蓋”的分水嶺。寫之前想清楚右側(cè)引用的是不是列名就不會出錯(cuò)了。4.2 更新時(shí)加 WhereExists避免關(guān)聯(lián)空值覆蓋有一個(gè)很容易被忽視的更新場景更新一個(gè)子表但子表數(shù)據(jù)關(guān)聯(lián)的主表記錄可能已經(jīng)被刪了或者關(guān)聯(lián)值本身不在主表里。如果直接更新就會把一批“孤兒數(shù)據(jù)”的狀態(tài)改掉等到后續(xù)關(guān)聯(lián)查詢時(shí)才發(fā)現(xiàn)數(shù)據(jù)對不上。SqlSugar 的子查詢表達(dá)式可以解決這個(gè)問題。需求場景為更新所有帖子狀態(tài)為“已刪除”但只更新作者還存在的帖子。官方用法是借助SqlFunc.Subqueryabledb.UpdateablePost() .SetColumns(it it.Status -1) .Where(it SqlFunc.SubqueryableUser() .Where(u u.Id it.UserId) .Any()) .ExecuteCommand();Any()會被解析成EXISTS生成的 SQL 類似UPDATE post SET status -1 WHERE EXISTS (SELECT 1 FROM user u WHERE u.id post.user_id);這個(gè)寫法把“過濾臟數(shù)據(jù)”下推到了數(shù)據(jù)庫不用先查 id 列表再更新。我在做歷史數(shù)據(jù)清洗時(shí)經(jīng)常這么用因?yàn)闅v史數(shù)據(jù)里外鍵關(guān)系經(jīng)常不完整這個(gè)條件能一次性篩掉大量臟數(shù)據(jù)避免把原本就無主的記錄誤更新。不同版本的 SqlSugar 對SqlFunc.Subqueryable的支持略有差異用之前建議先在本地跑一個(gè)最小示例看下生成的 SQL。4.3 無主鍵實(shí)體、復(fù)合主鍵與樂觀鎖處理無主鍵實(shí)體更新是前面反復(fù)強(qiáng)調(diào)的高危場景。一張業(yè)務(wù)表如果本身沒有主鍵那么實(shí)體類里就不能定義IsPrimaryKey屬性。此時(shí)直接執(zhí)行var row new NoKeyTable { Name 測試, Code C001 }; db.Updateable(row).ExecuteCommand();很可能不會達(dá)到預(yù)期。所以無主鍵表更新時(shí)必須先定位條件var row new NoKeyTable { Code C001, Name 測試 }; db.Updateable(row) .WhereColumns(it new { it.Code }) .ExecuteCommand();這樣生成的 WHERE 只有code C001而其他列作為SET賦值定位和更新邏輯非常清晰。復(fù)合主鍵表的處理跟單主鍵類似只要實(shí)體上把多個(gè)字段標(biāo)記為主鍵默認(rèn)更新就會帶上全部主鍵條件。批量更新時(shí)可以顯式指定多個(gè)條件列db.Updateable(list) .WhereColumns(it new { it.OrderId, it.SeqNo }) .ExecuteCommand();再來說樂觀鎖。SqlSugar 本身沒有內(nèi)置強(qiáng)一致的樂觀鎖攔截但完全可以自己用“版本號條件”實(shí)現(xiàn)。表里加一個(gè)Version字段更新時(shí)在Where里帶上舊版本號var rows db.UpdateableUser() .SetColumns(it it.Name 新名字) .SetColumns(it it.Version it.Version 1) .Where(it it.Id request.Id it.Version request.Version) .ExecuteCommand(); if (rows 0) { // 說明版本號已經(jīng)變化應(yīng)該提示用戶重新加載 }這里SetColumns負(fù)責(zé)把版本號自增Where負(fù)責(zé)校驗(yàn)版本號一致兩條一起生成一條原子 SQL在并發(fā)場景下不會出現(xiàn)“兩個(gè)人同時(shí)改同一行”的問題。這個(gè)模式我在訂單、配置表等關(guān)鍵數(shù)據(jù)上用了很久穩(wěn)。4.4 更新配合事務(wù)、緩存與分頁批量更新操作經(jīng)常要跟其他寫操作放在同一個(gè)事務(wù)里。比如“改訂單狀態(tài)”和“扣庫存”必須一起成功或一起失敗。SqlSugar 的寫法很直接var result db.Ado.UseTran(() { db.UpdateableOrder() .SetColumns(it it.Status 2) .Where(it it.OrderId 10001) .ExecuteCommand(); db.UpdateableProduct() .SetColumns(it it.Stock it.Stock - 1) .Where(it it.Sku A10086) .ExecuteCommand(); }); if (result.HasError) { // 事務(wù)回滾記錄 result.ErrorMessage }UseTran會自動在傳入委托執(zhí)行發(fā)生異常時(shí)回滾不用自己手動管理Commit/Rollback代碼結(jié)構(gòu)也清晰。如果是異步方法可以用UseTranAsync。如果項(xiàng)目里開了二級緩存更新后記得清緩存否則老數(shù)據(jù)會被緩存住。SqlSugar 提供了RemoveDataCache方法db.UpdateableUser() .SetColumns(it it.Name 張三) .Where(it it.Id 1) .RemoveDataCache() .ExecuteCommand();最后說大數(shù)據(jù)量批量更新的分頁控制。當(dāng)List里有幾千甚至上萬條數(shù)據(jù)時(shí)一次性執(zhí)行會有兩個(gè)問題單次事務(wù)時(shí)間過長、數(shù)據(jù)庫鎖范圍過大。SqlSugar 的PageSize可以把大集合拆成多個(gè)批次db.Updateable(userList) .WhereColumns(it it.Id) .PageSize(500) .ExecuteCommand();這個(gè) API 會在內(nèi)部按 500 條一批執(zhí)行每一批有自己的事務(wù)邊界整體性能比循環(huán)調(diào)用好得多。我在清理歷史數(shù)據(jù)時(shí)用過一次 2 萬條左右的批量更新配合PageSize(1000)幾分鐘跑完沒有出現(xiàn)鎖等待超時(shí)。5. Update 踩坑與排查實(shí)錄5.1 影響行數(shù)為 0但數(shù)據(jù)其實(shí)沒變更新接口返回rows 0第一反應(yīng)“更新失敗了”實(shí)際上不一定。比如用戶把昵稱從“張三”改成“張三”數(shù)據(jù)庫會認(rèn)為沒有任何字段發(fā)生實(shí)際變化某些數(shù)據(jù)庫驅(qū)動返回的影響行數(shù)就是 0。這在 MySQL 里非常容易碰到。排查方法很簡單先看條件是否真的匹配。把 SqlSugar 生成的 SQL 打出來手動在數(shù)據(jù)庫客戶端執(zhí)行一遍看看是否命中記錄。打印 SQL 有兩種方式一種是在代碼里拿到更新語句SqlSugar 提供了類似ToSql()的方法var sql db.UpdateableUser() .SetColumns(it it.Name 張三) .Where(it it.Id 1) .ToSql(); Console.WriteLine(sql);另一種是開啟 SqlSugar 的 SQL 日志輸出。看到 SQL 之后再判斷如果條件字段類型不匹配導(dǎo)致索引失效或者實(shí)體字段名跟列名對不上都可能導(dǎo)致更新命中不了。如果確認(rèn)是“值沒變化導(dǎo)致的 0 行”業(yè)務(wù)上不要把它當(dāng)作失敗去提示用戶?？梢园研枨蟛鸪伞爸灰刑峤痪吞崾境晒Α被蛘哂肊xecuteCommand之前先判斷值是否變了。5.2 更新全表的災(zāi)難WHERE 被吞了怎么辦見過太多線上事故是“一條 update 語句忘了寫 where”。ORM 雖然幫你生成了 SQL但它不會替你檢查業(yè)務(wù)完整性。尤其是這種寫法db.UpdateableUser() .SetColumns(it it.Status -1) .ExecuteCommand();沒寫WhereSqlSugar 不會報(bào)錯(cuò)它會老老實(shí)實(shí)生成UPDATE user SET status -1然后整個(gè)表的狀態(tài)就沒了。這也是為什么我在前面反復(fù)強(qiáng)調(diào)寫 Update 之前先寫條件列養(yǎng)成“條件優(yōu)先”的習(xí)慣。有一個(gè)保險(xiǎn)做法在開發(fā)環(huán)境配置 SqlSugar 的 SQL 執(zhí)行監(jiān)控把所有更新語句記錄到日志里人工巡檢或者定時(shí)檢查。另一個(gè)更保險(xiǎn)的做法是給所有核心更新語句用ToSql()先看一眼確認(rèn)翻譯出來的 SQL 帶上了WHERE。不要嫌麻煩這個(gè)動作十秒鐘能省掉的爛攤子可能是幾小時(shí)甚至一整天。如果已經(jīng)誤更新了全表第一時(shí)間先備份并停止寫入然后根據(jù)業(yè)務(wù)日志嘗試恢復(fù)。老實(shí)講預(yù)防的成本遠(yuǎn)低于事后處理ORM 本身不背這個(gè)鍋寫代碼的人要心里有數(shù)。5.3 并發(fā)下的臟寫版本號、條件值、數(shù)據(jù)庫鎖并發(fā)更新問題在運(yùn)營后臺尤其突出。兩個(gè)管理員同時(shí)編輯同一個(gè)用戶后保存的人會覆蓋先保存的人。解決辦法就是用樂觀鎖也就是我前面提到的“版本號 條件”。這里再給一個(gè)更通用的做法更新時(shí)在Where里帶上舊值條件不一定要版本號字段。比如表單頁提交時(shí)前端帶了用戶當(dāng)前年齡更新語句要求數(shù)據(jù)庫里的年齡必須還是這個(gè)值才更新var rows db.UpdateableUser() .SetColumns(it it.Name request.Name) .Where(it it.Id request.Id it.Age request.OldAge) .ExecuteCommand();如果rows 0說明這行數(shù)據(jù)在你打開表單之后已經(jīng)被別人改過這時(shí)再決定是重試還是報(bào)沖突。這個(gè)方案的優(yōu)點(diǎn)是表結(jié)構(gòu)不用加字段缺點(diǎn)是每個(gè)條件都得預(yù)先賦值字段多的時(shí)候?qū)懫饋矸爆?。兩者選一種即可。對于“讀出來、改一下、寫回去”的場景盡量改造成 SQL 表達(dá)式直接更新比如庫存、次數(shù)這一類千萬不要在應(yīng)用層做“讀改寫”。如果一個(gè)字段經(jīng)常被并發(fā)修改數(shù)據(jù)庫表設(shè)計(jì)時(shí)就該考慮加版本號或者使用原子更新表達(dá)式。5.4 大批量更新性能調(diào)優(yōu)經(jīng)驗(yàn)最后集中說性能。最常見的性能問題不是Updateable本身慢而是寫法沒發(fā)揮出框架和數(shù)據(jù)庫的優(yōu)勢。第一條鐵律絕對不要循環(huán)里面調(diào)單條更新。哪怕只有十次循環(huán)每次都要重新連數(shù)據(jù)庫、開事務(wù)浪費(fèi)巨大。能用批量Updateable(list)就不用單條。第二條經(jīng)驗(yàn)是PageSize配合合理的批大小。我試過 500、1000、2000 三檔大多數(shù)情況下 500~1000 效果比較穩(wěn)。批太大事務(wù)時(shí)間太長鎖競爭激烈批太小又體現(xiàn)不出批量優(yōu)勢。不同數(shù)據(jù)庫表現(xiàn)有差異SQLServer 和 MySQL 建議都實(shí)際壓一下。第三條經(jīng)驗(yàn)是如果要更新幾萬行且邏輯和現(xiàn)有表數(shù)據(jù)強(qiáng)相關(guān)別死磕 ORM。SqlSugar 的Ado對象允許直接執(zhí)行原生 SQLvar rows db.Ado.ExecuteCommand( UPDATE user SET status status WHERE department_id deptId, new SqlSugar.SugarParameter(status, -1), new SqlSugar.SugarParameter(deptId, 100) );原生 SQL 配合臨時(shí)表、join 更新往往比逐條 ORM 更新快一個(gè)數(shù)量級。框架不是萬能的該用 SQL 的時(shí)候大膽用。更新操作還依賴索引。批量更新時(shí)如果Where后面的字段沒索引數(shù)據(jù)庫會全表掃描然后鎖住大量行性能瞬間崩掉。我習(xí)慣在開發(fā)環(huán)境用EXPLAIN看一下更新語句的執(zhí)行計(jì)劃尤其是那種“按業(yè)務(wù)編號更新整張表”的腳本。最后再分享一個(gè)小習(xí)慣任何更新方法在交付前我都會用ToSql()或ToSqlString()看一眼生成的 SQL重點(diǎn)檢查兩件事——SET 里有沒有混進(jìn)不該更新的列WHERE 里條件是不是完整。這個(gè)習(xí)慣幫我躲過了至少三次潛在的線上事故。SqlSugar 的 Update 語法本身不難難的是每次動手前都保持“更新是有風(fēng)險(xiǎn)的”這根弦。把這根弦繃住了更新操作就能變成一件既簡單又安全的事。 SqlSugar Update 語法全解析：從基礎(chǔ)到批量更新與踩坑指南
在 .NET 服務(wù)端開發(fā)里ORM 框架的選擇一直是個(gè)熱鬧話題。從 EF Core 到 Dapper 再到 SqlSugar每家都有自己的忠實(shí)用戶。SqlSugar 能在大量老項(xiàng)目和中小團(tuán)隊(duì)里扎根不是靠概念包裝而是靠那套貼合業(yè)務(wù)直覺的更新語法——尤其 Update 系列寫法簡單、直接、一眼看懂又能覆蓋絕大多數(shù)更新場景。如果你正在用 .NET 寫增刪改查或者正從別的 ORM 遷到 SqlSugar這篇把 Update 的常用語法、參數(shù)含義和踩坑點(diǎn)全部理一遍可以直接當(dāng)字典查。我最早接觸 SqlSugar 是做幾個(gè)運(yùn)營后臺系統(tǒng)剛開始天天手拼 SQL一個(gè)“改用戶資料”的需求寫了快兩百行條件分支后來換成db.Updateable(...)之后代碼量至少減了一半。這篇文章把這些年用過的 update 場景整理成合集不保證覆蓋所有偏門 API但日常開發(fā)里你能遇到的更新需求基本都能從這里面找到對應(yīng)的姿勢。老手可以直接跳到第三章新手建議從頭看因?yàn)樵角懊娴闹R點(diǎn)越容易被忽略而忽略的代價(jià)往往是線上數(shù)據(jù)被批量改壞。1. 先把 Update 語法的全局邏輯講清楚1.1 為什么 SqlSugar 值得單獨(dú)整理一份更新合集很多開發(fā)會覺得ORM 不都是根據(jù)實(shí)體生成 SQL 嗎Update 有什么好講的實(shí)際上更新操作和 Insert、Select 有本質(zhì)區(qū)別插入關(guān)心“插哪些字段”查詢關(guān)心“篩哪些條件”而更新必須同時(shí)處理好“賦值”和“條件”兩層邏輯。條件寫寬了整張表被改賦值列寫多了無關(guān)字段被覆蓋。這兩個(gè)問題在業(yè)務(wù)代碼里一旦出現(xiàn)往往是事故級別。SqlSugar 的UpdateableAPI 恰恰就是圍繞這兩層邏輯設(shè)計(jì)的。它的鏈?zhǔn)椒椒ò迅虏鸪扇龎K表是誰、要給哪些列賦值、在什么條件下生效。理解了這套模型之后你不需要去背每個(gè)方法的簽名而是自然知道去哪里查賦值相關(guān)的方法叫SetColumns或UpdateColumns條件相關(guān)的方法叫Where或WhereColumns執(zhí)行方法只有一個(gè)叫ExecuteCommand。這套設(shè)計(jì)還有一個(gè)好處是貼近業(yè)務(wù)表達(dá)。我經(jīng)常給團(tuán)隊(duì)里不太熟悉 SQL 的初級開發(fā)看代碼他們讀SetColumns(it it.Name 張三)的時(shí)候第一反應(yīng)是“這是個(gè)比較表達(dá)式”其實(shí)是賦值敲過一次之后就能記住。這種“把 SQL 語義翻譯成鏈?zhǔn)椒椒ā钡淖龇ㄗ尭逻壿嬜兊每勺x、可拼裝、可動態(tài)控制也是我愿意持續(xù)用它的原因。適合什么人看這篇合集一種是項(xiàng)目里已經(jīng)在用 SqlSugar但老是記不住更新 API 的另一種是剛接觸 .NET ORM想對比一下更新寫法的。如果你是后者建議先打開 SqlSugar 官方文檔的更新章節(jié)配合這篇一起看效果會好很多。1.2 從一條 SQL 到一行鏈?zhǔn)秸{(diào)用Updateable 封裝了什么先回顧最原始的 SQL 更新長什么樣UPDATE user SET name 張三, phone 13800138000, update_time NOW() WHERE id 10086;這條 SQL 一共干三件事指定表user設(shè)置三列的新值限定id 10086這一行。SqlSugar 的Updateable做的就是把這三件事分別映射到對應(yīng)的鏈?zhǔn)椒椒ㄉ媳碛煞盒蚒pdateableUser()決定也可以用.AS(表名)改表名。賦值由實(shí)體對象本身或者SetColumns、UpdateColumns決定。條件由Where、WhereColumns決定或者依賴實(shí)體主鍵自動生成。執(zhí)行ExecuteCommand()發(fā)送 SQL返回受影響行數(shù)。我經(jīng)常和一個(gè)比喻Updateable像一個(gè)裝修隊(duì)泛型是房子的地址賦值是“你要翻新哪些區(qū)域”條件就是“只翻新幾號房其他房間別碰”最后ExecuteCommand是簽字驗(yàn)收。ExecuteCommand不調(diào)用前面的鏈?zhǔn)脚渲迷俣嘁膊粫嬲龍?zhí)行更新這個(gè)特性也讓開發(fā)者可以像拼積木一樣動態(tài)構(gòu)造更新語句。還有一點(diǎn)容易忽略SqlSugar 生成更新語句時(shí)會使用參數(shù)化查詢。比如剛才那條 SQL最終發(fā)給數(shù)據(jù)庫的可能是name name這樣的參數(shù)形式。這樣做有兩個(gè)好處一是能有效避免 SQL 注入二是數(shù)據(jù)庫可以緩存執(zhí)行計(jì)劃。很多開發(fā)從手拼 SQL 轉(zhuǎn)過來之后最不適應(yīng)的就是這一點(diǎn)但實(shí)際上這恰恰是 ORM 框架幫你兜底的地方。1.3 主鍵SqlSugar 默認(rèn)用什么決定更新范圍更新操作最怕“不知道更新了誰”。SqlSugar 在實(shí)體更新時(shí)默認(rèn)會嘗試使用實(shí)體主鍵作為更新條件。也就是說如果你的User類里有一個(gè)標(biāo)了IsPrimaryKey true的屬性并且實(shí)體對象里的主鍵值有值那么db.Updateable(user).ExecuteCommand()會自動生成帶主鍵條件的WHERE。但這里有一個(gè)必須警惕的點(diǎn)如果實(shí)體沒有主鍵或者主鍵值沒有賦值SqlSugar 的行為就不是那么“安全”了。不同版本的策略會有差異有些情況會嘗試把所有列都拼到 WHERE 里做全列匹配導(dǎo)致一條都更新不中有些情況可能生成沒有條件的更新語句直接全表覆蓋。無論哪種結(jié)果都是業(yè)務(wù)災(zāi)難。所以我給自己的團(tuán)隊(duì)定了一條鐵律沒有配置主鍵的實(shí)體絕對不允許裸調(diào)ExecuteCommand()必須先寫WhereColumns或Where顯式指定更新條件。在下面的章節(jié)我會反復(fù)強(qiáng)調(diào)這一點(diǎn)因?yàn)樗档每淘谀X門上。2. 最基本的實(shí)體更新與批量更新2.1 單實(shí)體更新確定主鍵之后直接調(diào)最基礎(chǔ)的用法是傳入一個(gè)實(shí)體對象。假設(shè)你的User類長這樣public class User { [SqlSugar.SugarColumn(IsPrimaryKey true)] public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } public DateTime UpdateTime { get; set; } }那么更新單條記錄只需要var user new User { Id 1, Name 張三, Age 18, UpdateTime DateTime.Now }; var rows db.Updateable(user).ExecuteCommand();這個(gè)操作生成的 SQL 大致是UPDATE user SET name name, age age, update_time update_time WHERE id id;這里有幾個(gè)容易被坑的地方。第一Updateable(user)默認(rèn)會把實(shí)體里所有非空字段都放進(jìn) SET 語句具體哪些列會更新取決于列是否允許為空以及版本行為。我見過很多人在實(shí)體更新時(shí)把不想動的字段也賦了舊值結(jié)果白白產(chǎn)生一次無意義的寫操作。第二ExecuteCommand返回的rows是影響行數(shù)如果更新前后值一模一樣很多數(shù)據(jù)庫返回的影響行數(shù)是 0不代表更新失敗。后面常見問題里再詳細(xì)說。如果實(shí)在不放心主鍵會不會被識別可以顯式指定更新條件列var rows db.Updateable(user) .WhereColumns(it it.Id) .ExecuteCommand();WhereColumns的意思是“用 Id 這一列的值作為每一行的定位條件”即使實(shí)體沒有配置主鍵這個(gè)寫法也能正常更新。2.2 批量更新別在 foreach 里逐條 Update新手最常見的錯(cuò)誤是拿到一個(gè)ListUser之后在循環(huán)里調(diào)用db.Updateable(single).ExecuteCommand()。數(shù)據(jù)量小的時(shí)候確實(shí)能跑但幾百上千條之后性能直線下降還容易把事務(wù)邊界搞亂。SqlSugar 直接支持傳集合var list new ListUser { new User { Id 1, Name 張三, Age 18 }, new User { Id 2, Name 李四, Age 22 }, new User { Id 3, Name 王五, Age 25 } }; var rows db.Updateable(list).ExecuteCommand();這個(gè)操作并不是生成一條“一個(gè) UPDATE 更新多行”的 SQL而是框架內(nèi)部逐條生成更新語句并在一個(gè)事務(wù)包裹下執(zhí)行。好處是具備基本的原子性中間只要有一條失敗整個(gè)批量更新都會回滾。壞處是數(shù)據(jù)量大了之后性能依然不理想所以 SqlSugar 提供了PageSize方法來分批執(zhí)行這個(gè)我放到性能優(yōu)化小節(jié)細(xì)講。批量更新還有一個(gè)注意點(diǎn)如果列表里的實(shí)體帶有主鍵默認(rèn)按主鍵更新如果主鍵缺失或者你想按照業(yè)務(wù)字段去定位就要使用WhereColumns。比如按照 用戶編號區(qū)域編號 來更新var rows db.Updateable(list) .WhereColumns(it new { it.RegionId, it.UserId }) .ExecuteCommand();這段代碼的意思是同一個(gè)RegionId和UserId對應(yīng)的記錄會被更新為該實(shí)體中攜帶的其他列值。這個(gè)寫法在處理 Excel 導(dǎo)入后修正數(shù)據(jù)時(shí)尤其常用。2.3 異步方法與受影響行數(shù)ASP.NET Core 項(xiàng)目里我基本都會用異步版本。SqlSugar 的更新方法基本都有對應(yīng)異步版本var rows await db.Updateable(user).ExecuteCommandAsync();為什么要強(qiáng)調(diào)異步Web 應(yīng)用在高并發(fā)下如果線程池里的線程都阻塞在數(shù)據(jù)庫操作上吞吐量會明顯下降。而且 SqlSugar 的異步 API 不只是包一層 Task內(nèi)部會正確處理連接和異步 IO所以能用 async 就用 async。rows這個(gè)返回值也別把它當(dāng)擺設(shè)。我習(xí)慣在更新用戶狀態(tài)這類關(guān)鍵操作后判斷返回值if (rows 0) { // 不能直接認(rèn)定失敗但可以單獨(dú)處理 }為什么不能直接認(rèn)定失敗因?yàn)椤坝绊懶袛?shù)為 0”可能有三種情況記錄不存在、條件不滿足、數(shù)據(jù)值沒有變化。如果業(yè)務(wù)要求嚴(yán)格應(yīng)該再查一次數(shù)據(jù)或者用更高階的樂觀鎖方案來判斷到底有沒有沖突。3. 按條件更新與局部列控制3.1 SetColumns只更新你指定的字段而不是整個(gè)實(shí)體實(shí)體更新雖然方便但最大的問題是“不可控”。比如編輯用戶資料時(shí)前端只會傳過來姓名和年齡但實(shí)體里還有手機(jī)號、狀態(tài)、積分等字段。如果直接用實(shí)體更新就必須先把舊實(shí)體查出來整個(gè)賦一遍否則會把自己的字段覆蓋掉。更優(yōu)雅的方案是SetColumns它可以做到只更新指定字段db.UpdateableUser() .SetColumns(it it.Name 張三) .SetColumns(it it.Age 18) .SetColumns(it it.UpdateTime DateTime.Now) .Where(it it.Id 10086) .ExecuteCommand();這里的不是比較而是“賦值的意思”。it.Name 張三被解析成SET name 張三。第一次看到的人很容易懵這個(gè)語法是 SqlSugar 獨(dú)有的習(xí)慣寫多了反而覺得很順因?yàn)樗选敖o哪個(gè)列賦值”寫得很顯式。我實(shí)際項(xiàng)目里最喜歡用這個(gè) API 做“動態(tài)更新”。接口入?yún)⒖赡苤挥胁糠肿侄斡兄祩鹘y(tǒng)做法是寫一大堆 if 去拼接 SQL用 SqlSugar 可以這樣var upd db.UpdateableUser().Where(it it.Id request.Id); if (!string.IsNullOrEmpty(request.Name)) { upd upd.SetColumns(it it.Name request.Name); } if (request.Age.HasValue) { upd upd.SetColumns(it it.Age request.Age.Value); } var rows await upd.ExecuteCommandAsync();這樣既避免了把 null 更新進(jìn)數(shù)據(jù)庫也避免了覆蓋前端沒有提交的字段。而且SetColumns方法支持鏈?zhǔn)秸{(diào)用像拼積木一樣條件滿足就多拼一塊不滿足就不拼非常靈活。3.2 UpdateColumns 與 IgnoreColumns局部列控制的速查對比除了SetColumnsSqlSugar 還提供了兩個(gè)從實(shí)體更新出發(fā)的列控制方法。一個(gè)是UpdateColumns指定“只更新這些列”另一個(gè)是IgnoreColumns指定“除了這些列都要更新”。先說UpdateColumns它適合實(shí)體已經(jīng)完整賦值但不想更新某些無關(guān)字段的場景var user new User { Id 1, Name 張三, Age 18, UpdateTime DateTime.Now, CreateTime DateTime.Now // 這個(gè)字段不該被更新 }; db.Updateable(user) .UpdateColumns(it new { it.Name, it.Age, it.UpdateTime }) .ExecuteCommand();生成的 SQL 只會包含name、age、update_time三個(gè) SET 字段不管實(shí)體里CreateTime有沒有值都不會碰它。再看IgnoreColumns它是反著來默認(rèn)全字段更新但把指定的列排除在外db.Updateable(user) .IgnoreColumns(it new { it.CreateTime, it.RowVersion }) .ExecuteCommand();這在處理“某些列只能由數(shù)據(jù)庫維護(hù)”的場景時(shí)非常好用比如自增主鍵、創(chuàng)建時(shí)間、行版本號等。我建議把這兩個(gè)方法區(qū)分開來記UpdateColumns 是白名單IgnoreColumns 是黑名單。不要把兩者混用否則容易造成理解混亂。另外如果用SetColumns已經(jīng)明確指定了賦值列就不要再疊加UpdateColumns了那樣會讓代碼邏輯變得難以維護(hù)。3.3 Where 與 WhereColumns更新條件到底怎么寫Where是大家最熟悉的條件方法它生成的是整個(gè)更新的全局過濾條件和普通查詢里的Where幾乎一樣db.UpdateableUser() .SetColumns(it it.Status -1) .Where(it it.Id 10086 it.OrganizationId 5) .ExecuteCommand();對應(yīng)的 SQL 就是UPDATE user SET status -1 WHERE id 10086 AND organization_id 5;Where適合“所有行共用同一個(gè)條件”的批量更新比如把某個(gè)組織下的所有用戶停用。而WhereColumns之前已經(jīng)出現(xiàn)過它的作用相對特殊批量更新時(shí)用它指定“每一行要攜帶哪些列作為更新條件”。它的語義更像“把實(shí)體里這些列的值作為 SQL 參數(shù)放進(jìn) WHERE”。看一個(gè)例子var list new ListUser { new User { Id 1, Name 張三, RegionId 10 }, new User { Id 2, Name 李四, RegionId 20 } }; db.Updateable(list) .WhereColumns(it new { it.Id, it.RegionId }) .ExecuteCommand();這條會生成兩條更新語句第一條是WHERE id 1 AND region_id 10第二條是WHERE id 2 AND region_id 20。Where和WhereColumns可以組合使用但絕大多數(shù)業(yè)務(wù)場景只需要其中一種。記住Where 是靜態(tài)全局條件WhereColumns 是逐行動態(tài)條件。這個(gè)區(qū)別搞清楚了批量更新基本不會寫錯(cuò)。4. 復(fù)雜更新場景與 SqlSugar 高階玩法4.1 用 SQL 表達(dá)式做自增、減庫存、字符串拼接業(yè)務(wù)里經(jīng)常遇到“瀏覽量加 1”“庫存減 1”這樣的需求。新手容易寫出這種代碼先查出來再內(nèi)存里加一再更新回去。這個(gè)寫法在并發(fā)下一定會丟更新因?yàn)橹虚g有“查出來”和“寫回去”的間隙。正確做法是讓數(shù)據(jù)庫自己在 SQL 里做加減。SqlSugar 的SetColumns支持表達(dá)式右側(cè)引用數(shù)據(jù)庫字段本身db.UpdateableProduct() .SetColumns(it it.Stock it.Stock - 1) .Where(it it.Sku A10086 it.Stock 1) .ExecuteCommand();生成的 SQL 類似UPDATE product SET stock stock - 1 WHERE sku A10086 AND stock 1;這么做有兩個(gè)好處第一整個(gè)過程在數(shù)據(jù)庫內(nèi)部完成不存在查詢再回寫的并發(fā)窗口第二Where 里加stock 1天然防止了庫存扣成負(fù)數(shù)比在業(yè)務(wù)代碼里判斷可靠得多。同理字符串拼接、時(shí)間追加都可以用表達(dá)式db.UpdateableUser() .SetColumns(it it.Name it.Name _新后綴) .SetColumns(it it.LoginCount it.LoginCount 1) .SetColumns(it it.UpdateTime DateTime.Now) .Where(it it.Id 1) .ExecuteCommand();SetColumns右側(cè)如果出現(xiàn)it.某字段它會被翻譯成字段引用而不是參數(shù)值。這一點(diǎn)非常重要因?yàn)樗恰皵?shù)據(jù)庫內(nèi)部計(jì)算”還是“外部參數(shù)覆蓋”的分水嶺。寫之前想清楚右側(cè)引用的是不是列名就不會出錯(cuò)了。4.2 更新時(shí)加 WhereExists避免關(guān)聯(lián)空值覆蓋有一個(gè)很容易被忽視的更新場景更新一個(gè)子表但子表數(shù)據(jù)關(guān)聯(lián)的主表記錄可能已經(jīng)被刪了或者關(guān)聯(lián)值本身不在主表里。如果直接更新就會把一批“孤兒數(shù)據(jù)”的狀態(tài)改掉等到后續(xù)關(guān)聯(lián)查詢時(shí)才發(fā)現(xiàn)數(shù)據(jù)對不上。SqlSugar 的子查詢表達(dá)式可以解決這個(gè)問題。需求場景為更新所有帖子狀態(tài)為“已刪除”但只更新作者還存在的帖子。官方用法是借助SqlFunc.Subqueryabledb.UpdateablePost() .SetColumns(it it.Status -1) .Where(it SqlFunc.SubqueryableUser() .Where(u u.Id it.UserId) .Any()) .ExecuteCommand();Any()會被解析成EXISTS生成的 SQL 類似UPDATE post SET status -1 WHERE EXISTS (SELECT 1 FROM user u WHERE u.id post.user_id);這個(gè)寫法把“過濾臟數(shù)據(jù)”下推到了數(shù)據(jù)庫不用先查 id 列表再更新。我在做歷史數(shù)據(jù)清洗時(shí)經(jīng)常這么用因?yàn)闅v史數(shù)據(jù)里外鍵關(guān)系經(jīng)常不完整這個(gè)條件能一次性篩掉大量臟數(shù)據(jù)避免把原本就無主的記錄誤更新。不同版本的 SqlSugar 對SqlFunc.Subqueryable的支持略有差異用之前建議先在本地跑一個(gè)最小示例看下生成的 SQL。4.3 無主鍵實(shí)體、復(fù)合主鍵與樂觀鎖處理無主鍵實(shí)體更新是前面反復(fù)強(qiáng)調(diào)的高危場景。一張業(yè)務(wù)表如果本身沒有主鍵那么實(shí)體類里就不能定義IsPrimaryKey屬性。此時(shí)直接執(zhí)行var row new NoKeyTable { Name 測試, Code C001 }; db.Updateable(row).ExecuteCommand();很可能不會達(dá)到預(yù)期。所以無主鍵表更新時(shí)必須先定位條件var row new NoKeyTable { Code C001, Name 測試 }; db.Updateable(row) .WhereColumns(it new { it.Code }) .ExecuteCommand();這樣生成的 WHERE 只有code C001而其他列作為SET賦值定位和更新邏輯非常清晰。復(fù)合主鍵表的處理跟單主鍵類似只要實(shí)體上把多個(gè)字段標(biāo)記為主鍵默認(rèn)更新就會帶上全部主鍵條件。批量更新時(shí)可以顯式指定多個(gè)條件列db.Updateable(list) .WhereColumns(it new { it.OrderId, it.SeqNo }) .ExecuteCommand();再來說樂觀鎖。SqlSugar 本身沒有內(nèi)置強(qiáng)一致的樂觀鎖攔截但完全可以自己用“版本號條件”實(shí)現(xiàn)。表里加一個(gè)Version字段更新時(shí)在Where里帶上舊版本號var rows db.UpdateableUser() .SetColumns(it it.Name 新名字) .SetColumns(it it.Version it.Version 1) .Where(it it.Id request.Id it.Version request.Version) .ExecuteCommand(); if (rows 0) { // 說明版本號已經(jīng)變化應(yīng)該提示用戶重新加載 }這里SetColumns負(fù)責(zé)把版本號自增Where負(fù)責(zé)校驗(yàn)版本號一致兩條一起生成一條原子 SQL在并發(fā)場景下不會出現(xiàn)“兩個(gè)人同時(shí)改同一行”的問題。這個(gè)模式我在訂單、配置表等關(guān)鍵數(shù)據(jù)上用了很久穩(wěn)。4.4 更新配合事務(wù)、緩存與分頁批量更新操作經(jīng)常要跟其他寫操作放在同一個(gè)事務(wù)里。比如“改訂單狀態(tài)”和“扣庫存”必須一起成功或一起失敗。SqlSugar 的寫法很直接var result db.Ado.UseTran(() { db.UpdateableOrder() .SetColumns(it it.Status 2) .Where(it it.OrderId 10001) .ExecuteCommand(); db.UpdateableProduct() .SetColumns(it it.Stock it.Stock - 1) .Where(it it.Sku A10086) .ExecuteCommand(); }); if (result.HasError) { // 事務(wù)回滾記錄 result.ErrorMessage }UseTran會自動在傳入委托執(zhí)行發(fā)生異常時(shí)回滾不用自己手動管理Commit/Rollback代碼結(jié)構(gòu)也清晰。如果是異步方法可以用UseTranAsync。如果項(xiàng)目里開了二級緩存更新后記得清緩存否則老數(shù)據(jù)會被緩存住。SqlSugar 提供了RemoveDataCache方法db.UpdateableUser() .SetColumns(it it.Name 張三) .Where(it it.Id 1) .RemoveDataCache() .ExecuteCommand();最后說大數(shù)據(jù)量批量更新的分頁控制。當(dāng)List里有幾千甚至上萬條數(shù)據(jù)時(shí)一次性執(zhí)行會有兩個(gè)問題單次事務(wù)時(shí)間過長、數(shù)據(jù)庫鎖范圍過大。SqlSugar 的PageSize可以把大集合拆成多個(gè)批次db.Updateable(userList) .WhereColumns(it it.Id) .PageSize(500) .ExecuteCommand();這個(gè) API 會在內(nèi)部按 500 條一批執(zhí)行每一批有自己的事務(wù)邊界整體性能比循環(huán)調(diào)用好得多。我在清理歷史數(shù)據(jù)時(shí)用過一次 2 萬條左右的批量更新配合PageSize(1000)幾分鐘跑完沒有出現(xiàn)鎖等待超時(shí)。5. Update 踩坑與排查實(shí)錄5.1 影響行數(shù)為 0但數(shù)據(jù)其實(shí)沒變更新接口返回rows 0第一反應(yīng)“更新失敗了”實(shí)際上不一定。比如用戶把昵稱從“張三”改成“張三”數(shù)據(jù)庫會認(rèn)為沒有任何字段發(fā)生實(shí)際變化某些數(shù)據(jù)庫驅(qū)動返回的影響行數(shù)就是 0。這在 MySQL 里非常容易碰到。排查方法很簡單先看條件是否真的匹配。把 SqlSugar 生成的 SQL 打出來手動在數(shù)據(jù)庫客戶端執(zhí)行一遍看看是否命中記錄。打印 SQL 有兩種方式一種是在代碼里拿到更新語句SqlSugar 提供了類似ToSql()的方法var sql db.UpdateableUser() .SetColumns(it it.Name 張三) .Where(it it.Id 1) .ToSql(); Console.WriteLine(sql);另一種是開啟 SqlSugar 的 SQL 日志輸出。看到 SQL 之后再判斷如果條件字段類型不匹配導(dǎo)致索引失效或者實(shí)體字段名跟列名對不上都可能導(dǎo)致更新命中不了。如果確認(rèn)是“值沒變化導(dǎo)致的 0 行”業(yè)務(wù)上不要把它當(dāng)作失敗去提示用戶?？梢园研枨蟛鸪伞爸灰刑峤痪吞崾境晒Α被蛘哂肊xecuteCommand之前先判斷值是否變了。5.2 更新全表的災(zāi)難WHERE 被吞了怎么辦見過太多線上事故是“一條 update 語句忘了寫 where”。ORM 雖然幫你生成了 SQL但它不會替你檢查業(yè)務(wù)完整性。尤其是這種寫法db.UpdateableUser() .SetColumns(it it.Status -1) .ExecuteCommand();沒寫WhereSqlSugar 不會報(bào)錯(cuò)它會老老實(shí)實(shí)生成UPDATE user SET status -1然后整個(gè)表的狀態(tài)就沒了。這也是為什么我在前面反復(fù)強(qiáng)調(diào)寫 Update 之前先寫條件列養(yǎng)成“條件優(yōu)先”的習(xí)慣。有一個(gè)保險(xiǎn)做法在開發(fā)環(huán)境配置 SqlSugar 的 SQL 執(zhí)行監(jiān)控把所有更新語句記錄到日志里人工巡檢或者定時(shí)檢查。另一個(gè)更保險(xiǎn)的做法是給所有核心更新語句用ToSql()先看一眼確認(rèn)翻譯出來的 SQL 帶上了WHERE。不要嫌麻煩這個(gè)動作十秒鐘能省掉的爛攤子可能是幾小時(shí)甚至一整天。如果已經(jīng)誤更新了全表第一時(shí)間先備份并停止寫入然后根據(jù)業(yè)務(wù)日志嘗試恢復(fù)。老實(shí)講預(yù)防的成本遠(yuǎn)低于事后處理ORM 本身不背這個(gè)鍋寫代碼的人要心里有數(shù)。5.3 并發(fā)下的臟寫版本號、條件值、數(shù)據(jù)庫鎖并發(fā)更新問題在運(yùn)營后臺尤其突出。兩個(gè)管理員同時(shí)編輯同一個(gè)用戶后保存的人會覆蓋先保存的人。解決辦法就是用樂觀鎖也就是我前面提到的“版本號 條件”。這里再給一個(gè)更通用的做法更新時(shí)在Where里帶上舊值條件不一定要版本號字段。比如表單頁提交時(shí)前端帶了用戶當(dāng)前年齡更新語句要求數(shù)據(jù)庫里的年齡必須還是這個(gè)值才更新var rows db.UpdateableUser() .SetColumns(it it.Name request.Name) .Where(it it.Id request.Id it.Age request.OldAge) .ExecuteCommand();如果rows 0說明這行數(shù)據(jù)在你打開表單之后已經(jīng)被別人改過這時(shí)再決定是重試還是報(bào)沖突。這個(gè)方案的優(yōu)點(diǎn)是表結(jié)構(gòu)不用加字段缺點(diǎn)是每個(gè)條件都得預(yù)先賦值字段多的時(shí)候?qū)懫饋矸爆?。兩者選一種即可。對于“讀出來、改一下、寫回去”的場景盡量改造成 SQL 表達(dá)式直接更新比如庫存、次數(shù)這一類千萬不要在應(yīng)用層做“讀改寫”。如果一個(gè)字段經(jīng)常被并發(fā)修改數(shù)據(jù)庫表設(shè)計(jì)時(shí)就該考慮加版本號或者使用原子更新表達(dá)式。5.4 大批量更新性能調(diào)優(yōu)經(jīng)驗(yàn)最后集中說性能。最常見的性能問題不是Updateable本身慢而是寫法沒發(fā)揮出框架和數(shù)據(jù)庫的優(yōu)勢。第一條鐵律絕對不要循環(huán)里面調(diào)單條更新。哪怕只有十次循環(huán)每次都要重新連數(shù)據(jù)庫、開事務(wù)浪費(fèi)巨大。能用批量Updateable(list)就不用單條。第二條經(jīng)驗(yàn)是PageSize配合合理的批大小。我試過 500、1000、2000 三檔大多數(shù)情況下 500~1000 效果比較穩(wěn)。批太大事務(wù)時(shí)間太長鎖競爭激烈批太小又體現(xiàn)不出批量優(yōu)勢。不同數(shù)據(jù)庫表現(xiàn)有差異SQLServer 和 MySQL 建議都實(shí)際壓一下。第三條經(jīng)驗(yàn)是如果要更新幾萬行且邏輯和現(xiàn)有表數(shù)據(jù)強(qiáng)相關(guān)別死磕 ORM。SqlSugar 的Ado對象允許直接執(zhí)行原生 SQLvar rows db.Ado.ExecuteCommand( UPDATE user SET status status WHERE department_id deptId, new SqlSugar.SugarParameter(status, -1), new SqlSugar.SugarParameter(deptId, 100) );原生 SQL 配合臨時(shí)表、join 更新往往比逐條 ORM 更新快一個(gè)數(shù)量級。框架不是萬能的該用 SQL 的時(shí)候大膽用。更新操作還依賴索引。批量更新時(shí)如果Where后面的字段沒索引數(shù)據(jù)庫會全表掃描然后鎖住大量行性能瞬間崩掉。我習(xí)慣在開發(fā)環(huán)境用EXPLAIN看一下更新語句的執(zhí)行計(jì)劃尤其是那種“按業(yè)務(wù)編號更新整張表”的腳本。最后再分享一個(gè)小習(xí)慣任何更新方法在交付前我都會用ToSql()或ToSqlString()看一眼生成的 SQL重點(diǎn)檢查兩件事——SET 里有沒有混進(jìn)不該更新的列WHERE 里條件是不是完整。這個(gè)習(xí)慣幫我躲過了至少三次潛在的線上事故。SqlSugar 的 Update 語法本身不難難的是每次動手前都保持“更新是有風(fēng)險(xiǎn)的”這根弦。把這根弦繃住了更新操作就能變成一件既簡單又安全的事。