MySQL關於資料字典的一個疑問
今天看著MySQL的資料字典,突然想到一個問題:為什麼MySQL資料字典 information_schema中的表名是大寫,而performance_schema和其他庫中的是小寫?
帶著這個問題,我開始了一些猜測和自我論證。
首先大小寫的這個情況是相對不相容的。
比如在performance_schema中,根據關鍵字user可以找到兩個相關的表。
mysql> show tables like 'user%';
+--------------------------------------+
| Tables_in_performance_schema (user%) |
+--------------------------------------+
| user_variables_by_thread |
| users |
+--------------------------------------+
2 rows in set (0.00 sec)
但是如果我改做大寫,是不能識別的,這在其他的資料庫裡也是類似的處理方式。
mysql> desc USERS;
ERROR 1146 (42S02): Table 'performance_schema.USERS' doesn't exist
mysql> select database();
+--------------------+
| database() |
+--------------------+
| performance_schema |
+--------------------+
1 row in set (0.00 sec)
而在information_schema中,則是相對相容的。
mysql> select count(*)from tables; select count(*)from TABLES;
+----------+
| count(*) |
+----------+
| 383 |
+----------+
1 row in set (0.01 sec)
+----------+
| count(*) |
+----------+
| 383 |
+----------+
1 row in set (0.00 sec)
如果從物理檔案的角度來看,你會發現在MySQL中information_schema這個資料庫和其他資料庫不同,沒有一個指定的目錄存在。
[root@dev01 mysql]# ll
total 188796
-rw-r----- 1 mysql mysql 56 Jan 2 12:37 auto.cnf
-rw-r----- 1 mysql mysql 5 Mar 13 14:26 dev01.pid
drwxr-x--- 2 mysql mysql 12288 Mar 9 10:44 devopsdb
drwxr-x--- 2 mysql mysql 4096 Jan 2 12:38 dms_metadata
-rw-r----- 1 mysql mysql 1292 Jan 26 19:44 ib_buffer_pool
-rw-r----- 1 mysql mysql 79691776 Mar 13 23:27 ibdata1
-rw-r----- 1 mysql mysql 50331648 Mar 13 23:27 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 Mar 13 23:27 ib_logfile1
-rw-r----- 1 mysql mysql 12582912 Mar 13 23:36 ibtmp1
drwxr-x--- 2 mysql mysql 4096 Jan 24 19:04 kmp
drwxr-x--- 2 mysql mysql 4096 Jan 2 12:37 mysql
-rw-r----- 1 mysql mysql 324407 Mar 13 21:54 mysqld.log
drwxr-x--- 2 mysql mysql 4096 Jan 2 12:37 performance_schema
drwxr-x--- 2 mysql mysql 12288 Jan 2 12:37 sys
drwxr-x--- 2 mysql mysql 4096 Mar 13 23:27 test
這個資料的儲存就好比Oracle裡面的系統表空間,所以information_schema是名副其實的資料字典庫。
而performance_schema則是一個記憶體庫,它的儲存引擎是特別的一種,不是InnoDB也不是MyISAM,Memory,而是performance_schema
帶著疑問我繼續切換到了information_schema中,可以很明顯的發現information_schema中的資料字典大多是Memory儲存引擎。
mysql> show create table tables \G
*************************** 1. row ***************************
Table: TABLES
Create Table: CREATE TEMPORARY TABLE `TABLES` (
`TABLE_CATALOG` varchar(512) NOT NULL DEFAULT '',
。。。
`TABLE_COMMENT` varchar(2048) NOT NULL DEFAULT ''
) ENGINE=MEMORY DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
還要一些是InnoDB的。
mysql> show create table PLUGINS\G
*************************** 1. row ***************************
Table: PLUGINS
Create Table: CREATE TEMPORARY TABLE `PLUGINS` (
`PLUGIN_NAME` varchar(64) NOT NULL DEFAULT '',
`PLUGIN_VERSION` varchar(20) NOT NULL DEFAULT '',
`PLUGIN_STATUS` varchar(10) NOT NULL DEFAULT '',
。。。
`LOAD_OPTION` varchar(64) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
所以資料字典的結構其實還算是比價繁雜,涉及多個儲存引擎,涉及多中規則和處理方式。
如果我們仔細檢視上面的語句,就會發現,這些資料字典都是temporary table.
明白了這些,對我們分析問題的方向就很有利了。
所以我的初步設想就是透過這種命名方式能夠標識出來它就是臨時表,避免混淆。
怎麼理解呢。
如果一個資料庫中存在一個臨時表,一個普通表,名字都是test,可不可行?
不要猜行不行,而是快速驗證一下。
mysql> create table tmp (id int,name varchar(30));
Query OK, 0 rows affected (0.09 sec)
mysql> create temporary table tmp(id int,name varchar(30));
Query OK, 0 rows affected (0.00 sec)
這個時候插入一條記錄,顯示成功,但是我們卻沒有辦法判斷到底是插入到了哪個表裡。
mysql> insert into tmp values(1,'aa');
Query OK, 1 row affected (0.00 sec)
所以我們可以用排除的方式來驗證,我們刪掉tmp,然後檢視剩下的資料到底在哪裡?
刪除成功,但是這個時候我們還需要其他的資訊來佐證。
mysql> drop table tmp ;
Query OK, 0 rows affected (0.00 sec)
檢視tmp的定義資訊,很明顯drop的tmp是臨時表。
mysql> show create table tmp ;
+-------+---------------------------------------------+
| Table | Create Table
+-------+--------------------------------------------+
| tmp | CREATE TABLE `tmp` (
`id` int(11) DEFAULT NULL,
`name` varchar(30) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+-----------------------------------------+
1 row in set (0.00 sec)
那麼插入的資料到了哪裡呢,一查便知,顯示為0,則很顯然資料是插入到了臨時表tmp中。
mysql> select count(*)from tmp ;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)
而如果我們繼續換個思路,定義兩個表,一個是大寫的TABLES,一個是小寫的tables
則預設的情況下也是不會衝突的,儘管tables是在資料字典層面的一個表,但是在其他資料庫中依舊可以正常處理,命名還是不會衝突。
mysql> create table TABLES (id INT );
Query OK, 0 rows affected (0.12 sec)
mysql> create table tables (id INT );
Query OK, 0 rows affected (0.11 sec)
所以這個問題的初步理解就是為了在資料字典層面作為一種清晰的標識,而如果想得到更多的資訊,還是得翻翻程式碼的實現了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2152370/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於字典和陣列的疑問陣列
- 關於使用ThreadLocal管理資料庫連線的一些疑問thread資料庫
- 關於TargetServiceFactoryVisitable的疑問
- 關於Jive論壇中CACHE Hash機制的一個疑問
- MySQL 8.0 20個 InnoDB 及資料字典相關的新特性MySql
- 關於Multiple Buffer Pools的一些疑問
- 【Mysql】關於一個mysql的坑比時區問題MySql
- 關於 dingo API 的疑問GoAPI
- 關於jdonframework框架的小疑問Framework框架
- 關於設計模式的疑問設計模式
- 關於dataguard需要查詢的資料字典
- 關於一個資料庫列設計的問題資料庫
- MySQL資料字典MySql
- 基於mysql資料庫 關於sql優化的一些問題MySql資料庫優化
- 關於非同步介面呼叫的疑問?非同步
- 關於no-wait latch 的疑問AI
- 關於論壇快取的疑問快取
- 關於JTA實現的疑問
- 關於資料字典的查詢效率優化優化
- 問一個有關JBPM連MySQL資料庫的問題,高手請進MySql資料庫
- 關於String內的indexOf方法的一些疑問Index
- 關於python訪問字典的方法Python
- 有關事件的一點疑問事件
- [20170515]資料庫啟動的一個疑問.txt資料庫
- 一個關於資料庫閃回區問題的處理資料庫
- 關於資料字典的查詢效率最佳化
- 關於原型模式的看法和疑問原型模式
- 關於DDD學習過程中的一些疑問
- 關於資料儲存的一個故事
- 關於go和資料庫連線,客戶端以及驅動的疑問?Go資料庫客戶端
- 關於執行緒使用中的幾個疑問,請教大家!執行緒
- 【疑難系列】 一個看起來是資料庫死鎖的問題資料庫
- 關於教程的一個問題
- MySQL 8.0 之資料字典MySql
- navicat生成mysql資料字典MySql
- 有幾點關於C語言的疑問C語言
- 關於Proxy和Decorator設計模式的疑問設計模式
- 關於多執行緒協作的疑問執行緒