九九热最新网址,777奇米四色米奇影院在线播放,国产精品18久久久久久久久久,中文有码视频,亚洲一区在线免费观看,国产91精品在线,婷婷丁香六月天

20條sql書寫規(guī)范好習(xí)慣讓你受益一生

上傳人:ta****fu 文檔編號:199336986 上傳時間:2023-04-10 格式:DOCX 頁數(shù):9 大?。?10.67KB
收藏 版權(quán)申訴 舉報 下載
20條sql書寫規(guī)范好習(xí)慣讓你受益一生_第1頁
第1頁 / 共9頁
20條sql書寫規(guī)范好習(xí)慣讓你受益一生_第2頁
第2頁 / 共9頁
20條sql書寫規(guī)范好習(xí)慣讓你受益一生_第3頁
第3頁 / 共9頁

下載文檔到電腦,查找使用更方便

9.98 積分

下載資源

還剩頁未讀,繼續(xù)閱讀

資源描述:

《20條sql書寫規(guī)范好習(xí)慣讓你受益一生》由會員分享,可在線閱讀,更多相關(guān)《20條sql書寫規(guī)范好習(xí)慣讓你受益一生(9頁珍藏版)》請在裝配圖網(wǎng)上搜索。

1、MySQL 中,21 個寫 SQL 的好習(xí)慣 每一個好習(xí)慣都是一筆財富,本文分 SQL 后悔藥、SQL 性能優(yōu)化、SQL 規(guī)范優(yōu)雅三個方向,分享寫 SQL 的 21 個好習(xí)慣。 1. 寫完 SQL 先 explain 查看執(zhí)行計劃?!維QL 性能優(yōu)化】 日常開發(fā)寫 SQL 的時候,盡量養(yǎng)成這個好習(xí)慣呀:寫完 SQL 后,用 explain 分析一下,尤其注意走不走索引。 explain?select?userid,name,age?from?user? where?userid?=10086?or?age?=18; 2. 操作 delete 或者 update 語句,加個 limi

2、t。【SQL 后悔藥】 在執(zhí)行刪除或者更新語句時,盡量加上 limit,以下面的這條 SQL 為例吧: delete?from?euser?where?age?>?30?limit?200; 因為加了 limit 主要有這些好處: · 「降低寫錯 SQL 的代價」, 你在命令行執(zhí)行這個 SQL 的時候,如果不加 limit,執(zhí)行的時候一個「不小心手抖」,可能數(shù)據(jù)全刪掉了,如果「刪錯」了呢?加了 limit 200,就不一樣了。刪錯也只是丟失 200 條數(shù)據(jù),可以通過 binlog 日志快速恢復(fù)的。 · 「SQL 效率很可能更高」,你在 SQL 行中,加了 limit 1,如果第一條就

3、命中目標 return, 沒有 limit 的話,還會繼續(xù)執(zhí)行掃描表。 · 「避免了長事務(wù)」,delete 執(zhí)行時,如果 age 加了索引,MySQL 會將所有相關(guān)的行加寫鎖和間隙鎖,所有執(zhí)行相關(guān)行會被鎖住,如果刪除數(shù)量大,會直接影響相關(guān)業(yè)務(wù)無法使用。 · 「數(shù)據(jù)量大的話,容易把 CPU 打滿」?,如果你刪除數(shù)據(jù)量很大時,不加? limit 限制一下記錄數(shù),容易把 CPU 打滿,導(dǎo)致越刪越慢的。 3. 設(shè)計表的時候,所有表和字段都添加相應(yīng)的注釋?!維QL 規(guī)范優(yōu)雅】 這個好習(xí)慣一定要養(yǎng)成啦,設(shè)計數(shù)據(jù)庫表的時候,所有表和字段都添加相應(yīng)的注釋,后面更容易維護。 「正例:」 CREATE

4、?TABLE?`account`?( ??`id`?int(11)?NOT?NULL?AUTO_INCREMENT?COMMENT?'主鍵Id', ??`name`?varchar(255)?DEFAULT?NULL?COMMENT?'賬戶名', ??`balance`?int(11)?DEFAULT?NULL?COMMENT?'余額', ??`create_time`?datetime?NOT?NULL?COMMENT?'創(chuàng)建時間', ??`update_time`?datetime?NOT?NULL?ON?UPDATE?CURRENT_TIMESTAMP?COMMENT?'更新時

5、間', ??PRIMARY?KEY?(`id`), ??KEY?`idx_name`?(`name`)?USING?BTREE )?ENGINE=InnoDB?AUTO_INCREMENT=1570068?DEFAULT?CHARSET=utf8?ROW_FORMAT=REDUNDANT?COMMENT='賬戶表'; 「反例:」 CREATE?TABLE?`account`?( ??`id`?int(11)?NOT?NULL?AUTO_INCREMENT, ??`name`?varchar(255)?DEFAULT?NULL, ??`balance`?int(11)?DEFAU

6、LT?NULL, ??`create_time`?datetime?NOT?NULL?, ??`update_time`?datetime?NOT?NULL?ON?UPDATE?CURRENT_TIMESTAMP, ??PRIMARY?KEY?(`id`), ??KEY?`idx_name`?(`name`)?USING?BTREE )?ENGINE=InnoDB?AUTO_INCREMENT=1570068?DEFAULT?CHARSET=utf8; 4. SQL 書寫格式,關(guān)鍵字大小保持一致,使用縮進。【SQL 規(guī)范優(yōu)雅】 「正例:」 SELECT?stu.name,?su

7、m(stu.score) FROM?Student?stu WHERE?stu.classNo?=?'1班' GROUP?BY?stu.name 「反例:」 SELECT?stu.name,?sum(stu.score)?from?Student?stu?WHERE?stu.classNo?=?'1班'?group?by?stu.name. 顯然,統(tǒng)一關(guān)鍵字大小寫一致,使用縮進對齊,會使你的 SQL 看起來更優(yōu)雅~ 5. INSERT 語句標明對應(yīng)的字段名稱?!維QL 規(guī)范優(yōu)雅】 「反例:」 insert?into?Student?values?('666','撿田螺的小男孩

8、','100'); 「正例:」 insert?into?Student(student_id,name,score)?values?('666','撿田螺的小男孩','100'); 6. 變更 SQL 操作先在測試環(huán)境執(zhí)行,寫明詳細的操作步驟以及回滾方案,并在上生產(chǎn)前 review?!維QL 后悔藥】 · 變更 SQL 操作先在測試環(huán)境測試,避免有語法錯誤就放到生產(chǎn)上了。 · 變更?SQL?操作需要寫明詳細操作步驟,尤其有依賴關(guān)系的時候,如:先修改表結(jié)構(gòu)再補充對應(yīng)的數(shù)據(jù)。 · 變更?SQL?操作要有回滾方案,并在上生產(chǎn)前,review 對應(yīng)變更 SQL。 7. 設(shè)計數(shù)據(jù)庫表的時候

9、,加上三個字段:主鍵、create_time、update_time?!維QL 規(guī)范優(yōu)雅】 「反例:」 CREATE?TABLE?`account`?( ??`name`?varchar(255)?DEFAULT?NULL?COMMENT?'賬戶名', ??`balance`?int(11)?DEFAULT?NULL?COMMENT?'余額', )?ENGINE=InnoDB?AUTO_INCREMENT=1570068?DEFAULT?CHARSET=utf8?ROW_FORMAT=REDUNDANT?COMMENT='賬戶表'; 「正例:」 CREATE?TABLE?`acc

10、ount`?( ??`id`?int(11)?NOT?NULL?AUTO_INCREMENT?COMMENT?'主鍵Id', ??`name`?varchar(255)?DEFAULT?NULL?COMMENT?'賬戶名', ??`balance`?int(11)?DEFAULT?NULL?COMMENT?'余額', ??`create_time`?datetime?NOT?NULL?COMMENT?'創(chuàng)建時間', ??`update_time`?datetime?NOT?NULL?ON?UPDATE?CURRENT_TIMESTAMP?COMMENT?'更新時間', ??PRIM

11、ARY?KEY?(`id`), ??KEY?`idx_name`?(`name`)?USING?BTREE )?ENGINE=InnoDB?AUTO_INCREMENT=1570068?DEFAULT?CHARSET=utf8?ROW_FORMAT=REDUNDANT?COMMENT='賬戶表'; 「理由:」 · 主鍵一般都要加上的,沒有主鍵的表是沒有靈魂的。 · 創(chuàng)建時間和更新時間的話,還是建議加上吧,詳細審計、跟蹤記錄,都是有用的。 阿里開發(fā)手冊也提到這個點,如圖: 8. 寫完 SQL 語句,檢查 where、order by、group by 后面的列,多表關(guān)聯(lián)的列是否

12、已加索引,優(yōu)先考慮組合索引?!維QL 性能優(yōu)化】 「反例:」 select?*?from?user? where?address?='深圳'?order?by?age; 「正例:」 添加索引 alter?table?user?add?index?idx_address_age?(address,age) 9. 修改或刪除重要數(shù)據(jù)前,要先備份,先備份,先備份?!維QL 后悔藥】 如果要修改或刪除數(shù)據(jù),在執(zhí)行 SQL 前一定要先備份要修改的數(shù)據(jù),萬一誤操作,還能吃口「后悔藥」~ 10. where 后面的字段,留意其數(shù)據(jù)類型的隱式轉(zhuǎn)換?!維QL 性能優(yōu)化】 「反例:」

13、 //userid 是varchar字符串類型 select?*?from?user?where?userid?=123; 「正例:」 select?*?from?user?where?userid?='123'; 「理由:」 · 因為不加單引號時,是字符串跟數(shù)字的比較,它們類型不匹配,MySQL 會做隱式的類型轉(zhuǎn)換,把它們轉(zhuǎn)換為浮點數(shù)再做比較,最后導(dǎo)致索引失效。 11. 盡量把所有列定義為 NOT NULL?!維QL 規(guī)范優(yōu)雅】 · 「NOT NULL 列更節(jié)省空間」,NULL 列需要一個額外字節(jié)作為判斷是否為 NULL 的標志位。 · 「NULL 列需要注意空指針問

14、題」,NULL 列在計算和比較的時候,需要注意空指針問題。 12. 修改或者刪除 SQL,先寫 WHERE 查一下,確認后再補充 delete 或 update。【SQL 后悔藥】 尤其在操作生產(chǎn)的數(shù)據(jù)時,遇到修改或者刪除的 SQL,先加個 where 查詢一下,確認 OK 之后,再執(zhí)行 update 或者 delete 操作。 13. 減少不必要的字段返回,如使用 select <具體字段> 代替 select *?!維QL 性能優(yōu)化】 「反例:」 select?*?from?employee; 「正例:」 select?id,name?from?employee; 「理由:

15、」 · 節(jié)省資源,減少網(wǎng)絡(luò)開銷。 · 可能用到覆蓋索引,減少回表,提高查詢效率。 14. 所有表必須使用 Innodb 存儲引擎?!維QL 規(guī)范優(yōu)雅】 Innodb?「支持事務(wù),支持行級鎖,更好的恢復(fù)性」,高并發(fā)下性能更好,所以呢,沒有特殊要求(即 Innodb 無法滿足的功能如:列存儲,存儲空間數(shù)據(jù)等)的情況下,所有表必須使用 Innodb 存儲引擎。 15. 數(shù)據(jù)庫和表的字符集盡量統(tǒng)一使用 UTF8。【SQL 規(guī)范優(yōu)雅】 盡量統(tǒng)一使用 UTF8 編碼。 · 可以避免亂碼問題。 · 可以避免不同字符集比較轉(zhuǎn)換所導(dǎo)致的索引失效問題。 「如果需要存儲表情,那么選擇 utf8mb

16、4 來進行存儲,注意它與 utf-8 編碼的區(qū)別?!? 16. 盡量使用 varchar 代替 char。【SQL 性能優(yōu)化】 「反例:」 ??`deptName`?char(100)?DEFAULT?NULL?COMMENT?'部門名稱' 「正例:」 `deptName`?varchar(100)?DEFAULT?NULL?COMMENT?'部門名稱' 「理由:」 · 因為首先變長字段存儲空間小,可以節(jié)省存儲空間。 17. 如果修改字段含義或?qū)ψ侄伪硎镜臓顟B(tài)追加時,需要及時更新字段注釋?!維QL 規(guī)范優(yōu)雅】 這個點,是阿里開發(fā)手冊中 MySQL 的規(guī)約。你的字段,尤其是表示枚

17、舉狀態(tài)時,如果含義被修改了,或者狀態(tài)追加時,為了后面更好維護,需要及時更新字段的注釋。 18. SQL 命令行修改數(shù)據(jù),養(yǎng)成 begin + commit 事務(wù)的習(xí)慣?!維QL 后悔藥】 「正例:」 begin; update?account?set?balance?=1000000 where?name?='撿田螺的小男孩'; commit; 「反例:」 update?account?set?balance?=1000000 where?name?='撿田螺的小男孩'; 19. 索引命名要規(guī)范,主鍵索引名為 pk_ 字段名;唯一索引名為 uk _字段名 ;普通索引名則為

18、idx _字段名?!維QL 規(guī)范優(yōu)雅】 說明:pk_ 即 primary key;uk_ 即 unique key;idx_ 即 index 的簡稱。 20. WHERE 從句中不對列進行函數(shù)轉(zhuǎn)換和表達式計算?!維QL 性能優(yōu)化】 假設(shè) loginTime 加了索引。 「反例:」 select?userId,loginTime? from?loginuser where?Date_ADD(loginTime,Interval?7?DAY)?>=now(); 「正例:」 explain??select?userId,loginTime? from?loginuser? wh

19、ere??loginTime?>=?Date_ADD(NOW(),INTERVAL?-?7?DAY); 「理由:」 · 索引列上使用 MySQL 的內(nèi)置函數(shù),索引失效。 21. 如果修改/更新數(shù)據(jù)過多,考慮批量進行?!維QL 性能優(yōu)化】 「反例:」 delete?from?account??limit?100000; 「正例:」 for?each(200次) { ?delete?from?account??limit?500; } 「理由:」 · 大批量操作會造成主從延遲。 · 大批量操作會產(chǎn)生大事務(wù),阻塞。 · 大批量操作,數(shù)據(jù)量過大,會把 CPU 打滿。 參考與感謝

展開閱讀全文
溫馨提示:
1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3.本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

相關(guān)資源

更多
正為您匹配相似的精品文檔
關(guān)于我們 - 網(wǎng)站聲明 - 網(wǎng)站地圖 - 資源地圖 - 友情鏈接 - 網(wǎng)站客服 - 聯(lián)系我們

copyright@ 2023-2025  zhuangpeitu.com 裝配圖網(wǎng)版權(quán)所有   聯(lián)系電話:18123376007

備案號:ICP2024067431-1 川公網(wǎng)安備51140202000466號


本站為文檔C2C交易模式,即用戶上傳的文檔直接被用戶下載,本站只是中間服務(wù)平臺,本站所有文檔下載所得的收益歸上傳人(含作者)所有。裝配圖網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對上載內(nèi)容本身不做任何修改或編輯。若文檔所含內(nèi)容侵犯了您的版權(quán)或隱私,請立即通知裝配圖網(wǎng),我們立即給予刪除!