information_schema詳解

information_schema數(shù)據(jù)庫是MySQL系統(tǒng)自帶的數(shù)據(jù)庫咪奖,它提供了數(shù)據(jù)庫元數(shù)據(jù)的訪問方式盗忱。
1:關于字符集和排序規(guī)則相關的系統(tǒng)表

CHARACTER_SETS :存儲數(shù)據(jù)庫相關字符集信息(memory存儲引擎)

COLLATIONS :字符集對應的排序規(guī)則

COLLATION_CHARACTER_SET_APPLICABILITY:就是一個字符集和連線校對的一個對應關系而已

下面我們說一下character sets和collations的區(qū)別:

字符集(character sets)存儲字符串,是指人類語言中最小的表義符號羊赵。例如’A'趟佃、’B'等;

排序規(guī)則(collations)規(guī)則比較字符串昧捷,collations是指在同一字符集內字符之間的比較規(guī)則

每個字符序唯一對應一種字符集闲昭,但一個字符集可以對應多種字符序,其中有一個是默認字符序(Default Collation)

MySQL中的字符序名稱遵從命名慣例:以字符序對應的字符集名稱開頭靡挥;以_ci(表示大小寫不敏感)序矩、_cs(表示大小寫敏感)或_bin(表示按編碼值比較)結尾。例如:在字符序“utf8_general_ci”下跋破,字符“a”和“A”是等價的

看一下有關于字符集和校對相關的MySQL變量:

character_set_server:默認的內部操作字符集

character_set_client:客戶端來源數(shù)據(jù)使用的字符集

character_set_connection:連接層字符集

character_set_results:查詢結果字符集

character_set_database:當前選中數(shù)據(jù)庫的默認字符集

character_set_system:系統(tǒng)元數(shù)據(jù)(字段名等)字符集

再看一下MySQL中的字符集轉換過程:

(1). MySQL Server收到請求時將請求數(shù)據(jù)從character_set_client轉換為character_set_connection簸淀;

(2). 進行內部操作前將請求數(shù)據(jù)從character_set_connection轉換為內部操作字符集,其確定方法如下:

使用每個數(shù)據(jù)字段的CHARACTER SET設定值毒返;

若上述值不存在租幕,則使用對應數(shù)據(jù)表的DEFAULT CHARACTER SET設定值(MySQL擴展,非SQL標準)拧簸;

若上述值不存在劲绪,則使用對應數(shù)據(jù)庫的DEFAULT CHARACTER SET設定值;

若上述值不存在,則使用character_set_server設定值珠叔。

(3). 將操作結果從內部操作字符集轉換為character_set_results蝎宇。

2:權限相關的一些表:

SCHEMA_PRIVILEGES:提供了數(shù)據(jù)庫的相關權限,這個表是內存表是從mysql.db中拉去出來的祷安。

TABLE_PRIVILEGES:提供的是表權限相關信息姥芥,信息是從 mysql.tables_priv 表中加載的

COLUMN_PRIVILEGES :這個表可以清楚就能看到表授權的用戶的對象,那張表那個庫以及授予的是什么權限汇鞭,如果授權的時候加上with grant option的話凉唐,我們可以看得到PRIVILEGE_TYPE這個值必須是YES。

USER_PRIVILEGES:提供的是表權限相關信息霍骄,信息是從 mysql.user 表中加載的

通過表我們可以很清晰看得到MySQL授權的層次台囱,SCHEMA,TABLE读整,COLUMN級別簿训,當然這些都是基于用戶來授予的∶准洌可以看得到MySQL的授權也是相當?shù)募毭艿那科罚梢跃唧w到列,這在某一些應用場景下還是很有用的屈糊,比如審計等的榛。

3:存儲數(shù)據(jù)庫系統(tǒng)的實體對象的一些表:

COLUMNS:存儲表的字段信息,所有的存儲引擎

INNODB_SYS_COLUMNS :存放的是INNODB的元數(shù)據(jù)逻锐, 他是依賴于SYS_COLUMNS這個統(tǒng)計表而存在的夫晌。

ENGINES :引擎類型,是否支持這個引擎昧诱,描述晓淀,是否支持事物,是否支持分布式事務盏档,是否能夠支持事物的回滾點

EVENTS :記錄MySQL中的事件要糊,類似于定時作業(yè)

FILES :這張表提供了有關在MySQL的表空間中的數(shù)據(jù)存儲的文件的信息,文件存儲的位置妆丘,這個表的數(shù)據(jù)是從InnoDB in-memory中拉取出來的,所以說這張表本身也是一個內存表局劲,每次重啟重新進行拉取勺拣。也就是我們下面要說的INNODB_SYS_DATAFILES這張表。還要注意一點的是這張表包含有臨時表的信息鱼填,所以說和SYS_DATAFILES 這張表是不能夠對等的药有,還是要從INNODB_SYS_DATAFILES看。如果undo表空間也配置是InnoDB 的話,那么也是會被記錄下來的愤惰。

PARAMETERS :參數(shù)表存儲了一些存儲過程和方法的參數(shù)苇经,以及存儲過程的返回值信息。存儲和方法在ROUTINES里面存儲宦言。

PLUGINS :基本上是MySQL的插件信息扇单,是否是活動狀態(tài)等信息。其實SHOW PLUGINS本身就是通過這張表來拉取道德數(shù)據(jù)

ROUTINES:關于存儲過程和方法function的一些信息奠旺,不過這個信息是不包括用戶自定義的蜘澜,只是系統(tǒng)的一些信息。

SCHEMATA:這個表提供了實例下有多少個數(shù)據(jù)庫响疚,而且還有數(shù)據(jù)庫默認的字符集

TRIGGERS :這個表記錄的就是觸發(fā)器的信息鄙信,包括所有的相關的信息。系統(tǒng)的和自己用戶創(chuàng)建的觸發(fā)器忿晕。

VIEWS :視圖的信息装诡,也是系統(tǒng)的和用戶的基本視圖信息。

這些表存儲的都是一些數(shù)據(jù)庫的實體對象践盼,方便我們進行查詢和管理鸦采,對于一個DBA來說,這些表能夠大大方便我們的工作宏侍,更快更方便的了結和查詢數(shù)據(jù)庫的相關信息赖淤。

4:約束外鍵等相關的一些表:

REFERENTIAL_CONSTRAINTS:這個表提供的外鍵相關的信息,而且只提供外鍵相關信息

TABLE_CONSTRAINTS :這個表提供的是 相關的約束信息

INNODB_SYS_FOREIGN_COLS :這個表也是存儲的INNODB關于外鍵的元數(shù)據(jù)信息和SYS_FOREIGN_COLS 存儲的信息是一致的

INNODB_SYS_FOREIGN :存儲的INNODB關于外鍵的元數(shù)據(jù)信息和SYS_FOREIGN_COLS 存儲的信息是一致的谅河,只不過是單獨對于INNODB來說的

KEY_COLUMN_USAGE:數(shù)據(jù)庫中所有有約束的列都會存下下來咱旱,也會記錄下約束的名字和類別

為什么要把外鍵和約束單列出來呢,因為感覺這是一塊獨立的東西绷耍,雖然我們的生產(chǎn)環(huán)境大部分都不會使用外鍵吐限,因為這會降低性能,但是合理的利用約束還是一個不錯的選擇褂始,比如唯一約束诸典。

5:關于管理的一些的一些表:

GLOBAL_STATUS ,GLOBAL_VARIABLES崎苗,SESSION_STATUS狐粱,SESSION_VARIABLES:這四張表分別記錄了系統(tǒng)的變量,狀態(tài)(全局和會話的信息)胆数,作為DBA相信大家也都比較熟悉了肌蜻,而且這幾張表也是在系統(tǒng)重啟的時候回重新加載的。也就是內存表必尼。

PARTITIONS :MySQL分區(qū)表相關的信息蒋搜,通過這張表我們可以查詢到分區(qū)的相關信息(數(shù)據(jù)庫中已分區(qū)的表篡撵,以及分區(qū)表的分區(qū)和每個分區(qū)的數(shù)據(jù)信息)

PROCESSLIST:show processlist其實就是從這個表拉取數(shù)據(jù),PROCESSLIST的數(shù)據(jù)是他的基礎豆挽。由于是一個內存表育谬,所以我們相當于在內存中查詢一樣,這些操作都是很快的帮哈。

INNODB_CMP_PER_INDEX膛檀,INNODB_CMP_PER_INDEX_RESET:這兩個表存儲的是關于壓縮INNODB信息表的時候的相關信息,有關整個表和索引信息都有.我們知道對于一個INNODB壓縮表來說,不管是數(shù)據(jù)還是二級索引都是會被壓縮的,因為數(shù)據(jù)本身也可以看作是一個聚集索引。

INNODB_CMPMEM 但汞,INNODB_CMPMEM_RESET:這兩個表是存放關于MySQL INNODB的壓縮頁的buffer pool信息宿刮,但是要注意一點的就是,用這兩個表來收集所有信息的表的時候,是會對性能造成嚴重的影響的,所以說默認是關閉狀態(tài)的。如果要打開這個功能的話我們要設置innodb_cmp_per_index_enabled參數(shù)為ON狀態(tài)私蕾。

INNODB_BUFFER_POOL_STATS :表提供有關INNODB 的buffer pool相關信息僵缺,和show engine innodb status提供的信息是相同的。也是show engine innodb status的信息來源踩叭。

INNODB_BUFFER_PAGE_LRU磕潮,INNODB_BUFFER_PAGE :維護了INNODB LRU LIST的相關信息

INNODB_BUFFER_PAGE :這個表就比較屌了,存的是buffer里面緩沖的頁數(shù)據(jù)容贝。查詢這個表會對性能產(chǎn)生很嚴重的影響自脯,千萬不要再我們自己的生產(chǎn)庫上面執(zhí)行這個語句,除非你能接受服務短暫的停頓

INNODB_SYS_DATAFILES :這張表就是記錄的表的文件存儲的位置和表空間的一個對應關系(INNODB)

INNODB_TEMP_TABLE_INFO :這個表惠記錄所有的INNODB的所有用戶使用到的信息斤富,但是只能記錄在內存中和沒有持久化的信息膏潮。

INNODB_METRICS :提供INNODB的各種的性能指數(shù),是對INFORMATION_SCHEMA的補充满力,收集的是MySQL的系統(tǒng)統(tǒng)計信息焕参。這些統(tǒng)計信息都是可以手動配置打開還是關閉的。有以下參數(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:存儲的是關于壓縮INNODB信息表的時候的相關信息宛瞄,詳細請見推薦筆記。

為什么把這些表列為管理相關的表呢交胚,因為我感覺像連接份汗,分區(qū),壓縮表蝴簇,innodb buffer pool等表杯活,我們通過這些表都能很清晰的看到自己數(shù)據(jù)庫的相關功能的狀態(tài),特別是我們通過一些變量更容易窺透MySQL的運行狀態(tài)熬词,方便我們進行管理旁钧。

6:關于表信息和索引信息的一些表

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 卻是標注的活躍表空間骑疆。 這個表是不提供關于innodb的表空間信息的田篇,對于我們來說并沒有太大作用,因為我們生產(chǎn)庫是強制INNODB的封断;

INNODB_SYS_TABLES 這張表依賴的是SYS_TABLES數(shù)據(jù)字典中拉取出來的斯辰。此表提供了有關表格的格式和存儲特性,包括行格式坡疼,壓縮頁面大小位級別的信息(如適用)

提供的是關于INNODB的表空間信息彬呻,其實和SYS_TABLESPACES 中的INNODB信息是一致的。

STATISTICS:這個表提供的是關于表的索引信息柄瑰,所有索引的相關信息闸氮。

INNODB_SYS_INDEXES:提供相關INNODB表的索引的相關信息,和SYS_INDEXES 這個表存儲的信息基本是一樣的教沾,只不過后者提供的是所有存儲引擎的索引信息蒲跨,后者只提供INNODB表的索引信息。

INNODB_SYS_TABLESTATS:

這個表就比較重要了授翻,記錄的是MySQL的INNODB表信息以及MySQL優(yōu)化器會預估SQL選擇合適的索引信息或悲,其實就是MySQL數(shù)據(jù)庫的統(tǒng)計信息

這個表的記錄是記錄在內存當中的孙咪,是一個內存表,每次重啟后就會重新記錄巡语,所以只能記錄從上次重啟后的數(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:這個表存儲的是關于INNODB表有全文索引的索引使用信息的,同樣這個表也是要設置innodb_ft_aux_table以后才能夠使用的钓试,一般情況下是空的

INNODB_FT_INDEX_CACHE :這張表存放的是插入前的記錄信息装黑,也是為了避免DML時候昂貴的索引重組

7:關于MySQL優(yōu)化相關的一些表

OPTIMIZER_TRACE :提供的是優(yōu)化跟蹤功能產(chǎn)生的信息.

PROFILING:SHOW PROFILE可以深入的查看服務器執(zhí)行語句的工作情況。以及也能幫助你理解執(zhí)行語句消耗時間的情況弓熏。一些限制是它沒有實現(xiàn)的功能恋谭,不能查看和剖析其他連接的語句,以及剖析時所引起的消耗挽鞠。

SHOW PROFILES顯示最近發(fā)給服務器的多條語句疚颊,條數(shù)根據(jù)會話變量profiling_history_size定義,默認是15信认,最大值為100材义。設為0等價于關閉分析功能。詳細信息請見MySQL profile

INNODB_FT_BEING_DELETED,INNODB_FT_DELETED: INNODB_FT_BEING_DELETED 這張表是INNODB_FT_DELETED的一個快照,只在OPTIMIZE TABLE 的時候才會使用嫁赏。

8:關于MySQL事物和鎖的相關的一些表

INNODB_LOCKS:現(xiàn)在獲取的鎖其掂,但是不含沒有獲取的鎖,而且只是針對INNODB的潦蝇。

INNODB_LOCK_WAITS:系統(tǒng)鎖等待相關信息款熬,包含了阻塞的一行或者多行的記錄深寥,而且還有鎖請求和被阻塞改請求的鎖信息等。

INNODB_TRX:包含了所有正在執(zhí)行的的事物相關信息(INNODB)贤牛,而且包含了事物是否被阻塞或者請求鎖翩迈。

我們通過這些表就能夠很方便的查詢出來未結束的事物和被阻塞的進程

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市盔夜,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌堤魁,老刑警劉巖喂链,帶你破解...
    沈念sama閱讀 218,755評論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異妥泉,居然都是意外死亡椭微,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,305評論 3 395
  • 文/潘曉璐 我一進店門盲链,熙熙樓的掌柜王于貴愁眉苦臉地迎上來蝇率,“玉大人,你說我怎么就攤上這事刽沾”灸剑” “怎么了?”我有些...
    開封第一講書人閱讀 165,138評論 0 355
  • 文/不壞的土叔 我叫張陵侧漓,是天一觀的道長锅尘。 經(jīng)常有香客問我,道長布蔗,這世上最難降的妖魔是什么藤违? 我笑而不...
    開封第一講書人閱讀 58,791評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮纵揍,結果婚禮上顿乒,老公的妹妹穿的比我還像新娘。我一直安慰自己泽谨,他們只是感情好璧榄,可當我...
    茶點故事閱讀 67,794評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著隔盛,像睡著了一般犹菱。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上吮炕,一...
    開封第一講書人閱讀 51,631評論 1 305
  • 那天腊脱,我揣著相機與錄音,去河邊找鬼龙亲。 笑死陕凹,一個胖子當著我的面吹牛悍抑,可吹牛的內容都是我干的。 我是一名探鬼主播杜耙,決...
    沈念sama閱讀 40,362評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼搜骡,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了佑女?” 一聲冷哼從身側響起记靡,我...
    開封第一講書人閱讀 39,264評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎团驱,沒想到半個月后摸吠,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,724評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡嚎花,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3 336
  • 正文 我和宋清朗相戀三年寸痢,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片紊选。...
    茶點故事閱讀 40,040評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡啼止,死狀恐怖,靈堂內的尸體忽然破棺而出兵罢,到底是詐尸還是另有隱情献烦,我是刑警寧澤,帶...
    沈念sama閱讀 35,742評論 5 346
  • 正文 年R本政府宣布趣些,位于F島的核電站仿荆,受9級特大地震影響,放射性物質發(fā)生泄漏坏平。R本人自食惡果不足惜拢操,卻給世界環(huán)境...
    茶點故事閱讀 41,364評論 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望舶替。 院中可真熱鬧令境,春花似錦、人聲如沸顾瞪。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,944評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽陈醒。三九已至惕橙,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間钉跷,已是汗流浹背弥鹦。 一陣腳步聲響...
    開封第一講書人閱讀 33,060評論 1 270
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人彬坏。 一個月前我還...
    沈念sama閱讀 48,247評論 3 371
  • 正文 我出身青樓朦促,卻偏偏與公主長得像,于是被迫代替她去往敵國和親栓始。 傳聞我的和親對象是個殘疾皇子务冕,可洞房花燭夜當晚...
    茶點故事閱讀 44,979評論 2 355

推薦閱讀更多精彩內容