❶ MYsql使用基礎、進階分享
MySQL是一個關系型資料庫管理系統，由瑞典MySQL AB公司開發，屬於Oracle旗下產品，是最流行的關系型資料庫管理系統之一。
埠是3306。
表很多時，使用linux腳本，需要根據需要修改一下：
和創建一樣，可以加上 if exists
可兩篇文章：
如：
用於在已有的表中添加、刪除或修改列。
添加 ADD
或
默認是添加到最後，但可以指定位置。 FIRST ：添加最前
AFTER 欄位名> ：添加指定欄位之後
例子：
刪除 DROP
修改 MODIFY 主要修改原列的類型或約束條件 同樣可以用 FIRST 和 AFTER 欄位名> ，代表的是修改到哪裡。
修改欄位名 CHANGE
可以把表2的數據復制到表1中，但 不能復制約束性條件 。
單行
多行，注意 只有一個VALUES ：
不寫 (行1, 行2...) 這一部分的話，默認一一對應
除了以上方法外，還可以用SET為每一行附上相應的值。
假如沒有篩選的話，就給全部都修改了。可以用 WHERE 篩選。
假如 沒有篩選的話，就給全部刪除了 。相當於清空。
清空
先把表刪除，然後再建一個。與 DELETE FROM 相比， TRUNCATE 的效率更快，因為 DELETE FROM 是把記錄逐條刪除的。
查詢執行的順序
FROM --> WHERE --> SELECT --> GROUP BY --> HAVING --> ORDER BY --> LIMIT
注意
當數據很大，上百萬的時候，使用LIMIT ... OFFSET ..的方式進行分頁十分浪費資源且耗時長。最好是結合WHERE使用，如：
REGEXP 使用正則表達進行匹配。 查詢時，需要搭配WHERE或HAVING使用 。
兩個表之間有交集且要用到兩個表的數據時，可以使用內連接查詢。
LEFT JOIN 關鍵字從左表（table1）返回所有的行，即使右表（table2）中沒有匹配。如果右表中沒有匹配，則結果為 NULL。
用法：
RIGHT JOIN 關鍵字從右表（table2）返回所有的行，即使左表（table1）中沒有匹配。如果左表中沒有匹配，則結果為 NULL。 把LEFT JOIN的表1、表2調換順序，就是REGHT JOIN 。
FULL OUTER JOIN 關鍵字只要左表（table1）和右表（table2）其中一個表中存在匹配，則返回行. 相當於結合了 LEFT JOIN 和 RIGHT JOIN 的結果。
但 MySQL中不支持 FULL OUTER JOIN 。
即SELECT嵌套。
IN 一個查詢結果作為另一個查詢的條件。 如：
EXISTS 用於判斷查詢子句是否有記錄，如果有一條或多條記錄存在返回 True，否則返回 False。True時執行。 如：
索引的本質是一種排好序的數據結構。利用索引可以提高查詢速度。
常見的索引有：
MySQL通過外鍵約束來保證表與表之間的數據的完整性和准確性。 外鍵的使用條件：
外鍵的好處：可以使得兩張表關聯，保證數據的一致性和實現一些級聯操作。
對已有的兩個表增加外鍵 比如：主表為A，子表為B，外鍵為aid，外鍵約束名字為a_fk_b
為子表添加一個欄位，當做外鍵
為子表添加外鍵約束條件
假如刪除記錄報錯： [Err] 1451 -Cannot deleteorupdatea parent row: aforeignkeyconstraintfails (...)
這是因為MySQL中設置了foreign key關聯，造成無法更新或刪除數據。可以通過設置 FOREIGN_KEY_CHECKS 變數來避免這種情況。 第一步：禁用外鍵約束，我們可以使用： SETFOREIGN_KEY_CHECKS=0; 第二步：刪除數據 第三步：啟動外鍵約束，我們可以使用： SETFOREIGN_KEY_CHECKS=1; 查看當前FOREIGN_KEY_CHECKS的值，可用如下命令： SELECT @@FOREIGN_KEY_CHECKS;
使用 UNION 來組合兩個查詢，如果第一個查詢返回 M 行，第二個查詢返回 N 行，那麼組合查詢的結果一般為 M+N 行。
每個查詢必須包含相同的列、表達式和聚集函數。
默認會去除相同行，如果需要 保留 相同行，使用 UNION ALL 。
只能包含一個 ORDER BY 子句，並且必須位於語句的最後 。
內置函數很多, 見: MySQL 函數
我們一般使用 START TRANSACTION 或 BEGIN 開啟事務, COMMIT 提交事務中的命令, SAVEPOINT : 相當於設置一個還原點, ROLLBACK TO : 回滾到某個還原點下
一般的使用格式如下:
開啟事務時, 默認加鎖
根據類型可分為共享鎖（SHARED LOCK）和排他鎖（EXCLUSIVE LOCK）或者叫讀鎖（READ LOCK）和寫鎖（WRITE LOCK）。
根據粒度劃分又分表鎖和行鎖。表鎖由資料庫伺服器實現，行鎖由存儲引擎實現。
除此之外,我們可以顯示加鎖
加鎖時, 如果沒有索引，會鎖表，如果加了索引，就會鎖行
InnoDB默認支持行鎖，獲取鎖是分步的，並不是一次性獲取所有的鎖，因此在鎖競爭的時候就會出現死鎖的情況
解決方法:
即ACID特性:
由於並發事務會引發上面這些問題, 我們可以設置事務的隔離級別解決上面的問題.
MySQL的默認隔離級別（可重復讀）
查看當前會話隔離級別
方式1
方式2
設置隔離級別
主從集群的示意圖如下:
主要涉及三個線程： binlog 線程、 I/O 線程和 SQL 線程。
同步流程:
由於MySQL主從集群只會從主節點同步到從節點, 不會反過來同步, 所以需要讀寫分離
讀寫分離需要在業務層面實現 , 寫數據只能在主節點上完成, 而讀數據可以在主節點或從節點上完成
索引是幫助MySQL高效獲取數據的排好序的數據結構
MySQL的索引有
推薦兩個在線工具:
簡單來說, B樹是在紅黑樹(一個平衡二叉樹)的基礎上將一個節點存放多個值, 實現的, 降低了樹的高度, 每個節點都存放索引及對應數據指針, 同一層的節點是遞增的
而B+樹在B樹的基礎上進行優化, 非葉子節點存放 子節點的開始的索引, 葉子節點存放索引和數據的指針, 且葉子節點之間有雙向的指針
如下示意圖:
不同的引擎, 主鍵索引存放的數據也不一樣, 比如常見的 MyISAM 和 InnoDB
MyISAM 的B+樹葉子節點存放表數據的指針, InnoDB 的B+樹葉子節點存放處主鍵外的數據
其他的:
即多個列組成一個索引, 語法:
由於聯合索引的B+樹的結構, 根據列建立, 所以我們的查找條件也要根據索引列的順序( where column1=x, column2=y,columnN... ), 否則會全表掃描
如果你對列進行了 （+，-，*，/，!） , 那麼都將不會走索引。
OR 引起的索引失效
OR 導致索引是在特定情況下的，並不是所有的 OR 都是使索引失效，如果OR連接的是 同 一個欄位，那麼索引 不會失效 ， 反之索引失效 。
這個我相信大家都明白，模糊搜索如果你前綴也進行模糊搜索，那麼不會走索引。
這兩種用法，也將使索引失效。另 IN 會走索引，但是當IN的取值范圍較大時會導致索引失效，走全表掃描, 見: MySQL中使用IN會不會走索引
不走索引。
走索引。
所以設計表的時候, 建議不可為空, 而是將默認值設置為 "" ( NOT NULL DEFAULT "" )
❷ mysql如何用事務和鎖 鎖住某一行數據，使得不允許兩個用戶同時讀取一行數據！！
1、在mysql資料庫中如何鎖定一行數據，保證不被其他的操作影響。
❸ mysql存儲過程出現鎖表鎖行的情況怎麼解決
行鎖的等待
在介紹如何解決行鎖等待問題前，先簡單介紹下這類問題產生的原因。產生原因簡述：當多個事務同時去操作（增刪改）某一行數據的時候，MySQL 為了維護 ACID 特性，就會用鎖的形式來防止多個事務同時操作某一行數據，避免數據不一致。只有分配到行鎖的事務才有權力操作該數據行，直到該事務結束，才釋放行鎖，而其他沒有分配到行鎖的事務就會產生行鎖等待。如果等待時間超過了配置值（也就是 innodb_lock_wait_timeout 參數的值，個人習慣配置成 5s，MySQL 官方默認為 50s），則會拋出行鎖等待超時錯誤。
如上圖所示，事務 A 與事務 B 同時會去 Insert 一條主鍵值為 1 的數據，由於事務 A 首先獲取了主鍵值為 1 的行鎖，導致事務 B 因無法獲取行鎖而產生等待，等到事務 A 提交後，事務 B 才獲取該行鎖，完成提交。這里強調的是行鎖的概念，雖然事務 B 重復插入了主鍵，但是在獲取行鎖之前，事務一直是處於行鎖等待的狀態，只有獲取行鎖後，才會報主鍵沖突的錯誤。當然這種 Insert 行鎖沖突的問題比較少見，只有在大量並發插入場景下才會出現，項目上真正常見的是 update&delete 之間行鎖等待，這里只是用於示例，原理都是相同的。
三、產生的原因根據我之前接觸到的此類問題，大致可以分為以下幾種原因
❹ MySQL資料庫表被鎖、解鎖，刪除事務
在程序員的職業生涯中，總會遇到資料庫表被鎖的情況，前些天就又撞見一次。由於業務突發需求，各個部門都在批量操作、導出數據，而資料庫又未做讀寫分離，結果就是：資料庫的某張表被鎖了！
用戶反饋系統部分功能無法使用，緊急排查，定位是資料庫表被鎖，然後進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點贊收藏，以備不時之需。
用戶反饋某功能頁面報502錯誤，於是第一時間看服務是否正常，資料庫是否正常。在控制台看到資料庫CPU飆升，堆積大量未提交事務，部分事務已經阻塞了很長時間，基本定位是資料庫層出現問題了。
查看阻塞事務列表，發現其中有鎖表現象，本想利用控制台直接結束掉阻塞的事務，但控制台賬號許可權有限，於是通過客戶端登錄對應賬號將鎖表事務kill掉，才避免了情況惡化。
下面就聊聊，如果當突然面對類似的情況，我們該如何緊急響應？
想像一個場景，當然也是軟體工程師職業生涯中會遇到的一種場景：原本運行正常的程序，某一天突然資料庫的表被鎖了，業務無法正常運轉，那麼我們該如何快速定位是哪個事務鎖了表，如何結束對應的事物？
首先最簡單粗暴的方式就是：重啟MySQL。對的，網管解決問題的神器——「重啟」。至於後果如何，你能不能跑了，要你自己三思而後行了！
重啟是可以解決表被鎖的問題的，但針對線上業務很顯然不太具有可行性。
下面來看看不用跑路的解決方案：
遇到資料庫阻塞問題，首先要查詢一下表是否在使用。
如果查詢結果為空，那麼說明表沒在使用，說明不是鎖表的問題。
如果查詢結果不為空，比如出現如下結果：
則說明表（test）正在被使用，此時需要進一步排查。
查看資料庫當前的進程，看看是否有慢SQL或被阻塞的線程。
執行命令：
該命令只顯示當前用戶正在運行的線程，當然，如果是root用戶是能看到所有的。
在上述實踐中，阿里雲控制台之所以能夠查看到所有的線程，猜測應該使用的就是root用戶，而筆者去kill的時候，無法kill掉，是因為登錄的用戶非root的資料庫賬號，無法操作另外一個用戶的線程。
如果情況緊急，此步驟可以跳過，主要用來查看核對：
如果情況緊急，此步驟可以跳過，主要用來查看核對：
看事務表INNODB_TRX中是否有正在鎖定的事務線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個sleep的線程事務一直沒有commit或者rollback，而是卡住了，需要手動kill掉。
搜索的結果中，如果在事務表發現了很多任務，最好都kill掉。
執行kill命令：
對應的線程都執行完kill命令之後，後續事務便可正常處理。
針對緊急情況，通常也會直接操作第一、第二、第六步。
這里再補充一些MySQL鎖相關的知識點：資料庫鎖設計的初衷是處理並發問題，作為多用戶共享的資源，當出現並發訪問的時候，資料庫需要合理地控制資源的訪問規則，而鎖就是用來實現這些訪問規則的重要數據結構。
根據加鎖的范圍，MySQL裡面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（metadata lock，MDL)。
表鎖是在Server層實現的，ALTER TABLE之類的語句會使用表鎖，忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現，而對於InnoDB來說，一般會採用行級鎖。畢竟鎖住整張表影響范圍太大了。
另外一個表級鎖是MDL（metadata lock），用於並發情況下維護數據的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時會被自動加上。
常見的一種鎖表場景就是有事務操作處於：Waiting for table metadata lock狀態。
MySQL在進行alter table等DDL操作時，有時會出現Waiting for table metadata lock的等待場景。
一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態，後續對該表的任何操作（包括讀）都無法進行，因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現了鎖等待隊列，就會造成災難性的後果。
通過show processlist可以看到表上有正在進行的操作（包括讀），此時alter table語句無法獲取到metadata 獨占鎖，會進行等待。
通過show processlist看不到表上有任何操作，但實際上存在有未提交的事務，可以在information_schema.innodb_trx中查看到。在事務沒有完成之前，表上的鎖不會釋放，alter table同樣獲取不到metadata的獨占鎖。
處理方法：通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然後kill掉，讓其回滾。
通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進行中的事務。很可能是因為在一個顯式的事務中，對表進行了一個失敗的操作（比如查詢了一個不存在的欄位），這時事務沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。
處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。
總之，alter table的語句是很危險的（核心是未提交事務或者長事務導致的），在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務、也沒有顯式事務中的報錯語句。
如果有alter table的維護任務，在無人監管的時候運行，最好通過lock_wait_timeout設置好超時時間，避免長時間的metedata鎖等待。
關於MySQL的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。
❺ 資料庫鎖表是什麼意思
1、資料庫鎖表的意思：因為在資料庫里，同一個數據可能有多個人來讀取或更改，為了防止我更改的時候別人也同時更改，這是一般要鎖住表不讓別人改。
2、舉個簡單例子：在更新資料庫記錄的過程中，我是不希望別人也來更新我的這些記錄的，像庫存，做出庫的時候，原數量100，我出了20，我就需要把數量更新到80；
在更新的過程中，別人又做了30的出庫，如果在我更新的時候，別人先把庫存更新到70，然後我又更新80，那數量就錯誤了。所以我更新的時候，我就需要鎖定這條記錄。這是數據行鎖，排他鎖。
(5)資料庫行鎖表鎖擴展閱讀：
資料庫鎖表的必要條件：
1）互斥條件：指進程對所分配到的資源進行排它性使用，即在一段時間內某資源只由一個進程佔用。如果此時還有其它進程請求資源，則請求者只能等待，直至佔有資源的進程用畢釋放。
2）請求和保持條件：指進程已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它進程佔有，此時請求進程阻塞，但又對自己已獲得的其它資源保持不放。
3）不剝奪條件：指進程已獲得的資源，在未使用完之前，不能被剝奪，只能在使用完時由自己釋放。
4）環路等待條件：指在發生死鎖時，必然存在一個進程——資源的環形鏈，即進程集合{P0，P1，P2，···，Pn}中的P0正在等待一個P1佔用的資源；P1正在等待P2佔用的資源，……，Pn正在等待已被P0佔用的資源。
❻ 資料庫鎖表是什麼意思
oracle資料庫 鎖表和死鎖的區別
死鎖指的是a,b兩個事務對同一對象進行dml或ddl操作（即修改表結構或者增刪改數據），出現了相互等待被鎖定的對象的情況，即類似於紅綠燈十字路口紅燈方向堵住路口，綠燈方向卻紅燈車輛擋在路口不能過去，這樣無論紅綠燈如何變化都無法通行。一般像oracle這樣的dbms是有死鎖檢測的，然後把鎖定對象拋出來按照預定規則處理或者讓程序處理。 鎖等待指的是a事務鎖定了操作對象，而b事務也要對其進行dml或ddl操作（即修改表結構或者增刪改數據）時，需要等待a事務完成。這個和死鎖不同，只要a事務完成後，b事務就可以正常進行了。類似於正常的紅綠燈十字路口通行狀態：紅燈方向就是等待鎖釋放的b事務，綠燈方向就是鎖定路口的a事務。待紅綠燈互換，則a事務執行完畢，b事務也就可以正常執行啦。
MySQL鎖表是什麼意思？有什麼用？什麼情況下用？好處？缺點？
白話解說如下：
簡單說，就是lock table，不讓別人動
鎖分共享鎖和排它鎖。
共享鎖時，別人能讀，不能改變數表數據
排它鎖時，別人既不能讀，也不能改表數據
根據以上特點，應該就知道何時使用鎖了。不想讓別人變更數據，對自己產生影響，就加鎖。一定要在不用之後，進行鎖釋放，不然，應歷搭用系統會一直因為讀取數據而報錯。
好處就是，保證數據的原子性，完整性，一致性。 只有加鎖者釋放了鎖，別人才能改變數據。
缺點就是，增加了系統開銷，有可能產生鎖等待，造成資料庫運行異常。這都是不正常的使用鎖帶來的問題。
什麼情況下造成資料庫鎖表？ 如何解決？
./question/180766896
兩個SQL的鎖表問題
不同的資料庫，多版本的實現機制不同，上述語句執行情況也就不一樣，下面以oracle為例說明：
1.insert/delete語句可以並發執行，陸慧不會鎖等待
2.並發insert不會鎖等待
3.並發update，如果不是操作同一條記錄，不會鎖等待
=================================================
對真實存在的數據進行並發操作才有可能發生寫沖突，所以樓主供要把握住這點就可以早爛答判斷是否會沖突了。
建議樓主構造簡單數據，開兩個客戶端，在不同的隔離級下去模擬並發操作，理論和實踐相結合，你會理解的更透徹。
oracle 資料庫 為什麼鎖表
簡單地說，鎖是為了保證數據的一致性，鎖不止存在於oracle，其他資料庫一樣有，只不過機制上可能大相徑庭。 至於什麼樣的操作會鎖表，其實鎖的種類很多，你所說的鎖表大概說的是行級鎖——也就是事務鎖吧
如何將資料庫中被鎖表解鎖
在操作資料庫的時候，有時候會由於操作不當引起資料庫表被鎖定，這么我們經常不知所措，不知怎麼給這些表解鎖，在pl/sql Developer工具的的菜單「tools」裡面的「sessions」可以查詢現在存在的會話，但是我們很難找到那個會話被鎖定了，想找到所以被鎖的會話就更難了，下面這叫查詢語句可以查詢出所以被鎖的會話。如下：
SELECT sn.username, m.SID,sn.SERIAL#, m.TYPE,
DECODE (m.lmode,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
lmode, LTRIM (TO_CHAR (lmode, '990'))
) lmode,
DECODE (m.request,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
request, LTRIM (TO_CHAR (m.request, '990'))
) request,
m.id1, m.id2
FROM v$session sn, v$lock m
WHERE (sn.SID = m.SID AND m.request != 0) --存在鎖請求，即被阻塞
OR ( sn.SID = m.SID --不存在鎖請求，但是鎖定的對象被其他會話請求鎖定
AND m.request = 0
AND lmode != 4
AND (id1, id2) IN (
SELECT s.id1, s.id2
FROM v$lock s
WHERE request != 0 AND s.id1 = m.id1
AND s.id2 = m.id2)
)
ORDER BY id1, id2, m.request;
通過以上查詢知道了sid和 SERIAL#就可以開殺了
alter system kill session 'sid,SERIAL#';
怎麼知道資料庫表已經鎖表了
通過查詢結果中的object_id，可以查詢到具體被鎖的對象再給你看看我查到的一些關於鎖的資料：鎖有以下幾種模式: 0：none 1：null 空 2：Row-S 行共享(RS)：共享表鎖 3：Row-X 行專用(RX)：用於行的修改 4：Share 共享鎖(S)：阻止其他DML操作 5：S/Row-X 共享行專用(SRX)：阻止其他事務操作 6：exclusive 專用(X)：獨立訪問使用數字越大鎖級別越高, 影響的操作越多。一般的查詢語句如select ... from ... ;是小於2的鎖, 有時會在v$locked_object出現。 select ... from ... for update; 是2的鎖。當對話使用for update子串打開一個游標時，所有返回集中的數據行都將處於行級(Row-X)獨占式鎖定，其他對象只能查詢這些數據行，不能進行update、delete或select...for update操作。 insert / update / delete ... ; 是3的鎖。沒有mit之前插入同樣的一條記錄會沒有反應, 因為後一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續工作。創建索引的時候也會產生3,4級別的鎖。 locked_mode為2,3,4不影響DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作會提示ora-00054錯誤。有主外鍵約束時 update / delete ... ; 可能會產生4,5的鎖。 DDL語句時是6的鎖。以DBA角色, 查看當前資料庫里鎖的情況可以用如下SQL語句： select object_id,session_id,locked_mode from v$locked_object; select t2.username,t2.sid,t2.serial#,t2.logon_time from v$locked_object t1,v$session t2 where t1.session_id=t2.sid order by t2.logon_time; 如果有長期出現的一列，可能是沒有釋放的鎖。我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖： alter system kill session 'sid,serial#'; 如果出現了鎖的問題, 某個DML操作可能等待很久沒有反應。當你採用的是直接連接資料庫的方式，也不要用OS系統命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，因為一個用戶進程可能產生一個以上的鎖, 殺OS進程並不能徹底清除鎖的問題。
如何實現資料庫鎖表及解鎖
鎖表：
LOCK TABLES tablename WRITE;LOCK TABLES tablename READ;解鎖
UNLOCK TABLES;
資料庫中如何釋鎖表進程
鎖表查詢的代碼有以下的形式：
select count(*) from v$locked_object;
select * from v$locked_object;
查看哪個表被鎖
select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id;查看是哪個session引起的
select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time;殺掉對應進程
執行命令：alter system kill session'1025,41';
其中1025為sid,41為serial#.
怎麼知道資料庫表已經鎖表了
先回答你的問題：
select *from v$locked_object;
可以獲得被鎖的對象的object_id及產生鎖的會話sid。
通過查詢結果中的object_id，可以查詢到具體被鎖的對象
再給你看看我查到的一些關於鎖的資料：
鎖有以下幾種模式:
0：none
1：null 空
2：Row-S 行共享(RS)：共享表鎖
3：Row-X 行專用(RX)：用於行的修改
4：Share 共享鎖(S)：阻止其他DML操作
5：S/Row-X 共享行專用(SRX)：阻止其他事務操作
6：exclusive 專用(X)：獨立訪問使用
數字越大鎖級別越高, 影響的操作越多。
一般的查詢語句如select ... from ... ;是小於2的鎖, 有時會在v$locked_object出現。
select ... from ... for update; 是2的鎖。
當對話使用for update子串打開一個游標時，
所有返回集中的數據行都將處於行級(Row-X)獨占式鎖定，
其他對象只能查詢這些數據行，不能進行update、delete或select...for update操作。
insert / update / delete ... ; 是3的鎖。
沒有mit之前插入同樣的一條記錄會沒有反應,
因為後一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續工作。
創建索引的時候也會產生3,4級別的鎖。
locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作會提示ora-00054錯誤。
有主外鍵約束時 update / delete ... ; 可能會產生4,5的鎖。
DDL語句時是6的鎖。
以DBA角色, 查看當前資料庫里鎖的情況可以用如下SQL語句：
select object_id,session_id,locked_mode from v$locked_object;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有長期出現的一列，可能是沒有釋放的鎖。
我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：
alter system kill session 'sid,serial#';
如果出現了鎖的問題, 某個DML操作可能等待很久沒有反應。
當你採用的是直接連接資料庫的方式，
也不要用OS系統命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，
因為一個用戶進程可能產生一個以上的鎖, 殺OS進程並不能徹底清除鎖的問題。
記得在資料庫級別用alter system kill session 'sid,serial#';殺掉不正常的鎖。
這里還講了一些：
......>>