艾銻知識 | 8種SQL錯誤用法

2020-02-18 15:46 作者：admin 瀏覽量：

這幾天如果大家關注疫情數據的變化，可以看到新增確診病例在持續下降，這意味著疫情很快就會結束，大家再也不用在家辦公了，到不是在家工作有什么不好，但人類發明工作不簡簡單單只是為了實現結果的達成，還有一個非常重要的因素就是人與人之間的聯結，這是人類內在價值的需求，透過工作與人接觸，共同感受彼此的能量流動，從而達到自我價值的實現，這就像演員都渴望登上奧斯卡的舞臺，來實現自我角色的認可一樣。
 
 
在家辦公，畢竟是家，松、散、懶以及無所謂的態度會隨時產生，我相信不是每個人都會這樣，但大部分人會如此，因為家本來就是放松的能量場，接下來大家即將回到公司，回到自己的工作崗位，難免會把在家的狀態帶入工作中，如果每個人都是這樣的狀態，企業很快會陷入新的窘境，所以沒有狀態，也不會有好的結果，狀態就是一切。
 
團隊的勢氣決定企業整體的戰斗力，那如何調整陸陸續續回來的團隊成員呢？
 
 
艾銻無限對中小企業有三條建議：
 
第一，重新梳理整個企業的戰略，疫情的發生，是否給你企業帶來了變化？如果有那是什么？是否需要調整自己原有的戰略方向來應對疫情發生后的影響？
 
第二，重新明確每個人的目標和目的，目標就是重回企業的人要干什么？干到什么程度？什么時間可以看到這個結果的發生？目的就是為什么要實現這個目標？這個目標與自己的意義是什么？與企業的意義又是什么？達成了會怎么樣？達不成又會怎么樣？
 
只有清晰這些問題，才會讓回到工作崗位的人快速改變自己的狀態投入到接下來的工作中，只有積極的狀態投入工作才會有積極的成果發生，反之依然。
 
第三，企業高管與員工建立一對一的對話機制，因疫情的影響，每個人心理或多或少都會產生一些內在的變化，作為企業的高層管理人員，最好與企業內部員工一對一的進行溝通，去了解在這個過程中員工受到的影響和產生的變化，以便接下來更好的調整他們的狀態，因為如果他們的心沒有回來，企業的要求和制度帶來的也都是大家沒有能量的重復和機械的工作，最終也很難帶來好的結果。
 
以上三點是企業管理者需要重視的，當然身為企業的一員無論是誰也都需要重新審視自己的狀態，因為這關系著企業接下來的生、死、存、亡，能量是企業持續發展的源泉，以上所有的目的都是為了聚合企業人的能量，重新點燃大家面對工作的激情和信心，這將是企業至勝的法定。
 
當然這只是我們一家之言，每家企業可根據自身的情況做出相應的調整和改變。
 
以上三點做為每一家企業的管理者都有必要重視起來，因為這關系著企業接下來的生、死、存、亡，當然這只是我們一家之言，可根據自身的情況做出相應的調整和改變。
 
那為什么我們會有這樣的思考，因為艾銻無限是一家企業互聯網”云”解決方案服務平臺，企業在初創時經歷了2003年的非典，后來又經歷了2008年的經濟危機以及2016年互聯網創業大潮，生生死死，幾經沉浮，最終發現上述三點是生死線中最重要的，所以愿意分享給大家，期望這次疫情大家不僅能渡過難關，更能看見大家在這個過程中強而有力的領導力，讓自己企業力挽狂瀾，讓自己的工作更上一層樓，讓自己的生活在2020年更精彩。
 
在這次疫情后各個企業恢復的過程中，艾銻無限還能為大家做的就是免費為中小企業提供相應的IT服務，以下是艾銻無限可以提供服務的內容，如果大家有相應的需求，可以打下面的電話與我們的企業相關人員聯系，我們一定會盡全力幫助大家渡過難關。
   
 
歷經10幾年,艾銻無限服務了5000多家中小企業并保障了幾十萬臺設備的正常運轉，積累了豐富的企業IT緊急問題和特殊故障的解決方案，我們為您的企業提供的IT服務分為三大版塊:
 
第一版塊是保障性IT外包服務:如電腦設備運維，辦公設備運維，網絡設備運維，服務器運維等綜合性企業IT設備運維服務。
 
第二版塊是功能性互聯網外包服務:如網站開發外包，小程序開發外包，APP開發外包，電商平臺開發外包，業務系統的開發外包和后期的運維外包服務。
 
第三版塊是增值性云服務外包:如企業郵箱上云，企業網站上云，企業存儲上云，企業APP小程序上云，企業業務系統上云，阿里云產品等后續的云運維外包服務。
   
更多服務也可以登錄艾銻無限的官網: www.bjitwx.com 查看詳細說明。

每家企業都有著不同的人，每個人都有著不一樣的思考，所以企業不需要統一所有人的思維，企業只需要統一所有人的心，因為只要心在一起了，能量就會合一，能量合一企業將無所不能。
 
相信這次疫情帶給中國企業的不僅僅是災難，更有可能的是歷練，這幾年經濟發展如此快速，大部分中小企業的成長都是隨著國家政策及整個社會的大勢起來的，沒有經過太多的挑戰和困難，所以存活周期也會很短，從2016年大眾創業，萬眾創新倡導下成立了上千萬家企業，但真正存活下來的就只有幾萬家，這樣的結果即不能給國家帶來穩定持續發展的動力，也不能為社會創造更大的價值，反而讓更多的人投機取巧，心浮氣躁，沉不下來真正把一件事做好，做到極致。
 
所以這次疫情也會讓大部分企業重新思考，問問自己，為什么要創立這家企業，想為這個國家和社會帶來的是什么？企業真正在創造的是什么？如何做才能讓社會因自己的企業變得更好？.....
 
當企業真正去思考，用心去創造價值的時候，也就是人們幸福快樂的時候，因為再也不用擔心假貨、次貨、買到不好的產品，更不用擔心環境被污染，大氣被破壞，疫情即是一場災難，又是重新成就中國企業的一次機會，讓全世界人覺醒，生命只有一次，我們要如何做才能不枉此生呢？
 
 
你對世界微笑，世界絕不會對你哭，希望大家都能積極樂觀起來，讓自己、自己的家人、自己的企業、還有自己的國家都快樂起來，把焦點、意識、能量放在我們想要什么上，而不是不要的事情上，我相信，就在不久的將來，我們一定會看到一個富強、文明、健康的中國以及一個和諧友愛的世界。
 
萬物同體，能量合一，最后無論你是中小企業，還是大型國有企業，只要你選擇艾銻無限，我們就一定全力以赴幫助大家渡過難關，服務有限，信息無限，透過全體艾銻人的努力，為您收集最有效的IT技術信息，讓您企業更快速解決遇到的IT問題：
 
艾銻知識 | 8種SQL錯誤用法


1. LIMIT 語句
分頁查詢是最常用的場景之一，但也通常也是最容易出問題的地方。比如對于下面簡單的語句，一般 DBA 想到的辦法是在 type, name, create_time 字段上加組合索引。這樣條件排序都能有效的利用到索引，性能迅速提升。
好吧，可能90%以上的 DBA 解決該問題就到此為止。但當 LIMIT 子句變成 “LIMIT 1000000,10” 時，程序員仍然會抱怨：我只取10條記錄為什么還是慢？要知道數據庫也并不知道第1000000條記錄從什么地方開始，即使有索引也需要從頭計算一次。出現這種性能問題，多數情形下是程序員偷懶了。在前端數據瀏覽翻頁，或者大數據分批導出等場景下，是可以將上一頁的最大值當成參數作為查詢條件的。SQL 重新設計如下： 在新設計下查詢時間基本固定，不會隨著數據量的增長而發生變化。
 
2. 隱式轉換
SQL語句中查詢變量和字段定義類型不匹配是另一個常見的錯誤。比如下面的語句： 其中字段 bpn 的定義為 varchar(20)，MySQL 的策略是將字符串轉換為數字之后再比較。函數作用于表字段，索引失效。上述情況可能是應用程序框架自動填入的參數，而不是程序員的原意。現在應用框架很多很繁雜，使用方便的同時也小心它可能給自己挖坑。
 
3. 關聯更新、刪除
雖然 MySQL5.6 引入了物化特性，但需要特別注意它目前僅僅針對查詢語句的優化。對于更新或刪除需要手工重寫成 JOIN。 比如下面 UPDATE 語句，MySQL 實際執行的是循環/嵌套子查詢（DEPENDENT SUBQUERY)，其執行時間可想而知。
 
執行計劃：重寫為 JOIN 之后，子查詢的選擇模式從 DEPENDENT SUBQUERY 變成 DERIVED，執行速度大大加
快，從7秒降低到2毫秒 執行計劃簡化為：


 
4. 混合排序
MySQL 不能利用索引進行混合排序。但在某些場景，還是有機會使用特殊方法提升性能的。 執行計劃顯示為全表掃描： 由于 is_reply 只有0和1兩種狀態，我們按照下面的方法重寫后，執行時間從1.58秒降低到2毫秒。
5. EXISTS語句
MySQL 對待 EXISTS 子句時，仍然采用嵌套子查詢的執行方式。如下面的 SQL 語句： 執行計劃為： 去掉 exists 更改為 join，能夠避免嵌套子查詢，將執行時間從1.93秒降低為1毫秒。
新的執行計劃： 6. 條件下推
外部查詢條件不能夠下推到復雜的視圖或子查詢的情況有：

• 聚合子查詢；
• 含有 LIMIT 的子查詢；
• UNION 或 UNION ALL 子查詢；
• 輸出字段中的子查詢；

如下面的語句，從執行計劃可以看出其條件作用于聚合子查詢之后 確定從語義上查詢條件可以直接下推后，重寫如下： 執行計劃變為：  
7. 提前縮小范圍
先上初始 SQL 語句： 數為90萬，時間消耗為12秒。 由于最后 WHERE 條件以及排序均針對最左主表，因此可以先對 my_order 排序提前縮小數據量再做左連接。SQL 重寫后如下，執行時間縮小為1毫秒左右。 再檢查執行計劃：子查詢物化后（select_type=DERIVED)參與 JOIN。雖然估算行掃描仍然為90萬，但是利用了索引以及 LIMIT 子句后，實際執行時間變得很小。
8. 中間結果集下推
 
再來看下面這個已經初步優化過的例子(左連接中的主表優先作用查詢條件)： 那么該語句還存在其它問題嗎？不難看出子查詢 c 是全表聚合查詢，在表數量特別大的情況下會導致整個語句的性能下降。其實對于子查詢 c，左連接最后結果集只關心能和主表 resourceid 能匹配的數據。因此我們可以重寫語句如下，執行時間從原來的2秒下降到2毫秒。 但是子查詢 a 在我們的SQL語句中出現了多次。這種寫法不僅存在額外的開銷，還使得
整個語句顯的繁雜。使用 WITH 語句再次重寫：  
總結
數據庫編譯器產生執行計劃，決定著SQL的實際執行方式。但是編譯器只是盡力服務，所有數據庫的編譯器都不是盡善盡美的。上述提到的多數場景，在其它數據庫中也存在性能問題。了解數據庫編譯器的特性，才能避規其短處，寫出高性能的SQL語句。程序員在設計數據模型以及編寫SQL語句時，要把算法的思想或意識帶進來。編寫復雜SQL語句要養成使用 WITH 語句的習慣。簡潔且思路清晰的SQL語句也能減小數據庫的負擔 。