标準結構化查詢語言(Structured Query Language)簡稱SQL，sql是我們日常工作中使用最多一項技能，寫sql可以說是一個可以幹到退休的技能。看似簡單，但要精通卻很難。 經過我與小夥伴交流，發現來自基層的小夥伴技術水準普遍不高，在處理一個問題時候，經常會岀現“卡殼“現象。市面關于這種HIT真正實用技術幹貨，實在很難尋覓！
實在有必要重寫一遍，全面提升大家sql能力。sql包括增、删、改、查，建立表、删除表、修改表等等内容，我們今天所講的sql是一種狹義上select語句，這個使用最頻繁，也是最複雜的。寫一篇關于技術類的文章，既要深刻，又要通俗易懂，的确要耗費我不少精力，如果大家覺得此文對你或者有需要的人有所幫助，歡迎您轉發！
關于MySQLnote.youdao.com
一、sql會不會淘汰？
大家滿懷熱情點進來學習一下sql，首先要搞清楚一個問題，sql會淘汰嗎？要回答這個問題，首先有必要了解sql發展背景，它是關系型資料庫誕生的産物，有時候不得不佩服這些先輩，當關系型資料庫起步發展的時候，就制定了一個統一的操作标準，就是SQL标準，所有關系型資料庫（mysql/mssql/oracle）都會實作這個标準，這也是為什麼sql會常勝不衰的原因，是以sql會不會淘汰，要看關系型資料庫會不會淘汰？到目前為止沒有看到任何關系型資料庫淘汰的迹象，傳統關系型資料庫過渡到分布式關系型資料庫，這是未來極有可能發生的事。
你可能會問市面不是有一個nosql的東西？首先nosql翻譯成中文，不是”沒有sql“的意思，而是”不僅僅有sql，還有其它“，nosql是not only sql的簡稱。nosql說的一種補充，什麼意思，sql主要處理結構化的資料，nosql主要處理非結構化的資料。目前來說nosql沒有一個統一的标準，都是按照用途來發展，比如鍵值(Key-Value)存儲資料庫， Redis；列存儲資料庫，Cassandra；文檔型資料庫， MongoDb；圖形(Graph)資料庫，Neo4J。
二、什麼是IT高手
紮實理論基礎知識，這是決定一個人水準飛得有多高。靈活運用這個基礎知識（非常難），才決定一個人水準有多牛。為什麼我會說經常出現”卡殼“現象，有些看上去很難的問題，其實運用一些基礎知識就可以解決，但是要做這一點非常困難。
我們通常對高手定義都是可以處理日常工作中一些難題，注意我說的是一些難題，不要期望解決所有的難題，什麼是日常工作的難題？
特點一：問題偶然出現，無法重制問題；
特點二，沒有明顯的邏輯錯誤，沒有解決問題思路；
特點三：問題本身就很難（比如資料結構與算法）。比如，HIS裡面醫技系統就有這樣一個難題一直無法解決，護士錄入A代碼記錄，背景偶然間會儲存B代碼記錄，半年時間偶然出現1，2次，但是我們在HIS程式裡面各種極端操作測試，始終無法重制問題，實在令人不解！
在這裡我分享一下曾經處理過難題，你會驚訝的發現，解決問題的方法很簡單，都是用的最基本的基礎知識解決的，但是你想到這種解決方法，非常不易！
第一個問題：使用netbeans開發環境，在書寫js函數queryStr的時候，按ctrl+shift+F格式化代碼的時候，偶然會出現結構混亂，有時候發現導航器js未出現這個函數，如下圖所示：
問題原因： 原來js代碼與html在同一個檔案來寫的，原來在queryStr函數是包含動态生成html代碼的片斷，雖然這個代碼放變量指派裡面，在格式化的時候，netbeans依然會檢測這個html是否合法，導緻縮進混亂，和導航器分析不出這個函數。我個人猜測格式化的底層實作，将整個文檔解析，解析html标簽，即便html标簽寫在js字元串變量裡面，如果沒有完整配對，依然會出問題。
解決方法：保證queryStr涉及的html字元完整，并且裡面提及的函數必須聲明出來。
第二個問題：下面來分享mysql bug。通過mysqldump導出來sql腳本，測試還原過程中，出現[Err] 1064錯誤，跟蹤到是以下語句出錯，百思不得其解，當時寫進資料庫沒有任何問題，為什麼導出來，再導進去的時候就報錯。
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''
質控科劉成章要求統計2018.04.01---2018-06-30門診醫生的收' at line 9
可能存在的原因：
UPDATE `info`.`fh_comm_detail` set `cl_proc` = ‘.....’ WHERE (`mxid` = '100005')
cl_proc後面的值當中包含注釋符号,mysql去解析的時候，觸發bug，原本包含在‘’中字元串含義發生變化，導緻語句報錯。（但是我在mysql查詢分析器，怎麼樣都模拟不出來這種錯誤，就是偶然發生）。
解決方法：将/*注釋符号替換為其他字元即可，比如”--”，讓其不觸發解析注釋串。
問題三：聯網醫保金額與本地程式計算，有少數患者偶爾會存在金額不一緻問題。翻看程式代碼左看右看，都沒有問題，如下所示。
lc_jine_sum = round(tab_1.tabpage_1.dw_1.getitemnumber(1,"jine_total"),2)
問題原因：我突然想起一個基礎知識，計算機浮點數本身是不準确的，每次運算都有可能得出不同的結果，既然不準确，為什麼我們還會大規模使用計算機來解決問題，解決方法就是提高計算機處理精度，讓它無限逼近準确。什麼意思，我們大部分現實當中，大部分都是計算到2位小數，最多也是4位小數，但是計算機就無所謂，10-20位都可以處理，10-20位小數精度再截取2-4位小數，當然就可以做到準确無誤。大家是否遇到過這種問題，明明隻有一位小數，把這些數字加起來的時候，你會看到一長串小數，這就是計算機内部使用高精度計算的問題，如下圖所示。
計算機内部使用高精度的小數（一般是10幾位以上），來解決小數不準确的問題。是以我當時就把代碼改了一下，果然改完以後，問題從此沒有出現過。這就是利用基礎知識去解決實際當中的難題，你看得我寫的很簡單，其實想到這個方法是非常困難的。
lc_jine_sum =round(tab_1.tabpage_1.dw_1.getitemnumber(1,"jine_total"),4) //先取出 4 位小數
lc_jine_sum = round(lc_jine_sum,2) //再進行 2 位小數四舍五入
三、解決一個sql問題基本思路
日常工作sql語句主要用途，臨時統計資料、背景查數找問題原因、制作報表。拿到一個sql語句的問題首先我們先從業務角度分析，背景是否存在資料，它們是否存在相應關聯？沒有資料，沒有關聯，後繼工作亳無意義。
舉例說明，患者用藥追蹤，統計患者用了哪個廠家哪個批次的藥品。統計的意義，如果發藥哪個批次有問題，可以精準找到相關患者。第一個問題，背景有資料嗎，有的。his裡面基本上都有藥品出入庫、患者用藥資料，但是藥品管理的廠家、批次，與患者用藥之間沒有關聯。這也是his系統裡面的一個難題，目前我還沒有看到靠譜的解決方案。由上述可以得知，患者用藥追蹤，這個問題無法用sql解決。
其次，通常你拿到一個稍微複雜sql問題一般不能一步到位寫出來。别操之過急，學會化解問題。舉例說明，統計曆史連續某段時間内每日在院人數，假設his系統中沒有生成資料（每天将在院人數資料拷貝生成一個中間表資料）。
第一步分解：假設你現在統計曆史某日（2020-03-01）的在院人數，在院人數 = (入院日期 <= 在院人數 <= 出院日期) + 一直未出院的在院人數。
第二步分解：模拟生成連續某段時間，比如2020-03月份，再關聯生成每日在院人數
最後，需要驗證統計出來的資料是否正确，經過驗證，統計出來的曆史在院資料是完全正确的，發現有個别出現1，2個人的誤差，是因為人為修改了”入院日期“，”出院日期“所緻，如果你想檢驗sql水準怎麼樣，我給你一個判斷标準，是否使用了中間表。嚴格來說，隻要資料庫存在資料，存在關聯，就可以用sql語句查出來，如果你精通sql是不會用到中間表的。
本文到此結束，還有下部分内容明天更新，感興趣的小夥伴可以點個關注哈
在這裡分享一下我平時學習MySQL的資料，希望能幫到有需要的小夥伴
MySQL資料詳情note.youdao.com