MySQL 中的 INSERT 是怎麼加鎖的?

2021-12-17 碼農突圍

來源:https://www.aneasystone.com/archives/2018/06/insert-locks-via-mysql-source-code.html

看到熱心網友在評論中提出的一個問題,我還是徹底被問蒙了。

他的問題是這樣的:

加了插入意向鎖後,插入數據之前,此時執行了 select...lock in share mode 語句(沒有取到待插入的值),然後插入了數據,下一次再執行 select...lock in share mode(不會跟插入意向鎖衝突),發現多了一條數據,於是又產生了幻讀。會出現這種情況嗎?

這個問題初看上去很簡單,在 RR 隔離級別下,假設要插入的記錄不存在,如果先執行 select...lock in share mode 語句,很顯然會在記錄間隙之間加上 GAP 鎖,而 insert 語句首先會對記錄加插入意向鎖,插入意向鎖和 GAP 鎖衝突,所以不存在幻讀;如果先執行 insert 語句後執行 select...lock in share mode 語句,由於 insert 語句在插入記錄之後,會對記錄加 X 鎖,它會阻止 select...lock in share mode 對記錄加 S 鎖,所以也不存在幻讀。兩種情況如下所示:

先執行 INSERT 後執行 SELECT:

圖片

先執行 SELECT 後執行 INSERT:

圖片

但是我們仔細想一想就會發現哪裡有點不對勁,我們知道 insert 語句會先在插入間隙上加上插入意向鎖,然後開始寫數據,寫完數據之後再對記錄加上 X 記錄鎖。

那麼問題就來了,如果在 insert 語句加插入意向鎖之後,寫數據之前,執行了 select...lock in share mode 語句,這個時候 GAP 鎖和插入意向鎖是不衝突的,查詢出來的記錄數為 0,然後 insert 語句寫數據,加 X 記錄鎖,因為記錄鎖和 GAP 鎖也是不衝突的,所以 insert 成功插入了一條數據,這個時候如果事務提交,select...lock in share mode語句再次執行查詢出來的記錄數就是 1,豈不是就出現了幻讀?

整個流程如下所示(我們把 insert 語句的執行分成兩個階段,INSERT 1 加插入意向鎖,還沒寫數據,INSERT 2 寫數據,加記錄鎖):

圖片一、INSERT 加鎖的困惑

在得出上面的結論時,我也感到很驚訝。按理是不可能出現這種情況的,只可能是我對這兩個語句的加鎖過程還沒有想明白。

於是我又去複習了一遍 MySQL 官方文檔,Locks Set by Different SQL Statements in InnoDB 這篇文檔對各個語句的加鎖有詳細的描述,其中對 insert 的加鎖過程是這樣說的(這應該是網絡上介紹 MySQL 加鎖機制被引用最多的文檔,估計也是被誤解最多的文檔):

INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.

Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Suppose that there are index records with values of 4 and 7. Separate transactions that attempt to insert values of 5 and 6 each lock the gap between 4 and 7 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each other because the rows are nonconflicting.

If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock. This can occur if another session deletes the row.

這裡講到了 insert 會對插入的這條記錄加排他記錄鎖,在加記錄鎖之前還會加一種 GAP 鎖,叫做插入意向鎖,如果出現唯一鍵衝突,還會加一個共享記錄鎖。這和我之前的理解是完全一樣的,那麼究竟是怎麼回事呢?難道 MySQL 的 RR 真的會出現幻讀現象?

在 Google 上搜索了很久,並沒有找到 MySQL 幻讀的問題,百思不得其解之際,遂決定從 MySQL 的源碼中一探究竟。

二、編譯 MySQL 源碼

編譯 MySQL 的源碼非常簡單,但是中間也有幾個坑,如果能繞過這幾個坑,在本地調試 MySQL 是一件很容易的事(當然能調試源碼是一回事,能看懂源碼又是另一回事了)。

我的環境是 Windows 10 x64,系統上安裝了 Visual Studio 2012,如果你的開發環境和我不一樣,編譯步驟可能也會不同。

在開始之前,首先要從官網下載 MySQL 源碼:

圖片

這裡我選擇的是 5.6.40 版本,作業系統下拉列表裡選 Source Code,OS Version 選擇 Windows(Architecture Independent),然後就可以下載打包好的 zip 源碼了。

將源碼解壓縮到 D:\mysql-5.6.40 目錄,在編譯之前,還需要再安裝幾個必要軟體:

CMake:CMake 本身並不是編譯工具,它是通過編寫一種平臺無關的 CMakeList.txt 文件來定製編譯流程的,然後再根據目標用戶的平臺進一步生成所需的本地化 Makefile 和工程文件,如 Unix 的 Makefile 或 Windows 的 Visual Studio 工程;Bison:MySQL 在執行 SQL 語句時,必然要對 SQL 語句進行解析,一般來說語法解析器會包含兩個模塊:詞法分析和語法規則。詞法分析和語法規則模塊有兩個較成熟的開源工具 Flex 和 Bison 分別用來解決這兩個問題。MySQL 出於性能和靈活考慮,選擇了自己完成詞法解析部分,語法規則部分使用了 Bison,所以這裡我們還要先安裝 Bison。Bison 的默認安裝路徑為 C:\Program Files\GnuWin32,但是千萬不要這樣,一定要記得選擇一個不帶空格的目錄,譬如 C:\GnuWin32 要不然在後面使用 Visual Studio 編譯 MySQL 時會卡死;Visual Studio:沒什麼好說的,Windows 環境下估計沒有比它更好的開發工具了吧。

安裝好 CMake 和 Bison 之後,記得要把它們都加到 PATH 環境變量中。做好準備工作,我們就可以開始編譯了,首先用 CMake 生成 Visual Studio 的工程文件:

D:\mysql-5.6.40> mkdir project
D:\mysql-5.6.40> cd project
D:\mysql-5.6.40\project> cmake -G "Visual Studio 11 2012 Win64" ..

cmake 的 -G 參數用於指定生成哪種類型的工程文件,這裡是 Visual Studio 2012,可以直接輸入 cmake -G 查看支持的工程類型。如果沒問題,會在 project 目錄下生成一堆文件,其中 MySQL.sln 就是我們要用的工程文件,使用 Visual Studio 打開它。

打開 MySQL.sln 文件,會在 Solution Explorer 看到 130 個項目,其中有一個叫 ALL_BUILD,這個時候如果直接編譯,編譯會失敗,在這之前,我們還要對代碼做點修改:

首先是 sql\sql_locale.cc 文件,看名字就知道這個文件用於國際化與本土化,這個文件裡有各個國家的語言字符,但是這個文件卻是 ANSI 編碼,所以要將其改成 Unicode 編碼;打開 sql\mysqld.cc 文件的第 5239 行,將 DBUG_ASSERT(0) 改成 DBUG_ASSERT(1),要不然調試時會觸發斷言;

現在我們可以編譯整個工程了,選中 ALL_BUILD 項目,Build,然後靜靜的等待 5 到 10 分鐘,如果出現了 Build: 130 succeeded, 0 failed 這樣的提示,那麼恭喜,你現在可以盡情的調試 MySQL 了。

我們將 mysqld 設置為 Startup Project,然後加個命令行參數 --console,這樣可以在控制臺裡查看列印的調試信息:

圖片

另外 client\Debug\mysql.exe 這個文件是對應的 MySQL 的客戶端,可以直接雙擊運行,默認使用的用戶為 ODBC@localhost,如果要以 root 用戶登錄,可以執行 mysql.exe -u root,不需要密碼。

三、調試 INSERT 加鎖流程

首先我們創建一個資料庫 test,然後創建一個測試表 t,主鍵為 id,並插入測試數據:

> use test;
> create table t(id int NOT NULL AUTO_INCREMENT , PRIMARY KEY (id));
> insert into t(id) values(1),(10),(20),(50);

然後我們開兩個客戶端會話,一個會話執行 insert into t(id) value(30),另一個會話執行 select * from t where id = 30 lock in share mode。很顯然,如果我們能在 insert 語句加插入意向鎖之後寫數據之前下個斷點,再在另一個會話中執行 select 就可以模擬出這種場景了。

那麼我們來找下 insert 語句是在哪加插入意向鎖的。第一次看 MySQL 源碼可能會有些不知所措,調著調著就會迷失在深深的調用層級中,我們看 insert 語句的調用堆棧,一開始時還比較容易理解,從 mysql_parse -> mysql_execute_command -> mysql_insert -> write_record -> handler::ha_write_row -> innobase::write_row -> row_insert_for_mysql,這裡就進入 InnoDb 引擎了。

然後繼續往下跟:row_ins_step -> row_ins -> row_ins_index_entry_step -> row_ins_index_entry -> row_ins_clust_index_entry -> row_ins_clust_index_entry_low -> btr_cur_optimistic_insert -> btr_cur_ins_lock_and_undo -> lock_rec_insert_check_and_lock。

一路跟下來,都沒有發現插入意向鎖的蹤跡,直到 lock_rec_insert_check_and_lock 這裡:

if (lock_rec_other_has_conflicting(
        static_cast<enum lock_mode>(
            LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION),
        block, next_rec_heap_no, trx)) {
 
    /* Note that we may get DB_SUCCESS also here! */
    trx_mutex_enter(trx);
 
    err = lock_rec_enqueue_waiting(
        LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION,
        block, next_rec_heap_no, index, thr);
 
    trx_mutex_exit(trx);
} else {
    err = DB_SUCCESS;
}

這裡是檢查是否有和插入意向鎖衝突的其他鎖,如果有衝突,就將插入意向鎖加到鎖等待隊列中。這很顯然是先執行 select ... lock in share mode 語句再執行 insert 語句時的情景,插入意向鎖和 GAP 衝突。但這不是我們要找的點,於是繼續探索,但是可惜的是,直到 insert 執行結束,我都沒有找到加插入意向鎖的地方。

跟代碼非常辛苦,我擔心是因為我跟丟了某塊的邏輯導致沒看到加鎖,於是我看了看加其他鎖的地方,發現在 InnoDb 裡行鎖都是通過調 lock_rec_add_to_queue(沒有鎖衝突) 或者 lock_rec_enqueue_waiting(有鎖衝突,需要等待其他事務釋放鎖) 來實現的,於是在這兩個函數上下斷點,執行一條 insert 語句,依然沒有斷下來,說明 insert 語句沒有加任何鎖!

到這裡我突然想起之前做過的 insert 加鎖的實驗,執行 insert 之後,如果沒有任何衝突,在 show engine innodb status 命令中是看不到任何鎖的,這是因為 insert 加的是隱式鎖。什麼是隱式鎖?隱式鎖的意思就是沒有鎖!

所以,根本就不存在之前說的先加插入意向鎖,再加排他記錄鎖的說法,在執行 insert 語句時,什麼鎖都不會加。這就有點意思了,如果 insert 什麼鎖都不加,那麼如果其他事務執行 select ... lock in share mode,它是如何阻止其他事務加鎖的呢?

答案就在於隱式鎖的轉換。

InnoDb 在插入記錄時,是不加鎖的。如果事務 A 插入記錄且未提交,這時事務 B 嘗試對這條記錄加鎖,事務 B 會先去判斷記錄上保存的事務 id 是否活躍,如果活躍的話,那麼就幫助事務 A 去建立一個鎖對象,然後自身進入等待事務 A 狀態,這就是所謂的隱式鎖轉換為顯式鎖。

我們跟一下執行 select 時的流程,如果 select 需要加鎖,則會走:sel_set_rec_lock -> lock_clust_rec_read_check_and_lock -> lock_rec_convert_impl_to_expl,lock_rec_convert_impl_to_expl 函數的核心代碼如下:

impl_trx = trx_rw_is_active(trx_id, NULL);
 
if (impl_trx != NULL
    && !lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP, block,
              heap_no, impl_trx)) {
    ulint    type_mode = (LOCK_REC | LOCK_X
                 | LOCK_REC_NOT_GAP);
 
    lock_rec_add_to_queue(
        type_mode, block, heap_no, index,
        impl_trx, FALSE);
}

首先判斷事務是否活躍,然後檢查是否已存在排他記錄鎖,如果事務活躍且不存在鎖,則為該事務加上排他記錄鎖。而本事務的鎖是通過 lock_rec_convert_impl_to_expl 之後的 lock_rec_lock 函數來加的。

到這裡,這個問題的脈絡已經很清晰了:

執行 insert 語句,判斷是否有和插入意向鎖衝突的鎖,如果有,加插入意向鎖,進入鎖等待;如果沒有,直接寫數據,不加任何鎖;執行 select ... lock in share mode 語句,判斷記錄上是否存在活躍的事務,如果存在,則為 insert 事務創建一個排他記錄鎖,並將自己加入到鎖等待隊列;

所以不存在網友所說的幻讀問題。那麼事情到此結束了麼?並沒有。

細心的你會發現,執行 insert 語句時,從判斷是否有鎖衝突,到寫數據,這兩個操作之間還是有時間差的,如果在這之間執行 select ... lock in share mode 語句,由於此時記錄還不存在,所以也不存在活躍事務,不會觸發隱式鎖轉換,這條語句會返回 0 條記錄,並加上 GAP 鎖;而 insert 語句繼續寫數據,不加任何鎖,在 insert 事務提交之後,select ... lock in share mode 就能查到 1 條記錄,這豈不是還有幻讀問題嗎?

為了徹底搞清楚這中間的細節,我們在 lock_rec_insert_check_and_lock 檢查完鎖衝突之後下個斷點,然後在另一個事務中執行 select ... lock in share mode,如果它能成功返回 0 條記錄,加上 GAP 鎖,說明就存在幻讀。不過事實上,這條 SQL 語句執行的時候卡住了,並不會返回 0 條記錄。從 show engine innodb status 的 TRANSACTIONS 裡我們看不到任何行鎖衝突的信息,但是我們從 RW-LATCH INFO 中卻可以看出一些端倪:

---
RW-LATCH INFO
---
RW-LOCK: 000002C97F62FC70
Locked: thread 10304 file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 879  S-LOCK
RW-LOCK: 000002C976A3B998
Locked: thread 10304 file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 256  S-LOCK
Locked: thread 10304 file d:\mysql-5.6.40\storage\innobase\include\btr0pcur.ic line 518  S-LOCK
Locked: thread 2820 file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 256  S-LOCK
Locked: thread 2820 file D:\mysql-5.6.40\storage\innobase\row\row0ins.cc line 2339  S-LOCK
RW-LOCK: 000002C976A3B8A8  Waiters for the lock exist
Locked: thread 2820 file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 256  X-LOCK
Total number of rw-locks 16434
OS WAIT ARRAY INFO: reservation count 10
--Thread 10304 has waited at btr0cur.cc line 256 for 26.00 seconds the semaphore:
S-lock on RW-latch at 000002C976A3B8A8 created in file buf0buf.cc line 1069
a writer (thread id 2820) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file btr0cur.cc line 256
Last time write locked in file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 256
OS WAIT ARRAY INFO: signal count 8
Mutex spin waits 44, rounds 336, OS waits 7
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 7.64 mutex, 30.00 RW-shared, 0.00 RW-excl

這裡列出了 3 個 RW-LOCK:000002C97F62FC70、000002C976A3B998、000002C976A3B8A8。其中可以看到最後一個 RW-LOCK 有其他線程在等待其釋放(Waiters for the lock exist)。下面列出了所有等待該鎖的線程,Thread 10304 has waited at btr0cur.cc line 256 for 26.00 seconds the semaphore,這裡的 Thread 10304 就是我們正在執行 select 語句的線程,它卡在了 btr0cur.cc 的 256 行,我們查看 Thread 10304 的堆棧:

圖片

btr0cur.cc 的 256 行位於 btr_cur_latch_leaves 函數,如下所示,通過 btr_block_get 來加鎖,看起來像是在訪問 InnoDb B+ 樹的葉子節點時卡住了:

case BTR_MODIFY_LEAF:
    mode = latch_mode == BTR_SEARCH_LEAF ? RW_S_LATCH : RW_X_LATCH;
    get_block = btr_block_get(
        space, zip_size, page_no, mode, cursor->index, mtr);

這裡的 latch_mode == BTR_SEARCH_LEAF,所以加鎖的 mode 為 RW_S_LATCH。

這裡要介紹一個新的概念,叫做 Latch,一般也把它翻譯成 「鎖」,但它和我們之前接觸的行鎖表鎖(Lock)是有區別的。這是一種輕量級的鎖,鎖定時間一般非常短,它是用來保證並發線程可以安全的操作臨界資源,通常沒有死鎖檢測機制。Latch 可以分為兩種:MUTEX(互斥量)和 RW-LOCK(讀寫鎖),很顯然,這裡我們看到的是 RW-LOCK。

我們回溯一下 select 語句的調用堆棧:ha_innobase::index_read -> row_search_for_mysql -> btr_pcur_open_at_index_side -> btr_cur_latch_leaves,從調用堆棧可以看出 select ... lock in share mode 語句在訪問索引,那麼為什麼訪問索引會被卡住呢?

接下來我們看看這個 RW-LOCK 是在哪裡加上的?從日誌裡可以看到 Locked: thread 2820 file D:\mysql-5.6.40\storage\innobase\btr\btr0cur.cc line 256 X-LOCK,所以這個鎖是線程 2820 加上的,加鎖的位置也在 btr0cur.cc 的 256 行,查看函數引用,很快我們就查到這個鎖是在執行 insert 時加上的,函數堆棧為:row_ins_clust_index_entry_low -> btr_cur_search_to_nth_level -> btr_cur_latch_leaves。

我們看這裡的 row_ins_clust_index_entry_low 函數(無關代碼已省略):

UNIV_INTERN
dberr_t
row_ins_clust_index_entry_low(
/*==========================*/
    ulint        flags,    /*!< in: undo logging and locking flags */
    ulint        mode,    /*!< in: BTR_MODIFY_LEAF or BTR_MODIFY_TREE,
                depending on whether we wish optimistic or
                pessimistic descent down the index tree */
    dict_index_t*    index,    /*!< in: clustered index */
    ulint        n_uniq,    /*!< in: 0 or index->n_uniq */
    dtuple_t*    entry,    /*!< in/out: index entry to insert */
    ulint        n_ext,    /*!< in: number of externally stored columns */
    que_thr_t*    thr)    /*!< in: query thread */
{
    /* 開啟一個 mini-transaction */
    mtr_start(&mtr);
     
    /* 調用 btr_cur_latch_leaves -> btr_block_get 加 RW_X_LATCH */
    btr_cur_search_to_nth_level(index, 0, entry, PAGE_CUR_LE, mode,
                    &cursor, 0, __FILE__, __LINE__, &mtr);
     
    if (mode != BTR_MODIFY_TREE) {
        /* 不需要修改 BTR_TREE,樂觀插入 */
        err = btr_cur_optimistic_insert(
            flags, &cursor, &offsets, &offsets_heap,
            entry, &insert_rec, &big_rec,
            n_ext, thr, &mtr);
    } else {
        /* 需要修改 BTR_TREE,先樂觀插入,樂觀插入失敗則進行悲觀插入 */
        err = btr_cur_optimistic_insert(
            flags, &cursor,
            &offsets, &offsets_heap,
            entry, &insert_rec, &big_rec,
            n_ext, thr, &mtr);
        if (err == DB_FAIL) {
            err = btr_cur_pessimistic_insert(
                flags, &cursor,
                &offsets, &offsets_heap,
                entry, &insert_rec, &big_rec,
                n_ext, thr, &mtr);
        }
    }
     
    /* 提交 mini-transaction */
    mtr_commit(&mtr);
}

這裡是執行 insert 語句的關鍵,可以發現執行插入操作的前後分別有一行代碼:mtr_start() 和 mtr_commit()。這被稱為 迷你事務(mini-transaction),既然叫做事務,那這個函數的操作肯定是原子性的,事實上確實如此,insert 會在檢查鎖衝突和寫數據之前,會對記錄所在的頁加一個 RW-X-LATCH 鎖,執行完寫數據之後再釋放該鎖(實際上寫數據的操作就是寫 redo log(重做日誌),將髒頁加入 flush list,這個後面有時間再深入分析了)。

這個鎖的釋放非常快,但是這個鎖足以保證在插入數據的過程中其他事務無法訪問記錄所在的頁。mini-transaction 也可以包含子事務,實際上在 insert 的執行過程中就會加多個 mini-transaction。

每個 mini-transaction 會遵守下面的幾個規則:

訪問一個頁需要獲得該頁的 S-LATCH 或 X-LATCH;持有該頁的 LATCH 直到修改或者訪問該頁的操作完成。

所以,最後的最後,真相只有一個:insert 和 select ... lock in share mode 不會發生幻讀。整個流程如下:

執行 insert 語句,對要操作的頁加 RW-X-LATCH,然後判斷是否有和插入意向鎖衝突的鎖,如果有,加插入意向鎖,進入鎖等待;如果沒有,直接寫數據,不加任何鎖,結束後釋放 RW-X-LATCH;執行 select ... lock in share mode 語句,對要操作的頁加 RW-S-LATCH,如果頁面上存在 RW-X-LATCH 會被阻塞,沒有的話則判斷記錄上是否存在活躍的事務,如果存在,則為 insert 事務創建一個排他記錄鎖,並將自己加入到鎖等待隊列,最後也會釋放 RW-S-LATCH;

相關焦點

  • MySQL的insert into select 引發鎖表
    大佬找到我,問:「你怎麼備份的?」我:「insert into select * from 呀!」大佬:「??你是不是不想混了?」又是被大佬嫌棄的一天,為了不捲鋪蓋走人,我決定去學習一下表備份的常見方法。
  • 讀MySQL源碼再看 insert 加鎖流程,一個字:牛
    在之前的博客中,我寫了一系列的文章,比較系統的學習了 MySQL 的事務、隔離級別、加鎖流程以及死鎖,我自認為對常見 SQL 語句的加鎖原理已經掌握的足夠了,但看到熱心網友在評論中提出的一個問題,我還是徹底被問蒙了。
  • insert唯一鍵衝突的加鎖情況分析
    今天分享的內容是MySQL裡面insert語句在發生衝突的時候加鎖情況,廢話就不多說了,直接從例子開始吧。:   從上面的圖中不難看出,session A上的第一個insert操作是成功的,這容易理解,因為沒有並發,表中的最大值是5。
  • MySQL InnoDB 引擎中的 7 種鎖類型,你都知道嗎?
    前言大概幾個月之前項目中用到事務,需要保證數據的強一致性,期間也用到了mysql的鎖,但當時對mysql的鎖機制只是管中窺豹,所以本文打算總結一下mysql的鎖機制。本文主要論述關於mysql鎖機制,mysql版本為5.7,引擎為innodb,由於實際中關於innodb鎖相關的知識及加鎖方式很多,所以沒有那麼多精力羅列所有場景下的加鎖過程並加以分析,僅根據現在了解的知識,結合官方文檔,說說自己的理解,如果發現有不對的地方,歡迎指正。概述總的來說,InnoDB共有七種類型的鎖:mysql鎖詳解1.
  • MySQL INSERT的4種形態
    墨墨導讀:MySQL中常用的四種插入數據的語句:insert ,insert select,replace into
  • InnoDB加鎖實驗
    I.實驗目的通過對MySQL中各種讀寫操作的加鎖情況的分析, 解構死鎖場景, 輔助分析死鎖出現的原因, 以更高效地解決死鎖問題. II. 鎖資料庫通過鎖來保證讀寫操作的一致性.InnoDB中使用的最多的行級鎖(record lock), 所有的行級鎖都是作用在索引上面的. InnoDB通過用行鎖代替表鎖大大提高了對並發的支持.
  • INSERT...ON DUPLICATE KEY UPDATE歷險記
    先按k查詢值「a」是否存在,如果存在,則執行 update ,否則執行 insert 。思考如果你要處理的數據是一個 List 呢?其中一部分數據在存在於資料庫,一部分不存在呢?你要篩選出不存在於資料庫中的數據來執行 insert ,篩選出存在於資料庫的數據來執行 update 。
  • mysql批量語句,怎麼保證操作都成功?
    今天就討論以下幾個數據批量操作的問題在一個批量操作的sql中,如果一個失敗,其他的會怎麼樣呢對於大數據表,線上更新而不影響用戶使用事務與鎖的關係建立測試表member#MYSQL#表在一個批量操作的sql中,如果一個失敗,其他的會怎麼樣呢第一種情況:先看一下,多條語句沒有事務控制的代碼$conn = Yii::$app->db1; $sql1 = 'insert into member (name,password) values ("yang","vincent")';$sql2 = 'insert into
  • MySQL資料庫Insert語句7種寫法
    簡介很多開發人員工作了幾年之後,都會自嘲,自己啥技術都沒學到,就會CRUD,可是我要說的是,CRUD你真的都會嗎,你在MySQL資料庫中,會幾種insert語句寫法呢。在這裡我會7種寫法,下面我就來給大家分別介紹一下。
  • MySQL實戰中的Insert語句的使用心得
    replace into 與 insert on deplicate udpate 比較:在沒有主鍵或者唯一索引重複時,replace into 與 insert on deplicate udpate 相同。
  • MySQL實戰中,Insert語句的使用心得總結
    replace into 與 insert on deplicate udpate 比較:1、在沒有主鍵或者唯一索引重複時,replace into 與 insert on deplicate udpate 相同。
  • MySQL中的共享鎖與排他鎖
    在MySQL中的行級鎖,表級鎖,頁級鎖中介紹過,行級鎖是Mysql中鎖定粒度最細的一種鎖,行級鎖能大大減少資料庫操作的衝突。
  • 認識mysql的鎖機制
    二、mysql鎖的分類Ⅰ、按粒度劃分1、表鎖表級鎖是mysql鎖中粒度最大的一種鎖,表示當前的操作對整張表加鎖。資源開銷比行鎖少,但是發生鎖衝突的概率很大。被大部分的mysql引擎支持,MyISAM和InnoDB都支持表級鎖。
  • 女朋友問我:什麼是 MySQL 的全局鎖、表鎖、行鎖?
    2.2 為什麼要加鎖?上面說了,利用全局鎖備份會造成兩個問題。那不加鎖行嗎?廢話,肯定是不行的。不加鎖,你養我呀(備份出問題被開除)?不加鎖同樣會出現意想不到的問題:舉個慄子,看電影買票,系統有個餘額表和用戶已購票表。
  • MySQL死鎖分析與解決之路
    --什麼是死鎖 --死鎖是並發系統中常見的問題,同樣也會出現在資料庫MySQL的並發讀寫請求場景中。當兩個及以上的事務,雙方都在等待對方釋放已經持有的鎖或因為加鎖順序不一致造成循環等待鎖資源,就會出現「死鎖」。常見的報錯信息為 」 Deadlock found when trying to get lock... 」。
  • MySQL mysqldump 數據導出詳解
    語法:默認不帶參數的導出,導出文本內容大概如下:創建資料庫判斷語句-刪除表-創建表-鎖表-禁用索引-插入數據-啟用索引-解鎖表。--host=h1 -uroot -proot --databases db1 |mysql --host=h2 -uroot -proot db2將h1伺服器中的db1資料庫的所有數據導入到h2中的db2資料庫中,db2的資料庫必須存在否則會報錯mysqldump --host=192.168.80.137 -uroot -proot -C --databases test
  • 為什麼大多數公司使用MySql的事務隔離級別是RC?
    本文所有的前提是MySQL的存儲引擎是Innodb。
  • 圖解mysql事務實現原理
    今天想跟大家一起研究下事務內部到底是怎麼實現的。事務無非是要做到可靠性以及並發處理可靠性:資料庫要保證當insert或update操作時拋異常或者資料庫crash的時候需要保障數據的操作前後的一致,想要做到這個,我需要知道我修改之前和修改之後的狀態,所以就有了undo log和redo log。
  • MySQL 的加鎖處理分析
    一條簡單SQL的加鎖實現分析在介紹完一些背景知識之後,本文接下來將選擇幾個有代表性的例子,來詳細分析MySQL的加鎖處理。當然,還是從最簡單的例子說起。經常有朋友發給我一個SQL,然後問我,這個SQL加什麼鎖?就如同下面兩條簡單的SQL,他們加什麼鎖?針對這個問題,該怎麼回答?
  • MySQL 加鎖處理分析
    一條簡單SQL的加鎖實現分析在介紹完一些背景知識之後,本文接下來將選擇幾個有代表性的例子,來詳細分析MySQL的加鎖處理。當然,還是從最簡單的例子說起。經常有朋友發給我一個SQL,然後問我,這個SQL加什麼鎖?就如同下面兩條簡單的SQL,他們加什麼鎖?針對這個問題,該怎麼回答?