MYSQL 有些軟件設計，我不知道你怎麼想的？
- 2020 年 3 月 8 日
- 筆記
事情是這樣的，公司裏面有一個買來的軟件，（軟件公司名，功能就不提了，以免讓人家不快，雖然能把軟件寫成這樣，也值得曝光）。
公司裏面的別的IT 部門的員工，問我這個MYSQL 怎麼這麼不穩定，一會兒有數據，一會兒沒數據，這個東西不穩定呀。OK MYSQL 不穩定，MYSQL 不穩定去年人家是NO1 好吧。但是不能流露出某些表情，"內存"的活動還是留在心裏最好。
將他給我的mysql以及相關的表進行了一個初步的人肉的測試，發現的確是查詢一個表，有的時候有數據庫，有的時候沒數據，好怪，心裏一萬隻，可愛的神獸。
具體的情況是，一個數據庫某些表，一會兒查詢數據庫的某張表可以select 出來數據，一會不可以select 出來數據，不可以select 數據表給出的結果是 empty set.
這不科學呀！到底是怎麼回事。
當前情況與分析問題
1 當前的數據庫表，的確是有時無法訪問到數據庫表，有時的時候可以訪問數據
2 其他的表有的時候也有類似情況
3 能查詢數據和不能查詢數據的時間間隔不固定
根據上面的問題，去查看錯誤日誌，也是沒有收穫，說明mysql並沒有因為嚴重的錯誤，而造成系統性的錯誤，所以先將MYSQL本身有問題的可能性排除，或降低到較低的水平。
那可能的錯誤的位置在應用層，正常的命令導致錯誤的事情也不少見，看看到底這個MYSQL 服務器承接了什麼操作？？？打開genernal log 一段時間，通過查看裏面的執行的語句，發現了有點意思。
下面是模擬這個MYSQL 服務器上所遭受的「挫折」 （或許僅僅是部分的）
先創建一個庫，然後生成 3 – 4 個這樣的存儲過程（其實用python寫更好）
存儲過程是一樣的，只不過存儲過程的名字， 創建數據表的名字，以及 replace into 數據的表名都要更改。然後一起運行（也可以多個存儲過多往一個表裏面寫，但我沒有這麼做）。
下面有三張表分別叫 big_data big_data1 big_data2
三個存儲過程，myproc() myproc1() myproc2() 裡邊除了表名不同其他都一樣
然後執行三個存儲過程，存儲過程在執行的時候，明顯 big_data 數據可以查詢，但big_data1 的表只能查出一條數據， big_data2 表乾脆就反饋empty set
首先我不大理解的是通過genernal log 查看，為什麼這個軟件一直要在數據庫裏面執行
set global autocommit = 0 ; replace into xxxx ; set global autocommit = 1; 整體數據庫的 commit 全部亂套了。
導致查詢數據庫的 autocommit 一會兒on 一會 off
可能用存儲過程來模擬軟件，還是缺乏嚴謹性，因為軟件裏面的一些架構或者設置在存儲過程裏面是沒有辦法設置的，模擬的。但實際上，一個軟件在出廠的時候，難道不應該做一下測試，發現一些問題。
單線程可能不會出現任何問題，只要一併發，多線程，事情就變得越發的複雜，很可能就遠超，腦洞可控的範圍。
另外我懷疑是拿ORACLE 裏面不自動commit 的概念用到了 mysql 裏面，這裡四大數據庫，只有ORACLE 一個奇葩默認是自己不commit 其他的數據庫 MYSQL , POSTGRESQL , SQL SERVER ，全部默認是自動提交。另外如果從事務的角度看，如果想批量插入數據一次性commit 也是可以理解的，但單條語句也沒有必要這樣操作，所以這個軟件的腦洞，我實在是不理解。
當然上面的測試從嚴謹性來說，還有很多問題存在，例如一會有數據，一會沒數據，從gernal log 裏面也看到，除了插入數據，同時也在delete 數據那些被查詢的表，具體是怎麼個邏輯，估計只有設計者明白。
借用三體裏面的概念， 我這個問題的發現，解決者站在二位空間努力了半天，解決發現問題，人家軟件的開發者，在三維的空間，大筆一揮就讓我暈頭轉向，這屬於降維打擊，不科學。（軟件是多線程並發處理，而general log 只能給我一個順序性的日誌，所以人家是三維立體，我這看general log 屬於二維空間）
但有一點，MYSQL 不穩定，數據庫有問題，這點 It's totally bull shit
