欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MySQL中的隱藏列的具體查看

 更新時間:2021年09月02日 15:03:00   作者:碼農參上  
mysql中存在一些隱藏列,例如行標識、事務ID、回滾指針等,不知道大家是否和我一樣好奇過,要怎樣才能實際地看到這些隱藏列的值呢,感興趣的可以了解一下

在介紹mysql的多版本并發(fā)控制mvcc的過程中,我們提到過mysql中存在一些隱藏列,例如行標識、事務ID、回滾指針等,不知道大家是否和我一樣好奇過,要怎樣才能實際地看到這些隱藏列的值呢?

本文我們就來重點討論一下諸多隱藏列中的行標識DB_ROW_ID,實際上,將行標識稱為隱藏列并不準確,因為它并不是一個真實存在的列,DB_ROW_ID實際上是一個非空唯一列的別名。在撥開它的神秘面紗之前,我們看一下官方文檔的說明:

If a table has a PRIMARY KEY or UNIQUE NOT NULL index that consists of a single column that has an integer type, you can use _rowid to refer to the indexed column in SELECT statements

簡單翻譯一下,如果在表中存在主鍵或非空唯一索引,并且僅由一個整數類型的列構成,那么就可以使用SELECT語句直接查詢_rowid,并且這個_rowid的值會引用該索引列的值。

著重看一下文檔中提到的幾個關鍵字,主鍵、唯一索引、非空、單獨一列、數值類型,接下來我們就要從這些角度入手,探究一下神秘的隱藏字段_rowid。

1、存在主鍵

先看設置了主鍵且是數值類型的情況,使用下面的語句建表:

CREATE TABLE `table1` (
  `id` bigint(20) NOT NULL PRIMARY KEY ,
  `name` varchar(32) DEFAULT NULL
) ENGINE=InnoDB;

插入三條測試數據后,執(zhí)行下面的查詢語句,在select查詢語句中直接查詢_rowid

select *,_rowid from table1

查看執(zhí)行結果,_rowid可以被正常查詢:

可以看到在設置了主鍵,并且主鍵字段是數值類型的情況下,_rowid直接引用了主鍵字段的值。對于這種可以被select語句查詢到的的情況,可以將其稱為顯式的rowid。

回顧一下前面提到的文檔中的幾個關鍵字,分別對其進行分析。由于主鍵必定是非空字段,下面來看一下主鍵是非數值類型字段的情況,建表如下:

CREATE TABLE `table2` (
  `id` varchar(20) NOT NULL PRIMARY KEY ,
  `name` varchar(32) DEFAULT NULL
) ENGINE=InnoDB;

table2執(zhí)行上面相同的查詢,結果報錯無法查詢_rowid,也就證明了如果主鍵字段是非數值類型,那么將無法直接查詢_rowid。

2、無主鍵,存在唯一索引

上面對兩種類型的主鍵進行了測試后,接下來我們看一下當表中沒有主鍵、但存在唯一索引的情況。首先測試非空唯一索引加在數值類型字段的情況,建表如下:

CREATE TABLE `table3` (
  `id` bigint(20) NOT NULL UNIQUE KEY,
  `name` varchar(32)
) ENGINE=InnoDB;

查詢可以正常執(zhí)行,并且_rowid引用了唯一索引所在列的值:

唯一索引與主鍵不同的是,唯一索引所在的字段可以為NULL。在上面的table3中,在唯一索引所在的列上添加了NOT NULL非空約束,如果我們把這個非空約束刪除掉,還能顯式地查詢到_rowid嗎?下面再創(chuàng)建一個表,不同是在唯一索引所在的列上,不添加非空約束:

CREATE TABLE `table4` (
  `id` bigint(20) UNIQUE KEY,
  `name` varchar(32)
) ENGINE=InnoDB;

執(zhí)行查詢語句,在這種情況下,無法顯式地查詢到_rowid

和主鍵類似的,我們再對唯一索引被加在非數值類型的字段的情況進行測試。下面在建表時將唯一索引添加在字符類型的字段上,并添加非空約束:

CREATE TABLE `table5` (
  `id` bigint(20),
  `name` varchar(32) NOT NULL UNIQUE KEY
) ENGINE=InnoDB;

同樣無法顯示的查詢到_rowid

針對上面三種情況的測試結果,可以得出結論,當沒有主鍵、但存在唯一索引的情況下,只有該唯一索引被添加在數值類型的字段上,且該字段添加了非空約束時,才能夠顯式地查詢到_rowid,并且_rowid引用了這個唯一索引字段的值。

3、存在聯(lián)合主鍵或聯(lián)合唯一索引

在上面的測試中,我們都是將主鍵或唯一索引作用在單獨的一列上,那么如果使用了聯(lián)合主鍵或聯(lián)合唯一索引時,結果會如何呢?還是先看一下官方文檔中的說明:

_rowid refers to the PRIMARY KEY column if there is a PRIMARY KEY consisting of a single integer column. If there is a PRIMARY KEY but it does not consist of a single integer column, _rowid cannot be used.

簡單來說就是,如果主鍵存在、且僅由數值類型的一列構成,那么_rowid的值會引用主鍵。如果主鍵是由多列構成,那么_rowid將不可用。

根據這一描述,我們測試一下聯(lián)合主鍵的情況,下面將兩列數值類型字段作為聯(lián)合主鍵建表:

CREATE TABLE `table6` (
  `id` bigint(20) NOT NULL,
  `no` bigint(20) NOT NULL,
  `name` varchar(32),
  PRIMARY KEY(`id`,`no`)
) ENGINE=InnoDB;

執(zhí)行結果無法顯示的查詢到_rowid

同樣,這一理論也可以作用于唯一索引,如果非空唯一索引不是由單獨一列構成,那么也無法直接查詢得到_rowid。這一測試過程省略,有興趣的小伙伴可以自己動手試試。

4、存在多個唯一索引

在mysql中,每張表只能存在一個主鍵,但是可以存在多個唯一索引。那么如果同時存在多個符合規(guī)則的唯一索引,會引用哪個作為_rowid的值呢?老規(guī)矩,還是看官方文檔的解答:

Otherwise, _rowid refers to the column in the first UNIQUE NOT NULL index if that index consists of a single integer column. If the first UNIQUE NOT NULL index does not consist of a single integer column, _rowid cannot be used.

簡單翻譯一下,如果表中的第一個非空唯一索引僅由一個整數類型字段構成,那么_rowid會引用這個字段的值。否則,如果第一個非空唯一索引不滿足這種情況,那么_rowid將不可用。

在下面的表中,創(chuàng)建兩個都符合規(guī)則的唯一索引:

CREATE TABLE `table8_2` (
  `id` bigint(20) NOT NULL,
  `no` bigint(20) NOT NULL,
  `name` varchar(32),
  UNIQUE KEY(no),
  UNIQUE KEY(id)
) ENGINE=InnoDB;

看一下執(zhí)行查詢語句的結果:

可以看到_rowid的值與no這一列的值相同,證明了_rowid會嚴格地選取第一個創(chuàng)建的唯一索引作為它的引用。

那么,如果表中創(chuàng)建的第一個唯一索引不符合_rowid的引用規(guī)則,第二個唯一索引滿足規(guī)則,這種情況下,_rowid可以被顯示地查詢嗎?針對這種情況我們建表如下,表中的第一個索引是聯(lián)合唯一索引,第二個索引才是單列的唯一索引情況,再來進行一下測試:

CREATE TABLE `table9` (
  `id` bigint(20) NOT NULL,
  `no` bigint(20) NOT NULL,
  `name` varchar(32),
  UNIQUE KEY `index1`(`id`,`no`),
  UNIQUE KEY `index2`(`id`)
) ENGINE=InnoDB;

進行查詢,可以看到雖然存在一個單列的非空唯一索引,但是因為順序選取的第一個不滿足要求,因此仍然不能直接查詢_rowid

如果將上面創(chuàng)建唯一索引的語句順序調換,那么將可以正常顯式的查詢到_rowid。

5、同時存在主鍵與唯一索引

從上面的例子中,可以看到唯一索引的定義順序會決定將哪一個索引應用_rowid,那么當同時存在主鍵和唯一索引時,定義順序會對其引用造成影響嗎?

按照下面的語句創(chuàng)建兩個表,只有創(chuàng)建主鍵和唯一索引的順序不同:

CREATE TABLE `table11` (
  `id` bigint(20) NOT NULL,
  `no` bigint(20) NOT NULL,
  PRIMARY KEY(id),
  UNIQUE KEY(no)
) ENGINE=InnoDB;

CREATE TABLE `table12` (
  `id` bigint(20) NOT NULL,
  `no` bigint(20) NOT NULL,
  UNIQUE KEY(id),
  PRIMARY KEY(no)
) ENGINE=InnoDB;

查看運行結果:

可以得出結論,當同時存在符合條件的主鍵和唯一索引時,無論創(chuàng)建順序如何,_rowid都會優(yōu)先引用主鍵字段的值。

6、無符合條件的主鍵與唯一索引

上面,我們把能夠直接通過select語句查詢到的稱為顯式的_rowid,在其他情況下雖然_rowid不能被顯式查詢,但是它也是一直存在的,這種情況我們可以將其稱為隱式的_rowid。

實際上,innoDB在沒有默認主鍵的情況下會生成一個6字節(jié)長度的無符號數作為自動增長的_rowid,因此最大為2^48-1,到達最大值后會從0開始計算。下面,我們創(chuàng)建一個沒有主鍵與唯一索引的表,在這張表的基礎上,探究一下隱式的_rowid。

CREATE TABLE `table10` (
  `id` bigint(20),
  `name` varchar(32)
) ENGINE=InnoDB;

首先,我們需要先查找到mysql的進程pid

ps -ef | grep mysqld

可以看到,mysql的進程pid是2068:

在開始動手前,還需要做一點鋪墊, 在innoDB中其實維護了一個全局變量dictsys.row_id,沒有定義主鍵的表都會共享使用這個row_id,在插入數據時會把這個全局row_id當作自己的主鍵,然后再將這個全局變量加 1。

接下來我們需要用到gdb調試的相關技術,gdb是一個在Linux下的調試工具,可以用來調試可執(zhí)行文件。在服務器上,先通過yum install gdb安裝,安裝完成后,通過下面的gdb命令 把 row_id 修改為 1:

gdb -p 2068 -ex 'p dict_sys->row_id=1' -batch

命令執(zhí)行結果:

在空表中插入3行數據:

INSERT INTO table10 VALUES (100000001, 'Hydra');
INSERT INTO table10 VALUES (100000002, 'Trunks');
INSERT INTO table10 VALUES (100000003, 'Susan');

查看表中的數據,此時對應的_rowid理論上是1~3:

然后通過gdb命令把row_id改為最大值2^48,此時已超過dictsys.row_id最大值:

gdb -p 2068 -ex 'p dict_sys->row_id=281474976710656' -batch

命令執(zhí)行結果:

再向表中插入三條數據:

INSERT INTO table10 VALUES (100000004, 'King');
INSERT INTO table10 VALUES (100000005, 'Queen');
INSERT INTO table10 VALUES (100000006, 'Jack');

查看表中的全部數據,可以看到第一次插入的三條數據中,有兩條數據被覆蓋了:

為什么會出現(xiàn)數據覆蓋的情況呢,我們對這一結果進行分析。首先,在第一次插入數據前_rowid為1,插入的三條數據對應的_rowid為1、2、3。如下圖所示:

當手動設置_rowid為最大值后,下一次插入數據時,插入的_rowid重新從0開始,因此第二次插入的三條數據的_rowid應該為0、1、2。這時準備被插入的數據如下所示:

當出現(xiàn)相同_rowid的情況下,新插入的數據會根據_rowid覆蓋掉原有的數據,過程如圖所示:

所以當表中的主鍵或唯一索引不滿足我們前面提到的要求時,innoDB使用的隱式的_rowid是存在一定風險的,雖然說2^48這個值很大,但還是有可能被用盡的,當_rowid用盡后,之前的記錄就會被覆蓋。從這一角度也可以提醒大家,在建表時一定要創(chuàng)建主鍵,否則就有可能發(fā)生數據的覆蓋。

本文基于mysql 5.7.31 進行測試

官方文檔:https://dev.mysql.com/doc/refman/5.7/en/create-index.html

到此這篇關于MySQL中的隱藏列的具體使用的文章就介紹到這了,更多相關MySQL 隱藏列內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

相關文章

  • mysql4.0升級到mysql5(4.1),解決字符集問題

    mysql4.0升級到mysql5(4.1),解決字符集問題

    軟件升級部分就不說了,光說數據庫遷移。
    2009-09-09
  • MySQL在線開啟或禁用GTID模式

    MySQL在線開啟或禁用GTID模式

    本文詳細講解了MySQL在線開啟或禁用GTID模式的方法,文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2021-11-11
  • MySQL驗證用戶權限的方法

    MySQL驗證用戶權限的方法

    這篇文章主要介紹了MySQL驗證用戶權限的方法,需要的朋友可以參考下
    2015-11-11
  • Mysql常用命令匯總

    Mysql常用命令匯總

    這篇文章主要介紹了Mysql常用命令,都是mysql數據庫日常最基本的操作命令,感興趣的小伙伴們可以參考一下
    2015-11-11
  • mysql查找配置文件位置的兩種方法

    mysql查找配置文件位置的兩種方法

    想去查看windows系統(tǒng)下,MySQL數據庫的配置文件,由于距離上一次查看時間太久,每次查看都要找很久在什么位置,所以本文給大家介紹了mysql查找配置文件位置的兩種方法,需要的朋友可以參考下
    2024-09-09
  • SQL處理時間戳時如何解決時區(qū)問題實例詳解

    SQL處理時間戳時如何解決時區(qū)問題實例詳解

    時間戳時間不分東西南北、在地球的每一個角落都是相同的,下面這篇文章主要給大家介紹了關于SQL處理時間戳時如何解決時區(qū)問題的相關資料,文中通過實例代碼介紹的非常詳細,需要的朋友可以參考下
    2022-08-08
  • MySQL 覆蓋索引的優(yōu)點

    MySQL 覆蓋索引的優(yōu)點

    當索引包含了所有查詢的數據時,這個索引就稱之為覆蓋索引。覆蓋索引能夠成為一個非常有力的工具并且能夠顯著改善性能,本文將具體講述覆蓋索引的優(yōu)點
    2021-05-05
  • 一文帶你了解MySQL中的鎖機制

    一文帶你了解MySQL中的鎖機制

    鎖是計算機協(xié)調多個進程或線程并發(fā)訪問某一資源的機制(避免爭搶)。本文就來通過幾個簡單的實力為大家詳細講講MySQL中的鎖機制吧
    2023-02-02
  • MYSQL 創(chuàng)建函數出錯的解決方案

    MYSQL 創(chuàng)建函數出錯的解決方案

    在程序開發(fā)過程中,大家有沒有遇到過mysql函數不能創(chuàng)建,我是遇到過,是一個很麻煩的問題,上網搜了些相關資料,整理在一起了,供大家參考,幫助那些需要幫助的朋友
    2015-08-08
  • 詳解mysql8.018在linux上安裝與配置過程

    詳解mysql8.018在linux上安裝與配置過程

    這篇文章主要介紹了mysql8.018在linux上安裝與配置過程,本文給大家介紹的非常詳細,具有一定的參考借鑒價值,需要的朋友可以參考下
    2020-01-01

最新評論