今天看著MySQL的數(shù)據(jù)字典，突然想到一個(gè)問題：為什么MySQL數(shù)據(jù)字典 information_schema中的表名是大寫，而performance_schema和其他庫中的是小寫？

帶著這個(gè)問題，我開始了一些猜測和自我論證。

首先大小寫的這個(gè)情況是相對不兼容的。

比如在performance_schema中，根據(jù)關(guān)鍵字user可以找到兩個(gè)相關(guān)的表。 

mysql> show tables  like 'user%';  
+--------------------------------------+  
| Tables_in_performance_schema (user%) |  
+--------------------------------------+  
| user_variables_by_thread             |  
| users                                |  
+--------------------------------------+  
2 rows in set (0.00 sec)  

但是如果我改做大寫，是不能識別的，這在其他的數(shù)據(jù)庫里也是類似的處理方式。 

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) 

如果從物理文件的角度來看，你會(huì)發(fā)現(xiàn)在MySQL中information_schema這個(gè)數(shù)據(jù)庫和其他數(shù)據(jù)庫不同，沒有一個(gè)指定的目錄存在。 

[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  

這個(gè)數(shù)據(jù)的存儲(chǔ)就好比Oracle里面的系統(tǒng)表空間，所以information_schema是名副其實(shí)的數(shù)據(jù)字典庫。

而performance_schema則是一個(gè)內(nèi)存庫，它的存儲(chǔ)引擎是特別的一種，不是InnoDB也不是MyISAM,Memory,而是performance_schema

帶著疑問我繼續(xù)切換到了information_schema中，可以很明顯的發(fā)現(xiàn)information_schema中的數(shù)據(jù)字典大多是Memory存儲(chǔ)引擎。 

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)  

所以數(shù)據(jù)字典的結(jié)構(gòu)其實(shí)還算是比價(jià)繁雜，涉及多個(gè)存儲(chǔ)引擎，涉及多中規(guī)則和處理方式。

如果我們仔細(xì)查看上面的語句，就會(huì)發(fā)現(xiàn)，這些數(shù)據(jù)字典都是temporary table.

明白了這些，對我們分析問題的方向就很有利了。

所以我的初步設(shè)想就是通過這種命名方式能夠標(biāo)識出來它就是臨時(shí)表，避免混淆。

怎么理解呢。

如果一個(gè)數(shù)據(jù)庫中存在一個(gè)臨時(shí)表，一個(gè)普通表，名字都是test，可不可行？

不要猜行不行，而是快速驗(yàn)證一下。 

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) 

這個(gè)時(shí)候插入一條記錄，顯示成功，但是我們卻沒有辦法判斷到底是插入到了哪個(gè)表里。 

mysql> insert into tmp values(1,'aa');  
Query OK, 1 row affected (0.00 sec)  

所以我們可以用排除的方式來驗(yàn)證，我們刪掉tmp,然后查看剩下的數(shù)據(jù)到底在哪里？

刪除成功，但是這個(gè)時(shí)候我們還需要其他的信息來佐證。 

mysql> drop table tmp ;  
Query OK, 0 rows affected (0.00 sec)  

查看tmp的定義信息，很明顯drop的tmp是臨時(shí)表。 

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)  

那么插入的數(shù)據(jù)到了哪里呢，一查便知，顯示為0，則很顯然數(shù)據(jù)是插入到了臨時(shí)表tmp中。 

mysql> select count(*)from tmp ;  
+----------+  
| count(*) |  
+----------+  
|        0 |  
+----------+  
1 row in set (0.00 sec)  

而如果我們繼續(xù)換個(gè)思路，定義兩個(gè)表，一個(gè)是大寫的TABLES,一個(gè)是小寫的tables

則默認(rèn)的情況下也是不會(huì)沖突的，盡管tables是在數(shù)據(jù)字典層面的一個(gè)表，但是在其他數(shù)據(jù)庫中依舊可以正常處理，命名還是不會(huì)沖突。 

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)  

所以這個(gè)問題的初步理解就是為了在數(shù)據(jù)字典層面作為一種清晰的標(biāo)識，而如果想得到更多的信息，還是得翻翻代碼的實(shí)現(xiàn)了。