五月综合缴情婷婷六月,色94色欧美sute亚洲线路二,日韩制服国产精品一区,色噜噜一区二区三区,香港三级午夜理伦三级三

您現(xiàn)在的位置: 365建站網(wǎng) > 365文章 > MySQL中INFORMATION_SCHEMA介紹

MySQL中INFORMATION_SCHEMA介紹

文章來源:365jz.com     點擊數(shù):404    更新時間:2018-05-22 10:32   參與評論
information_schema數(shù)據(jù)庫是MySQL系統(tǒng)自帶的數(shù)據(jù)庫,它提供了數(shù)據(jù)庫元數(shù)據(jù)的訪問方式。感覺information_schema就像是MySQL實例的一個百科全書,記錄了數(shù)據(jù)庫當中大部分我們需要了結(jié)的信息,比如字符集,權(quán)限相關(guān),數(shù)據(jù)庫實體對象信息,外檢約束,分區(qū),壓縮表,表信息,索引信息,參數(shù),優(yōu)化,鎖和事物等等。通過information_schema我們可以窺透整個MySQL實例的運行情況,可以了結(jié)MySQL實例的基本信息,甚至優(yōu)化調(diào)優(yōu),維護數(shù)據(jù)庫等,可以說是真正的一部百科全書啊哈哈。

在獲取自增ID時,我用到了以下語句:

select auto_increment from information_schema.tables where table_name = "表名";

仔細一看,這其實就是一條查詢語句,查詢了information_schema數(shù)據(jù)庫下的"tables"表,里面 以 table_name  為 "表名"  的一行記錄的  auto_increment字段的值。

 

那么information_schema數(shù)據(jù)庫是什么呢?

 

【INFORMATION_SCHEMA 數(shù)據(jù)庫】 是MySQL自帶的,它提供了訪問數(shù)據(jù)庫 元數(shù)據(jù) 的方式。什么是 元數(shù)據(jù) 呢?元數(shù)據(jù)是關(guān)于數(shù)據(jù)的數(shù)據(jù),如數(shù)據(jù)庫名或表名,列的數(shù)據(jù)類型,或訪問權(quán)限等。
有些時候用于表述該信息的其他術(shù)語包括“數(shù)據(jù)詞典”和“系統(tǒng)目錄”。
在MySQL中,把【INFORMATION_SCHEMA】 看作是一個數(shù)據(jù)庫,確切說是信息數(shù)據(jù)庫。其中保存著關(guān)于MySQL服務器所維護的所有其他數(shù)據(jù)庫的信息。如數(shù)據(jù)庫名,數(shù)據(jù)庫的表,表欄的數(shù)據(jù)類型與訪問權(quán)限等。
在 【INFORMATION_SCHEMA 】中,有數(shù)個 只讀 表。它們實際上是 視圖 ,而不是基本表,因此,你將無法看到與之相關(guān)的任何文件。

 

 

 

上文說information_schema中有可讀表 ! 那我們來看看能不能從里面    auto_increment來!

 


 

 

選擇information_schema數(shù)據(jù)庫:

 

use information_schema;

 

查詢(information_schema數(shù)據(jù)庫里面的)tables表中所有的自增ID

select auto_increment from tables;

OK整個數(shù)據(jù)庫中所有的自增ID已經(jīng)查詢出來,每一行都代表一個數(shù)據(jù)表!?。ㄓ泻芏鄋ull,是因為該表沒有自增主鍵?。?/span>

 


如果我們想要查詢指定表的自增ID,可以用下列語句:

 

select auto_increment from tables where table_name='表名';

當然如果有同名的數(shù)據(jù)表,查出來的可就不只是一條記錄了。可以加上指定數(shù)據(jù)庫的條件。

select auto_increment from tables where table_schema='數(shù)據(jù)庫名' and table_name='表名';

 

OK大功告成,我想直接修改指定數(shù)據(jù)表的自增ID,采用以下語句:

update tables set auto_increment = 27 where table_schema='數(shù)據(jù)庫' and table_name='表名';

可是為什么報了如下錯誤呢:

Error Code: 1044. Access denied for user 'root'@'localhost' to database 'information_schema'

真正修改auto_increment的辦法是:

1
alter table 表名 auto_increment = 數(shù)字;

 

  

 

原因很簡單information_schema是只讀表,不能修改!
 

下面就是根據(jù)自己學習的一些小小經(jīng)驗將這些表進行一個大體的分類,方便大家了結(jié),要是有不足的地方請指出,我會盡快修改。
1:關(guān)于字符集和排序規(guī)則相關(guān)的系統(tǒng)表
CHARACTER_SETS :存儲數(shù)據(jù)庫相關(guān)字符集信息(memory存儲引擎)
COLLATIONS :字符集對應的排序規(guī)則
COLLATION_CHARACTER_SET_APPLICABILITY:就是一個字符集和連線校對的一個對應關(guān)系而已
下面我們說一下character sets和collations的區(qū)別:
字符集(character sets)存儲字符串,是指人類語言中最小的表義符號。例如’A'、’B'等;
排序規(guī)則(collations)規(guī)則比較字符串,collations是指在同一字符集內(nèi)字符之間的比較規(guī)則
每個字符序唯一對應一種字符集,但一個字符集可以對應多種字符序,其中有一個是默認字符序(Default Collation)
 MySQL中的字符序名稱遵從命名慣例:以字符序?qū)淖址Q開頭;以_ci(表示大小寫不敏感)、_cs(表示大小寫敏感)或_bin(表示按編碼值比較)結(jié)尾。例如:在字符序“utf8_general_ci”下,字符“a”和“A”是等價的
看一下有關(guān)于字符集和校對相關(guān)的MySQL變量:
character_set_server:默認的內(nèi)部操作字符集
character_set_client:客戶端來源數(shù)據(jù)使用的字符集
character_set_connection:連接層字符集
character_set_results:查詢結(jié)果字符集
character_set_database:當前選中數(shù)據(jù)庫的默認字符集
character_set_system:系統(tǒng)元數(shù)據(jù)(字段名等)字符集
再看一下MySQL中的字符集轉(zhuǎn)換過程:
(1). MySQL Server收到請求時將請求數(shù)據(jù)從character_set_client轉(zhuǎn)換為character_set_connection;
(2). 進行內(nèi)部操作前將請求數(shù)據(jù)從character_set_connection轉(zhuǎn)換為內(nèi)部操作字符集,其確定方法如下:
使用每個數(shù)據(jù)字段的CHARACTER SET設定值;
若上述值不存在,則使用對應數(shù)據(jù)表的DEFAULT CHARACTER SET設定值(MySQL擴展,非SQL標準);
若上述值不存在,則使用對應數(shù)據(jù)庫的DEFAULT CHARACTER SET設定值;
若上述值不存在,則使用character_set_server設定值。
(3). 將操作結(jié)果從內(nèi)部操作字符集轉(zhuǎn)換為character_set_results。
2:權(quán)限相關(guān)的一些表:
SCHEMA_PRIVILEGES:提供了數(shù)據(jù)庫的相關(guān)權(quán)限,這個表是內(nèi)存表是從mysql.db中拉去出來的。
TABLE_PRIVILEGES:提供的是表權(quán)限相關(guān)信息,信息是從 mysql.tables_priv 表中加載的
COLUMN_PRIVILEGES :這個表可以清楚就能看到表授權(quán)的用戶的對象,那張表那個庫以及授予的是什么權(quán)限,如果授權(quán)的時候加上with grant option的話,我們可以看得到PRIVILEGE_TYPE這個值必須是YES。
USER_PRIVILEGES:提供的是表權(quán)限相關(guān)信息,信息是從 mysql.user 表中加載的
通過表我們可以很清晰看得到MySQL授權(quán)的層次,SCHEMA,TABLE,COLUMN級別,當然這些都是基于用戶來授予的??梢钥吹玫組ySQL的授權(quán)也是相當?shù)募毭艿?,可以具體到列,這在某一些應用場景下還是很有用的,比如審計等。
3:存儲數(shù)據(jù)庫系統(tǒng)的實體對象的一些表:
COLUMNS:存儲表的字段信息,所有的存儲引擎
INNODB_SYS_COLUMNS :存放的是INNODB的元數(shù)據(jù), 他是依賴于SYS_COLUMNS這個統(tǒng)計表而存在的。
ENGINES :引擎類型,是否支持這個引擎,描述,是否支持事物,是否支持分布式事務,是否能夠支持事物的回滾點
EVENTS :記錄MySQL中的事件,類似于定時作業(yè)
FILES :這張表提供了有關(guān)在MySQL的表空間中的數(shù)據(jù)存儲的文件的信息,文件存儲的位置,這個表的數(shù)據(jù)是從InnoDB in-memory中拉取出來的,所以說這張表本身也是一個內(nèi)存表,每次重啟重新進行拉取。也就是我們下面要說的INNODB_SYS_DATAFILES這張表。還要注意一點的是這張表包含有臨時表的信息,所以說和SYS_DATAFILES 這張表是不能夠?qū)Φ鹊?,還是要從INNODB_SYS_DATAFILES看。如果undo表空間也配置是InnoDB 的話,那么也是會被記錄下來的。
PARAMETERS :參數(shù)表存儲了一些存儲過程和方法的參數(shù),以及存儲過程的返回值信息。存儲和方法在ROUTINES里面存儲。
PLUGINS :基本上是MySQL的插件信息,是否是活動狀態(tài)等信息。其實SHOW PLUGINS本身就是通過這張表來拉取道德數(shù)據(jù)
ROUTINES:關(guān)于存儲過程和方法function的一些信息,不過這個信息是不包括用戶自定義的,只是系統(tǒng)的一些信息。
SCHEMATA:這個表提供了實例下有多少個數(shù)據(jù)庫,而且還有數(shù)據(jù)庫默認的字符集
TRIGGERS :這個表記錄的就是觸發(fā)器的信息,包括所有的相關(guān)的信息。系統(tǒng)的和自己用戶創(chuàng)建的觸發(fā)器。
VIEWS :視圖的信息,也是系統(tǒng)的和用戶的基本視圖信息。
這些表存儲的都是一些數(shù)據(jù)庫的實體對象,方便我們進行查詢和管理,對于一個DBA來說,這些表能夠大大方便我們的工作,更快更方便的了結(jié)和查詢數(shù)據(jù)庫的相關(guān)信息。
4:約束外鍵等相關(guān)的一些表:
REFERENTIAL_CONSTRAINTS:這個表提供的外鍵相關(guān)的信息,而且只提供外鍵相關(guān)信息
TABLE_CONSTRAINTS :這個表提供的是 相關(guān)的約束信息
INNODB_SYS_FOREIGN_COLS :這個表也是存儲的INNODB關(guān)于外鍵的元數(shù)據(jù)信息和SYS_FOREIGN_COLS 存儲的信息是一致的
INNODB_SYS_FOREIGN :存儲的INNODB關(guān)于外鍵的元數(shù)據(jù)信息和SYS_FOREIGN_COLS 存儲的信息是一致的,只不過是單獨對于INNODB來說的
KEY_COLUMN_USAGE:數(shù)據(jù)庫中所有有約束的列都會存下下來,也會記錄下約束的名字和類別
為什么要把外鍵和約束單列出來呢,因為感覺這是一塊獨立的東西,雖然我們的生產(chǎn)環(huán)境大部分都不會使用外鍵,因為這會降低性能,但是合理的利用約束還是一個不錯的選擇,比如唯一約束。
5:關(guān)于管理的一些的一些表:
GLOBAL_STATUS ,GLOBAL_VARIABLES,SESSION_STATUS,SESSION_VARIABLES:這四張表分別記錄了系統(tǒng)的變量,狀態(tài)(全局和會話的信息),作為DBA相信大家也都比較熟悉了,而且這幾張表也是在系統(tǒng)重啟的時候回重新加載的。也就是內(nèi)存表。
PARTITIONS :MySQL分區(qū)表相關(guān)的信息,通過這張表我們可以查詢到分區(qū)的相關(guān)信息(數(shù)據(jù)庫中已分區(qū)的表,以及分區(qū)表的分區(qū)和每個分區(qū)的數(shù)據(jù)信息)
PROCESSLIST:show processlist其實就是從這個表拉取數(shù)據(jù),PROCESSLIST的數(shù)據(jù)是他的基礎。由于是一個內(nèi)存表,所以我們相當于在內(nèi)存中查詢一樣,這些操作都是很快的。
INNODB_CMP_PER_INDEX,INNODB_CMP_PER_INDEX_RESET:這兩個表存儲的是關(guān)于壓縮INNODB信息表的時候的相關(guān)信息,有關(guān)整個表和索引信息都有.我們知道對于一個INNODB壓縮表來說,不管是數(shù)據(jù)還是二級索引都是會被壓縮的,因為數(shù)據(jù)本身也可以看作是一個聚集索引。
INNODB_CMPMEM ,INNODB_CMPMEM_RESET:這兩個表是存放關(guān)于MySQL INNODB的壓縮頁的buffer pool信息,但是要注意一點的就是,用這兩個表來收集所有信息的表的時候,是會對性能造成嚴重的影響的,所以說默認是關(guān)閉狀態(tài)的。如果要打開這個功能的話我們要設置innodb_cmp_per_index_enabled參數(shù)為ON狀態(tài)。
INNODB_BUFFER_POOL_STATS :表提供有關(guān)INNODB 的buffer pool相關(guān)信息,和show engine innodb status提供的信息是相同的。也是show engine innodb status的信息來源。
INNODB_BUFFER_PAGE_LRU,INNODB_BUFFER_PAGE :維護了INNODB LRU LIST的相關(guān)信息
INNODB_BUFFER_PAGE :這個表就比較屌了,存的是buffer里面緩沖的頁數(shù)據(jù)。查詢這個表會對性能產(chǎn)生很嚴重的影響,千萬不要再我們自己的生產(chǎn)庫上面執(zhí)行這個語句,除非你能接受服務短暫的停頓
INNODB_SYS_DATAFILES :這張表就是記錄的表的文件存儲的位置和表空間的一個對應關(guān)系(INNODB)
INNODB_TEMP_TABLE_INFO :這個表惠記錄所有的INNODB的所有用戶使用到的信息,但是只能記錄在內(nèi)存中和沒有持久化的信息。
INNODB_METRICS :提供INNODB的各種的性能指數(shù),是對INFORMATION_SCHEMA的補充,收集的是MySQL的系統(tǒng)統(tǒng)計信息。這些統(tǒng)計信息都是可以手動配置打開還是關(guān)閉的。有以下參數(shù)都是可以控制的:innodb_monitor_enable, innodb_monitor_disable, innodb_monitor_reset, innodb_monitor_reset_all。
INNODB_SYS_VIRTUAL :表存儲的是INNODB表的虛擬列的信息,當然這個還是比較簡單的,在MySQL 5.7中,支持兩種Generated Column,即Virtual Generated Column和Stored Generated Column,前者只將Generated Column保存在數(shù)據(jù)字典中(表的元數(shù)據(jù)),并不會將這一列數(shù)據(jù)持久化到磁盤上;后者會將Generated Column持久化到磁盤上,而不是每次讀取的時候計算所得。很明顯,后者存放了可以通過已有數(shù)據(jù)計算而得的數(shù)據(jù),需要更多的磁盤空間,與實際存儲一列數(shù)據(jù)相比并沒有優(yōu)勢,因此,MySQL 5.7中,不指定Generated Column的類型,默認是Virtual Column。
INNODB_CMP,INNODB_CMP_RESET:存儲的是關(guān)于壓縮INNODB信息表的時候的相關(guān)信息,詳細請見推薦筆記。
為什么把這些表列為管理相關(guān)的表呢,因為我感覺像連接,分區(qū),壓縮表,innodb buffer pool等表,我們通過這些表都能很清晰的看到自己數(shù)據(jù)庫的相關(guān)功能的狀態(tài),特別是我們通過一些變量更容易窺透MySQL的運行狀態(tài),方便我們進行管理。
6:關(guān)于表信息和索引信息的一些表
TABLES,TABLESPACES,INNODB_SYS_TABLES ,INNODB_SYS_TABLESPACES :
TABLES這張表毫無疑問了,就是記錄的數(shù)據(jù)庫中表的信息,其中包括系統(tǒng)數(shù)據(jù)庫和用戶創(chuàng)建的數(shù)據(jù)庫。show table status like 'test1'\G的來源就是這個表;
TABLESPACES 卻是標注的活躍表空間。 這個表是不提供關(guān)于innodb的表空間信息的,對于我們來說并沒有太大作用,因為我們生產(chǎn)庫是強制INNODB的;
INNODB_SYS_TABLES 這張表依賴的是SYS_TABLES數(shù)據(jù)字典中拉取出來的。此表提供了有關(guān)表格的格式和存儲特性,包括行格式,壓縮頁面大小位級別的信息(如適用)
提供的是關(guān)于INNODB的表空間信息,其實和SYS_TABLESPACES 中的INNODB信息是一致的。
STATISTICS:這個表提供的是關(guān)于表的索引信息,所有索引的相關(guān)信息。
INNODB_SYS_INDEXES:提供相關(guān)INNODB表的索引的相關(guān)信息,和SYS_INDEXES 這個表存儲的信息基本是一樣的,只不過后者提供的是所有存儲引擎的索引信息,后者只提供INNODB表的索引信息。
INNODB_SYS_TABLESTATS
這個表就比較重要了,記錄的是MySQL的INNODB表信息以及MySQL優(yōu)化器會預估SQL選擇合適的索引信息,其實就是MySQL數(shù)據(jù)庫的統(tǒng)計信息
這個表的記錄是記錄在內(nèi)存當中的,是一個內(nèi)存表,每次重啟后就會重新記錄,所以只能記錄從上次重啟后的數(shù)據(jù)庫統(tǒng)計信息。有了這個表,我們對于索引的維護就更加方便了,我們可以查詢索引的使用次數(shù),方便清理刪除不常用的索引,提高表的更新插入等效率,節(jié)省磁盤空間。
INNODB_SYS_FIELDS :這個表記錄的是INNODB的表索引字段信息,以及字段的排名
INNODB_FT_CONFIG :這張表存的是全文索引的信息
INNODB_FT_DEFAULT_STOPWORD:這個表存放的是stopword 的信息,是和全文索引匹配起來使用的,和innodb的 INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD 是相同的,這個STOPWORD必須是在創(chuàng)建索引之前創(chuàng)建,而且必須指定字段為varchar。stopword 也就是我們所說的停止詞,全文檢索時,停止詞列表將會被讀取和檢索,在不同的字符集和排序方式下,會造成命中失敗或者找不到此數(shù)據(jù),這取決于停止詞的不同的排序方式。我們可以使用這個功能篩選不必要字段。
INNODB_FT_INDEX_TABLE:這個表存儲的是關(guān)于INNODB表有全文索引的索引使用信息的,同樣這個表也是要設置innodb_ft_aux_table以后才能夠使用的,一般情況下是空的
INNODB_FT_INDEX_CACHE :這張表存放的是插入前的記錄信息,也是為了避免DML時候昂貴的索引重組
7:關(guān)于MySQL優(yōu)化相關(guān)的一些表
OPTIMIZER_TRACE :提供的是優(yōu)化跟蹤功能產(chǎn)生的信息.
PROFILING:SHOW PROFILE可以深入的查看服務器執(zhí)行語句的工作情況。以及也能幫助你理解執(zhí)行語句消耗時間的情況。一些限制是它沒有實現(xiàn)的功能,不能查看和剖析其他連接的語句,以及剖析時所引起的消耗。
SHOW PROFILES顯示最近發(fā)給服務器的多條語句,條數(shù)根據(jù)會話變量profiling_history_size定義,默認是15,最大值為100。設為0等價于關(guān)閉分析功能。詳細信息請見MySQL profile
INNODB_FT_BEING_DELETED,INNODB_FT_DELETED: INNODB_FT_BEING_DELETED 這張表是INNODB_FT_DELETED的一個快照,只在OPTIMIZE TABLE 的時候才會使用。
8:關(guān)于MySQL事物和鎖的相關(guān)的一些表
INNODB_LOCKS:現(xiàn)在獲取的鎖,但是不含沒有獲取的鎖,而且只是針對INNODB的。
INNODB_LOCK_WAITS:系統(tǒng)鎖等待相關(guān)信息,包含了阻塞的一行或者多行的記錄,而且還有鎖請求和被阻塞改請求的鎖信息等。
INNODB_TRX:包含了所有正在執(zhí)行的的事物相關(guān)信息(INNODB),而且包含了事物是否被阻塞或者請求鎖。
 

如對本文有疑問,請?zhí)峤坏浇涣髡搲?,廣大熱心網(wǎng)友會為你解答??! 點擊進入論壇

發(fā)表評論 (404人查看,0條評論)
請自覺遵守互聯(lián)網(wǎng)相關(guān)的政策法規(guī),嚴禁發(fā)布色情、暴力、反動的言論。
昵稱:
最新評論
------分隔線----------------------------

其它欄目

· 建站教程
· 365學習

業(yè)務咨詢

· 技術(shù)支持
· 服務時間:9:00-18:00
365建站網(wǎng)二維碼

Powered by 365建站網(wǎng) RSS地圖 HTML地圖

copyright © 2013-2024 版權(quán)所有 鄂ICP備17013400號