共計 4252 個字符，預計需要花費 11 分鐘才能閱讀完成。
這篇文章主要講解了“MySQL 數據字典 information_schema 中的表名為什么要大寫”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“MySQL 數據字典 information_schema 中的表名為什么要大寫”吧！
問題：為什么 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)
所以這個問題的初步理解就是為了在數據字典層面作為一種清晰的標識，而如果想得到更多的信息，還是得翻翻代碼的實現了。
感謝各位的閱讀，以上就是“MySQL 數據字典 information_schema 中的表名為什么要大寫”的內容了，經過本文的學習后，相信大家對 MySQL 數據字典 information_schema 中的表名為什么要大寫這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
