Java數(shù)據(jù)庫編程總結(jié)，內(nèi)涵視頻教程，數(shù)據(jù)庫我想大家應(yīng)該一點都不陌生吧，我想不管你寫啥的，數(shù)據(jù)庫就算沒用過也聽過了，是我們項目體系里面不可或缺的一環(huán)。
你知道MySQL的基本架構(gòu)么？你能在紙上給我大致畫出這個示意圖么？
好的那我們按照順序了解下，連接器是啥？
我們要進行查詢，第一步就是先去鏈接數(shù)據(jù)庫，那這個時候就是連接器跟我們對接。
他負責(zé)跟客戶端建立鏈接、獲取權(quán)限、維持和管理連接。
鏈接的時候會經(jīng)過TCP握手，然后身份驗證，然后我們輸入用戶名密碼就好了。
驗證ok后，我們就連上了這個MySQL服務(wù)了，但是這個時候我們處于空閑狀態(tài)。
怎么查看空閑連接列表？
showprocesslist，下圖就是我在自己的數(shù)據(jù)庫表執(zhí)行命令的結(jié)果，其中的Command列顯示為Sleep的這一行，就表示現(xiàn)在系統(tǒng)里面有一個空閑連接。
這里需要注意的是，我們數(shù)據(jù)庫的客戶端太久沒響應(yīng)，連接器就會自動斷開了，這個時間參數(shù)是wait_timeout控制住的，默認時長為8小時。
斷開后重連的時候會報錯，如果你想再繼續(xù)操作，你就需要重連了。
這個有個我看過的書本的案例：
一個在政府里的朋友說，他們的系統(tǒng)很奇怪，每天早上都得重啟一下應(yīng)用程序，否則就提示連接數(shù)據(jù)庫失敗，他們都不知道該怎么辦。
按照這個錯誤提示，應(yīng)該就是連接時間過長了，斷開了連接。
數(shù)據(jù)庫默認的超時時間是8小時，而他們平時六點下班，下班之后系統(tǒng)就沒有人用了，等到第二天早上九點甚至十點才上班，這中間的時間已經(jīng)超過10個小時了，數(shù)據(jù)庫的連接肯定就會斷開了。
是的，就是超出了超時時間，然后寫代碼的人也沒注意到這個細節(jié)，所以才會出現(xiàn)這個問題。
把超時時間改得長一點，問題就解決了。
這種參數(shù)其實我們平時不一定能接觸到，但是真的遇到問題的時候，知道每個參數(shù)的大概用法，不至于讓你變成無頭蒼蠅。
那除了重新鏈接，還有別的方式么？因為建立鏈接還是比較麻煩的。
使用長連接。
但是這里有個缺點，使用長連接之后，內(nèi)存會飆得很快，我們知道MySQL在執(zhí)行過程中臨時使用的內(nèi)存是管理在連接對象里面的。
只有在鏈接斷開的時候才能得到釋放，那如果一直使用長連接，那就會導(dǎo)致OOM（OutOfMemory），會導(dǎo)致MySQL重啟，在JVM里面就會導(dǎo)致頻繁的FullGC。
那你會怎么解決？
我一般會定期斷開長連接，使用一段時間后，或者程序里面判斷執(zhí)行過一個占用內(nèi)存比較大的查詢后就斷開連接，需要的時候重連就好了。
還有別的方法么？你這種感覺不優(yōu)雅呀小老弟。
執(zhí)行比較大的一個查詢后，執(zhí)行mysql_reset_connection可以重新初始化連接資源。這個過程相比上面一種會好點，不需要重連，但是會初始化連接的狀態(tài)。
你了解MySQL的查詢緩存么？
MySQL拿到一個查詢請求后，會先到查詢緩存看看，之前是不是執(zhí)行過這條語句。
大家是不是好奇同一條語句在MySQL執(zhí)行兩次，第一次和后面的時間是不一樣的，后者明顯快一些，這就是因為緩存的存在。
他跟Redis一樣，只要是你之前執(zhí)行過的語句，都會在內(nèi)存里面用key-value形式存儲著。
查詢的時候就會拿著語句先去緩存中查詢，如果能夠命中就返回緩存的value，如果不命中就執(zhí)行后面的階段。
但是我還是不喜歡用緩存，因為緩存弊大于利。
哦？此話怎講？
緩存的失效很容易，只要對表有任何的更新，這個表的所有查詢緩存就會全部被清空，就會出現(xiàn)緩存還沒使用，就直接被清空了，或者積累了很多緩存準備用來著，但是一個更新打回原形。
這就導(dǎo)致查詢的命中率低的可怕，只有那種只查詢不更新的表適用緩存，但是這樣的表往往很少存在，一般都是什么配置表之類的。
那我們查詢的時候不想用緩存一般都是怎么操作的，或者是用緩存又怎么操作？
可以顯示調(diào)用，把query_cache_type設(shè)置成為DEMAND，這樣SQL默認不適用緩存，想用緩存就用SQL_CACHE。
有個小技巧就是，我們之前開發(fā)的時候，都會去庫里看看sql執(zhí)行時間，但是可能是有緩存的，一般我們就在sql前面使用SQL_NO_CACHE就可以知道真正的查詢時間了。
selectSQL_NO_CACHE*fromB
緩存在MySQL8.0之后就取消了，所以大家現(xiàn)在應(yīng)該不需要太關(guān)注這個問題，主要是我之前用的版本都不高，所以緩存一直有，在《高性能MySQL》書中也看到了一些關(guān)于緩存的介紹，就想起來給大家也提一下了。
緩存查詢完了應(yīng)該做啥呢？
在緩存沒有命中的情況下，就開始執(zhí)行語句了，你寫的語句有沒有語法錯誤，這是接下來MySQL比較關(guān)心的點。
那他會怎么做呢？會先做詞法分析，你的語句有這么多單詞、空格，MySQL就需要識別每個字符串所代表的是什么，是關(guān)鍵字，還是表名，還是列名等等。
然后就開始語法分析，根據(jù)詞法分析的結(jié)果，語法分析會判斷你sql的對錯，錯了會提醒你的，并且會提示你哪里錯了。
分析沒錯之后就進入下一步，優(yōu)化器。
主要是優(yōu)化什么呢？
優(yōu)化就比較簡單了，因為我們建立表可能會建立很多索引，優(yōu)化有一步就是要確認使用哪個索引，比如使用你的主鍵索引，聯(lián)合索引還是什么索引更好。
還有就是對執(zhí)行順序進行優(yōu)化，條件那么多，先查哪個表，還是先關(guān)聯(lián)，會出現(xiàn)很多方案，最后由優(yōu)化器決定選用哪種方案。
最后就是執(zhí)行了，執(zhí)行就交給執(zhí)行器去做。
第一步可能就是權(quán)限的判斷，其實這里我不確定的一個點就是，我接觸的公司很多都是自研的線上查詢系統(tǒng)，我們是不能用Navicat直連線上庫，只能去網(wǎng)頁操作，那表的權(quán)限是在MySQL層做的，還是系統(tǒng)做的，我猜應(yīng)該是系統(tǒng)層做的，MySQL可能默認就全開放了，只是我們不知道ip。
執(zhí)行的時候，就一行一行的去判斷是否滿足條件，有索引的執(zhí)行起來可能就好點，一行行的判斷就像是接口都提前在引擎定義好了，所以他比較快。
數(shù)據(jù)庫的慢日志有個rows_examined字段，掃描多少行可以看到，還有explain也可以看到執(zhí)行計劃，我們掃描了多少行。
數(shù)據(jù)庫相關(guān)視頻教程
oracle數(shù)據(jù)庫教程：http://www.bjpowernode.com/v22/
數(shù)據(jù)庫plsql教程：http://www.bjpowernode.com/v23/
jdbc數(shù)據(jù)庫教程：http://www.bjpowernode.com/v24/
數(shù)據(jù)庫mysql教程：http://www.bjpowernode.com/v21
Java實戰(zhàn)項目視頻之egov項目視頻教程【免費下載】：http://www.bjpowernode.com/v83/
Java學(xué)生成績管理系統(tǒng)視頻教程【免費下載】：http://www.bjpowernode.com/v51/
以上就是長沙達內(nèi)教育Java培訓(xùn)機構(gòu)小編介紹的“Java數(shù)據(jù)庫編程總結(jié)，內(nèi)涵視頻教程”的內(nèi)容，希望對大家有幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。
