Java數據庫編程總結教程，數據庫我想大家應該一點都不陌生吧，我想不管你寫啥的，數據庫就算沒用過也聽過了，是我們項目體系裏面不可或缺的一環。
你知道MySQL的基本架構麼？你能在紙上給我大致畫出這個示意圖麼？
好的那我們按照順序瞭解下，連接器是啥？
我們要進行查詢，第一步就是先去鏈接數據庫，那這個時候就是連接器跟我們對接。
他負責跟客户端建立鏈接、獲取權限、維持和管理連接。
鏈接的時候會經過TCP握手，然後身份驗證，然後我們輸入用户名密碼就好了。
驗證ok後，我們就連上了這個MySQL服務了，但是這個時候我們處於空閒狀態。
怎麼查看空閒連接列表？
showprocesslist，下圖就是我在自己的數據庫表執行命令的結果，其中的Command列顯示為Sleep的這一行，就表示現在系統裏面有一個空閒連接。
這裏需要注意的是，我們數據庫的客户端太久沒響應，連接器就會自動斷開了，這個時間參數是wait_timeout控制住的，默認時長為8小時。
斷開後重連的時候會報錯，如果你想再繼續操作，你就需要重連了。
這個有個我看過的書本的案例：
一個在政府裏的朋友説，他們的系統很奇怪，每天早上都得重啓一下應用程序，否則就提示連接數據庫失敗，他們都不知道該怎麼辦。
按照這個錯誤提示，應該就是連接時間過長了，斷開了連接。
數據庫默認的超時時間是8小時，而他們平時六點下班，下班之後系統就沒有人用了，等到第二天早上九點甚至十點才上班，這中間的時間已經超過10個小時了，數據庫的連接肯定就會斷開了。
是的，就是超出了超時時間，然後寫代碼的人也沒注意到這個細節，所以才會出現這個問題。
把超時時間改得長一點，問題就解決了。
這種參數其實我們平時不一定能接觸到，但是真的遇到問題的時候，知道每個參數的大概用法，不至於讓你變成無頭蒼蠅。
那除了重新鏈接，還有別的方式麼？因為建立鏈接還是比較麻煩的。
使用長連接。
但是這裏有個缺點，使用長連接之後，內存會飆得很快，我們知道MySQL在執行過程中臨時使用的內存是管理在連接對象裏面的。
只有在鏈接斷開的時候才能得到釋放，那如果一直使用長連接，那就會導致OOM（OutOfMemory），會導致MySQL重啓，在JVM裏面就會導致頻繁的FullGC。
那你會怎麼解決？
我一般會定期斷開長連接，使用一段時間後，或者程序裏面判斷執行過一個佔用內存比較大的查詢後就斷開連接，需要的時候重連就好了。
還有別的方法麼？你這種感覺不優雅呀小老弟。
執行比較大的一個查詢後，執行mysql_reset_connection可以重新初始化連接資源。這個過程相比上面一種會好點，不需要重連，但是會初始化連接的狀態。
你瞭解MySQL的查詢緩存麼？
MySQL拿到一個查詢請求後，會先到查詢緩存看看，之前是不是執行過這條語句。
大家是不是好奇同一條語句在MySQL執行兩次，第一次和後面的時間是不一樣的，後者明顯快一些，這就是因為緩存的存在。
他跟Redis一樣，只要是你之前執行過的語句，都會在內存裏面用key-value形式存儲着。
查詢的時候就會拿着語句先去緩存中查詢，如果能夠命中就返回緩存的value，如果不命中就執行後面的階段。
但是我還是不喜歡用緩存，因為緩存弊大於利。
哦？此話怎講？
緩存的失效很容易，只要對錶有任何的更新，這個表的所有查詢緩存就會全部被清空，就會出現緩存還沒使用，就直接被清空了，或者積累了很多緩存準備用來着，但是一個更新打回原形。
這就導致查詢的命中率低的可怕，只有那種只查詢不更新的表適用緩存，但是這樣的表往往很少存在，一般都是什麼配置表之類的。
那我們查詢的時候不想用緩存一般都是怎麼操作的，或者是用緩存又怎麼操作？
可以顯示調用，把query_cache_type設置成為DEMAND，這樣SQL默認不適用緩存，想用緩存就用SQL_CACHE。
有個小技巧就是，我們之前開發的時候，都會去庫裏看看sql執行時間，但是可能是有緩存的，一般我們就在sql前面使用SQL_NO_CACHE就可以知道真正的查詢時間了。
selectSQL_NO_CACHE*fromB
緩存在MySQL8.0之後就取消了，所以大家現在應該不需要太關注這個問題，主要是我之前用的版本都不高，所以緩存一直有，在《高性能MySQL》書中也看到了一些關於緩存的介紹，就想起來給大家也提一下了。
緩存查詢完了應該做啥呢？
在緩存沒有命中的情況下，就開始執行語句了，你寫的語句有沒有語法錯誤，這是接下來MySQL比較關心的點。
那他會怎麼做呢？會先做詞法分析，你的語句有這麼多單詞、空格，MySQL就需要識別每個字符串所代表的是什麼，是關鍵字，還是表名，還是列名等等。
然後就開始語法分析，根據詞法分析的結果，語法分析會判斷你sql的對錯，錯了會提醒你的，並且會提示你哪裏錯了。
分析沒錯之後就進入下一步，優化器。
主要是優化什麼呢？
優化就比較簡單了，因為我們建立表可能會建立很多索引，優化有一步就是要確認使用哪個索引，比如使用你的主鍵索引，聯合索引還是什麼索引更好。
還有就是對執行順序進行優化，條件那麼多，先查哪個表，還是先關聯，會出現很多方案，最後由優化器決定選用哪種方案。
最後就是執行了，執行就交給執行器去做。
第一步可能就是權限的判斷，其實這裏我不確定的一個點就是，我接觸的公司很多都是自研的線上查詢系統，我們是不能用Navicat直連線上庫，只能去網頁操作，那表的權限是在MySQL層做的，還是系統做的，我猜應該是系統層做的，MySQL可能默認就全開放了，只是我們不知道ip。
執行的時候，就一行一行的去判斷是否滿足條件，有索引的執行起來可能就好點，一行行的判斷就像是接口都提前在引擎定義好了，所以他比較快。