一個併發SQL資料庫卡主了

首先說明這個問題不能怪資料庫。上週遇到一個事情，大家都在討論一個問題，我看沒人@我，我也沒管。直到有人說，讓我去看看她那裡為什麼查詢的比較慢。在處理過程中才發現這個資料庫上活動會話有80多個。難怪慢。背景是這個MySQL記憶體僅4G。（為什麼這麼小，我回答不了）

    看到紅黃框一共10句，是一模一樣的SQL，對一個log表全表排序。其中紅框的兩句幾乎是同一時刻。後面的估計是執行了沒反應繼續點選。而藍框中的SQL是對這個log表全表分組，其實性質一樣。

     查一下現在事務情況，出乎意料。以上的全表排序都卡主了，那麼問題很明顯了。

先處理這些，kill這些執行了幾個小時的SQL。過來幾秒以後，整個資料庫立刻恢復正常了。其他問題在這裡不方便多說了。只是好奇這個全表排序的為什麼有事務？

     單獨找一個資料庫，用MySQL預設的模式（自動提交），進行了幾個大表查詢，然後information.innodb_trx。發現沒有事務。推斷那時候一定是開啟事務了。（故障恢復第一要務是先恢復，沒有辦法追溯是次要的。由於之前設定不完善，很多資訊沒有）這次就只能粗淺的認為查詢開了事務，因為這個表600多M，10併發次查詢，而記憶體就只有4G。加上磁碟的IO效能也不行。諸多因素在一起，然後併發執行資料庫處理不了。透過殺掉長會話得以解決。

    這個配置，這樣用，換哪個資料庫可能或多或少都有點問題。也不排除個別資料庫能抗過去的。還是使用方式方法。

    道理千萬條，安全第一條。資料庫幾百種，規範第一條。開發不規範，運維兩行淚