django數(shù)據(jù)庫連接丟失

　　在Django中使用mysql偶爾會出現(xiàn)數(shù)據(jù)庫連接丟失的情況，錯誤通常有如下兩種

　　1. OperationalError: (2006, 'MySQL server has gone away')

　　1. OperationalError: (2013, 'Lost connection to MySQL server during query')

　　查詢mysql全局變量SHOW GLOBAL VARIABLES;可以看到wait_timeout，此變量表示連接空閑時間。如果客戶端使用一個連接查詢多次數(shù)據(jù)庫，如果連續(xù)查詢則沒有問題，如果查詢幾次后停頓超過wait_timeout后再次查詢就會出現(xiàn)數(shù)據(jù)庫連接丟失。

　　下面用Django復(fù)現(xiàn)下次問題：將mysql的wait_timeout設(shè)置為10秒，然后進(jìn)入django shell模擬查詢（以下錯誤信息只保留了部分）

　　In[1]：import time

　　In[2]：from django.contrib.auth.models import User

　　In[3]：list(User.objects.filter(id=1))

　　Out[3]：[]

　　In[4]：time.sleep(15) # 模擬比較慢的代碼（其中沒有查詢數(shù)據(jù)庫的代碼），或者空閑什么都不操作一段時間，此時間要比`wait_timeout`大一些

　　list(User.objects.filter(id=1))

　　Traceback (most recent call last):

　　File "", line 1, in

　　list(User.objects.filter(id=1))

　　File "/usr/lib/python3.6/site-packages/pymysql/connections.py", line 1037, in _read_bytes

　　CR.CR_SERVER_LOST, "Lost connection to MySQL server during query")

　　django.db.utils.OperationalError: (2013, 'Lost connection to MySQL server during query')

　　那么以上問題就基本說明了是空閑時間過長導(dǎo)致的錯誤。

　　django為了減少不必要的數(shù)據(jù)庫連接、關(guān)閉，復(fù)用了數(shù)據(jù)庫連接，當(dāng)開始一個請求后建立一個連接池存放連接，之后此次請求都復(fù)用一個連接。那猜測就是django保存連接的比wait_timeout長了，如果保存時間短一些就可以重新建立連接避免此錯誤了。 沒錯，官方文檔也已經(jīng)說明了此問題，設(shè)置數(shù)據(jù)庫 CONN_MAX_AGE參數(shù)，示例：

　　DATABASES = {

　　"default": {

　　'ENGINE': 'django.db.backends.mysql',

　　'NAME': '',

　　'USER': '',

　　'PASSWORD': '',

　　'HOST': '',

　　'CONN_MAX_AGE': 9 # 比wait_timeout小一些

　　}

　　}

　　當(dāng)我們測試后卻發(fā)現(xiàn)，事情并非想想中那么簡單。為何錯誤依舊出現(xiàn)？這一切的背后， 是人性的扭曲還是道德的淪喪?敬請收看下節(jié)《突破》。

　　對django源碼中CONN_MAX_AGE進(jìn)行了一番搜索，順藤摸瓜發(fā)現(xiàn)了django關(guān)閉失效連接的方法

　　django.db.close_old_connections()：

　　# Register an event to reset transaction state and close connections past

　　# their lifetime.

　　def close_old_connections(**kwargs):

　　for conn in connections.all():

　　conn.close_if_unusable_or_obsolete()

　　signals.request_started.connect(close_old_connections)

　　signals.request_finished.connect(close_old_connections)

　　重點在最后兩行，通過signal實現(xiàn)特定事件時執(zhí)行此方法，兩個特定事件顧名思義是請求開始和請求結(jié)束。而我們報錯的是在一次請求中，所以此法通常無效，僅僅是實現(xiàn)每個請求關(guān)閉并重新建立連接。

　　復(fù)現(xiàn)問題的django shell不要關(guān)閉，繼續(xù)執(zhí)行如下代碼：

　　In[5]：from django.db import close_old_connections

　　In[6]：close_old_connections()

　　In[7]：list(User.objects.filter(id=1))

　　Out[7]: []

　　調(diào)用

　　django.db.close_old_connections后再次查詢就沒有錯誤了。 那么我們要避免此錯誤就要執(zhí)行每個數(shù)據(jù)庫查詢前調(diào)用

　　django.db.close_old_connections方法。一般情況不會出現(xiàn)此類問題，因為一個請求中不間斷進(jìn)行數(shù)據(jù)庫查詢，無需每個請求調(diào)用此方法，杞人憂天。有時候一個請求中數(shù)據(jù)量較大，會查詢數(shù)據(jù)庫后進(jìn)行一段時間其他（不涉及數(shù)據(jù)庫）處理，比如先查詢一些數(shù)據(jù)，然后將數(shù)據(jù)處理、生成excel、保存文件并生成url。已知此過長需要非常長時間，那么最終url保存數(shù)據(jù)庫就最好先調(diào)用django.db.close_old_connections防止連接丟失

　　實際上②所述情況最好從根本上解決處理慢的問題，也可以換作異步處理，從根本上解決問題。

　　django自動重連數(shù)據(jù)庫

　　https://my.oschina.net/watcher/blog/3012223