专栏首页杨建荣的学习笔记MySQL关于数据字典的一个疑问

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)

所以这个问题的初步理解就是为了在数据字典层面作为一种清晰的标识,而如果想得到更多的信息,还是得翻翻代码的实现了。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-03-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • CentOS7压力测试MGR

    最近在规划CentOS7版本中的MySQL测试情况,于是找了公司内部的虚拟机来做下模拟测试。

    jeanron100
  • 最近的几个技术问题总结和答疑 (r8笔记第19天)

    笔记写了不少,有时候有的朋友问我几个关键字,我就会从脑海里进行搜索,凡是写过的,搜索一下总能找到,帮助了别人,提高了自己,何乐而不为。 但是笔记写了很多...

    jeanron100
  • 不能轻视的mysql重启过程 (r7笔记第55天)

    数据库的重启看似是一件非常简单,没有技术含量的活,这是我以前说的话。而这句话简直是戳中了我的痛点。这种活真是太有技术含量了,高深到让人需要注意太多的东西,需要做...

    jeanron100
  • 操作mysql第一次访问速度慢(远程)

    最近在使用java操作远程的mysql数据库的时候,第一次请求非常的慢,而且极其容易引起系统的崩溃报错连接超时

    Arebirth
  • mysql 配置总结( linux & macos ) 【原创】

    mysql 配置总结 Write By CS逍遥剑仙 我的主页: www.csxiaoyao.com GitHub: github.com/c...

    CS逍遥剑仙
  • Linux[CentOS]下编译安装Mysql5.7 步骤

    以后可以使用那些一键的脚本,但是要明白一些底层的操作,以后才能更得心应手。一味的用那些面板、一键安装脚本,并不是一个很好的选择。

    无道
  • Docker Compose Mysql

    新建目录后,将你需要的mysql配置文件 mymysqld.cnf 放到conf目录里:

    李郑
  • linux CentOS6.5 yum安装mysql 5.6

    3.随便在你存放文件的目录下执行,这里解释一下,由于这个mysql的yum源服务器在国外,所以下载速度会比较慢,还好mysql5.6只有79M大,而mysql5...

    斯文的程序
  • Centos安装MySQL5.7.22文档

    此时发现错误,无法创建lockfile,原因是在/var/lib目录下没有mysql文件夹,错误如下:

    AsiaYe
  • centos 手动安装mysql8

    官网太慢了,在清华镜像站下载:https://mirrors.tuna.tsinghua.edu.cn/mysql/downloads/MySQL-8.0/

    pollyduan

扫码关注云+社区

领取腾讯云代金券