本著愛扯淡的一貫作風，先講一下為什麼要做個這。。
話說，從某狗實習回來之後，守著實驗室的大offer實在不是咱的作風，所以就跟小伙伴們開始搞一款應用。這款應用的服務器和數據庫這一攤子事兒自然習慣性的被交代給了灑家。閒話不表。卻說某一夜灑家正酣睡，約摸二更時分，被客戶端開發妹子一通電話喚醒，道明原委，原來Mysql數據可能出現異常，需要灑家查明真相。灑家自是百般不情願，但還是連滾帶爬，翻身下地，戳開小本，一探究竟。。
灑家自忖，若是手機可以了解此事，何須如此周折。。。
何必重復造輪子？於是谷歌一番，不料竟無一app可令android手機操作Mysql。神傷啊。。
這可如何是好？
思忖良久，如何模擬cmd搞一個mysql命令行？開socket連3306？自行解析協議？吾非藍翔出身，恐難以勝任呀。也是天命所歸，此時灑家正翻騰服務器代碼，一眼瞄上了Spring jdbc。若使jdbc連接mysql，便可省去一番協議之事，真乃得來全不費工夫也。
灑家既然決定用Spring jdbc搞定此時，定然琢磨android端如何用得起服務器框架。實驗幾番，不想Spring核心因為Java庫文件與android沖突而不能使用。煩惱煩惱。既然如此，也省的費事，想想Spring jdbc不過也是jdbc的一層封裝，只用Spring jdbc應該無妨吧？試之，果然。
灑家也是醉了。直接利用Spring jdbc企圖做一命令行。也不是不可，最初未使用連接池，使得每次發送的命令都使用不同的連接。因而你想use test（test乃一庫也！），然後select * from t（t乃test庫中表也！），對方答曰：哦抱歉，沒有t這表。
這。。
上個DBCP如何？果然問題得以解決，原因嘛，就是連接沒有釋放罷了。
灑家真的不開心了……灑家如何知道您那數據庫服務器有撒子庫嘛。想來想去，只好默認為jdbc url配置庫名為information_schema了，客官如有特殊需求，還請自便吶！
灑家知道，無圖無真相。頁面沒有那麼有美感。別挑哈。
服務列表，客官可以在此編輯自己的服務器信息。灑家把這些信息存到了客官手機的sqlite當中了，灑家才不想要你的密碼呢。
客官，如果您只是來圍觀的，勸您就選簡易模式吧。
數據那一頁可是能夠拖動的哈！上下左右，毫無壓力！
命令行模式就是客官熟悉的模式了！在此，為了方便客官輸入命令，灑家提供了以下便捷的方式！
按'mysql' 即可呼出歷史記錄列表~~
其實程序的主體功能是灑家在回家的那次火車上搞出來的，火車上真無聊。。
千萬不要開啟混淆，因為混淆會導致連接失敗。為啥？灑家最近面試太多，累，不想管。。
