充值提現mysqllock欄位的簡單介紹

本文目錄一覽：

• 1、如何修改 Mysql 表 的屬性（將只讀改為可讀寫），只改表不改庫
• 2、請教一個MYSQL中死鎖的問題
• 3、Mysql 幻讀&Next Key Lock詳解

如何修改 Mysql 表 的屬性（將只讀改為可讀寫），只改表不改庫

如果是sqlserver資料庫，其實對於某列上不存在不讓修改的說法，sqlserver資料庫數據控制原理是角色控制，也就是說我們對於某一個角色去下定義，讓隸屬於這個角色的用戶不能夠更新數據。或者在某個角色的基礎上不分配或是回收對某一列的許可權!如果是這種情況，用一個能修改的角度登陸才行。

還有另一種就是所謂的觸發器，一旦發現你修改，立即返回原數據，這樣你也是永遠修改不了的!這時你要找到那個觸發器，將觸發器刪除後再進行修改，然後加回觸發器即可!

但這兩種情況都是對某一列下的定義(我們稱為鎖定粒度為列)不可能是某一個單元格!

如果你是站在erp管理的基礎上不讓你修改那是十分正常的!

在企業管理器中使用圖形方式(如二樓給的圖)還是語句，則沒有任何的區別!

請教一個MYSQL中死鎖的問題

通過代碼解鎖。

代碼如下  

1set global max_connections=4000;

增加允許的最大連接數，先讓前台網站可以正常工作。

回過頭google ：mysql unauthenticated user

果然，遇到此類問題的人很多，問題在於mysql的反向ip地址解析，配置參數里加上skip-name-resolve就可以。

補充

一、查看進程運行情況（會話1）

代碼如下  

1mysql select id,user,host,db,command,time,state from processlist a;+—-+——+—————–+——————–+———+——+———–+| id | user | host | db | command | time | state|+—-+——+—————–+——————–+———+——+———–+| 40 | root | localhost:14046 | information_schema | Query | 0 | executing|| 39 | root | localhost:13992 | chf | Sleep | 251 ||| 38 | root | localhost:13991 | chf | Sleep | 251 ||+—-+——+—————–+——————–+———+——+———–+3 rows in set (0.00 sec)

二、構造表被鎖現象

1）鎖住表（會話1）

代碼如下  

1mysqlLOCK TABLES chf.disc02 READ;或者–LOCK TABLES chf.disc02 WRITE;

2）執行dml操作（會話2）

代碼如下  

1mysqldelete from chf.disc02 limit 1;–會話處於卡死狀態

3）查詢進程運行情況（會話1）

代碼如下  

1mysql select id,user,host,db,command,time,state from processlist a;+—-+——+—————–+——————–+———+——+———–+| id | user | host | db | command | time | state|+—-+——+—————–+——————–+———+——+———–+| 41 | root | localhost:14358 | chf | Query | 5 | Locked|| 40 | root | localhost:14046 | information_schema | Query | 0 | executing|| 39 | root | localhost:13992 | chf | Sleep | 343 ||| 38 | root | localhost:13991 | chf | Sleep | 343 ||+—-+——+—————–+——————–+———+——+———–+

4 rows in set (0.01 sec)

說明：發現進程id為41的進程狀態為Locked

三、解鎖操作

1）刪掉被鎖進程（會話1）

代碼如下  

1mysql kill 41;

出現現象（會話2）

ERROR 2013 (HY000): Lost connection to MySQL server during query

2）查看進程（會話1）

代碼如下  

1mysql select id,user,host,db,command,time,state from processlist a;+—-+——+—————–+——————–+———+——+———–+| id | user | host | db | command | time | state|+—-+——+—————–+——————–+———+——+———–+| 40 | root | localhost:14046 | information_schema | Query | 0 | executing|| 39 | root | localhost:13992 | chf | Sleep | 298 ||| 38 | root | localhost:13991 | chf | Sleep | 298 ||+—-+——+—————–+——————–+———+——+———–+3 rows in set (0.01 sec)

四、批量解鎖

代碼如下  

1mysql select concat(『kill 『,id,』;’) kill_process from processlist a where a.state=』Locked』;+————–+| kill_process |+————–+| kill 43; || kill 42; |+————–+2 rows in set (0.01 sec)

Note：

1）可以使用show processlist查看當前用戶連接

如果是root帳號，你能看到所有用戶的當前連接。如果是其它普通帳號，只能看到自己佔用的連接。show processlist;只列出前100條，如果想全列出請使用show full processlist;

2）在構造鎖的會話中，使用unlock tables;也可以解鎖

總結一下原因，大概如下：

因為mysql默認會根據客戶端的ip地址反向解析，用於用戶登錄授權之用。不過正常情況下，很少會有人這樣用。ip地址反向解析是很慢的，尤其是高負荷的mysql，每秒種幾百次甚至更高的請求，這個請求壓到本地的dns伺服器上，dns伺服器說不定會懷疑你在惡意請求，然後不理你了，然後這些登錄請求就掛在那裡，後面的連接還持續，然後越積越多，然後就達到mysql的最大連接數據限制了，然後新的連接就直接被拒，得到連接數過多的消息。

因為mysql配置文件使用的之前的配置文件，當時跟web同伺服器，所以不存在這個問題。

這也正好解釋了為什麼phpMyAdmin里看mysqld狀態時，有很多失敗的連接，它們應該就是因反解析失敗而被拒的。

參考資料

MySQL解鎖.壹聚教程[引用時間2018-1-21]

Mysql 幻讀&Next Key Lock詳解

幻讀的定義是指，一個事務開啟後，執行前後兩次查詢，兩次查詢中出現了新的數據，幻讀僅針對數據的新增。

比如： 表t中，id為主鍵，目前有數據1,5,10,20四條。

開始一個事務A，前後兩次執行 select * from t where id 10 for update;

開啟一個事務B，在事務A第二次執行查詢前，執行insert into t values( 2,…); 並提交事務（請暫時忽略這裡能否成功執行！）。

此時在RC、RR隔離級別下都會導致事務A第二次查詢能夠查詢到 事務B新增的數據 id = 2。

RC級別下能夠看到不同結果就不做解釋了。

對於RR隔離級別下，有了MVCC版本控制為什麼還能讀取到不同的結果呢？

這裡要歸功於 “for update”。

“for update” 會將快照讀變為當前讀，在當前讀場景中，會自動讀取最新的數據，而非快照數據。

分析一下，鎖與當前讀關係。了解什麼情況下會加鎖。了解 意向鎖、共享鎖、排它鎖區別及各自在什麼情況下使用。

行鎖的概念都清楚，這裡就不做補充了。

間隙鎖實際上是指一個區間。

我們都知道，InnoDB 在RR事務隔離級別下解決幻讀問題就是通過Next Key Lock (間隙鎖+行鎖)來實現的。而且，很多地方也有提到，如果對於讀一致性要求不高的場景可以考慮使用RC隔離級別，允許幻讀的發生。

還是上邊說的那個實例，略微改動：

比如： 表t中，id為主鍵，目前有數據1,5,10,20四條。

開始一個事務A，前後三次分別執行

開啟一個事務B，在事務A執行update前，執行insert into t values( 2,…); 並提交事務。

此時我們知道，事務A中第二次查詢能夠查到 事務B新增的數據，也就是產生了幻讀。那麼，按照SQL執行的順序來說，事務B