mysql学习笔记

All is well!8023

已于 2023-08-02 17:35:39 修改

阅读量353

点赞数

文章标签： mysql 数据库

于 2023-08-02 17:32:28 首次发布

本文链接：https://blog.csdn.net/qq_36073688/article/details/132067478

版权

1、where 和 having 的区别：

执行时机不同：where是分组之前进行过滤，不满足where条件不参与分组；having是分组后对结果进行过滤。
判断条件不同：where不能对聚合函数进行判断，而having可以。

注意事项

执行顺序：where > 聚合函数 > having
分组之后，查询的字段一般为聚合函数和分组字段，查询其他字段无任何意义

2、DQL执行顺序

FROM -> WHERE -> GROUP BY -> SELECT -> ORDER BY -> LIMIT

3、联合查询 union, union all

把多次查询的结果合并，形成一个新的查询集
UNION ALL 会有重复结果，UNION 不会
联合查询比使用or效率高，不会使索引失效

4、ACID

原子性(Atomicity)：事务是不可分割的最小操作，要么全部成功，要么全部失败
一致性(Consistency)：事务完成时，必须使所有数据都保持一致状态
隔离性(Isolation)：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
持久性(Durability)：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的

5、并发事务

问题	描述
脏读	一个事务读到另一个事务还没提交的数据
不可重复读	一个事务先后读取同一条记录，但两次读取的数据不同
幻读	一个事务按照条件查询数据时，没有对应的数据行，但是再插入数据时，又发现这行数据已经存在

并发事务隔离级别：

READ_UNCOMMITTED：读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据，而未提交的数据可能会发生回滚，因此我们把该级别读取到的数据称之为脏数据，把这个问题称之为脏读；

READ_COMMITTED：读已提交，也叫提交读，该隔离级别的事务能读取到已经提交事务的数据，因此它不会有脏读问题。但由于在事务的执行中可以读取到其他事务提交的结果，所以在不同时间的相同 SQL 查询中，可能会得到不同的结果，这种现象叫做不可重复读；

REPEATABLE_READ：可重复读，它能确保同一事务多次查询的结果一致。但也会有新的问题，比如此级别的事务正在执行时，另一个事务成功的插入了某条数据，但因为它每次查询的结果都是一样的，所以会导致查询不到这条数据，自己重复插入时又失败（因为唯一约束的原因）。明明在事务中查询不到这条信息，但自己就是插入不进去，这就叫幻读（Phantom Read）；

SERIALIZABLE：串行化，最高的事务隔离级别，它会强制事务排序，使之不会发生冲突，从而解决了脏读、不可重复读和幻读问题，但因为执行效率低，所以真正使用的场景并不多。

隔离级别		脏读	不可重复读	幻读
Read uncommitted	读未提交	√	√	√
Read committed	读已提交	×	√	√
Repeatable Read(默认)	可重复读	×	×	√
Serializable	串行化	×	×	×

6、多版本并发控制（Multi-Version Concurrency Control, MVCC）

InnoDB 存储引擎的MVCC 的核心就是 Undo Log（回滚日志）+ Read View（快照读）
“CC”并发控制是通过 Read View 来实现管理，通过 Read View 原则来决定数据是否显示。同时针对不同的隔离级别，Read View 的生成策略不同，也就实现了不同的隔离级别。

MySQL 中的 MVCC 主要是通过使用事务的读写锁和快照来实现的。当一个事务开始时，MySQL 会为该事务创建一个唯一的事务 ID，称为版本号或者视图序列号。在事务执行期间，所有读操作都会记录下当前事务的版本号。

在 MVCC 机制中，读操作只能访问小于等于当前事务版本号的数据，从而避免了读取到未提交事务的中间状态数据。这样可以使得读操作不受写操作的影响，提高并发性能。

对于写操作，当一个事务修改数据时，MySQL 会将修改前的数据行保留为旧版本，并创建一个新版本的数据行。这样其他正在执行的事务仍然可以访问旧版本的数据。只有当该事务提交后，其他事务才能看到该修改结果。

需要注意的是，MySQL 的 MVCC 实现是基于存储引擎的。每个存储引擎可以根据自身特点选择不同的 MVCC 算法。例如，InnoDB 存储引擎使用了基于回滚段（undo log）和读写锁的 MVCC 实现。

总之，MySQL 的多版本并发控制（MVCC）是一种有效的并发控制机制，可以提高数据库的并发性能和事务隔离级别。

7、InnoDB和MyISAM

InnoDB支持事务，并发读写，多版本并发控制，支持行级锁。InnoDB 的主键索引和辅助索引都是使用B+树，InnoDB 通过事务日志（redo log）保证了崩溃后的可恢复性。

在 MySQL 5.5 之后，InnoDB 是默认的 MySQL 引擎。

全文索引支持（5.6版本之后）

事务支持：InnoDB 是一个支持事务的存储引擎，它遵循ACID（原子性、一致性、隔离性和持久性）特性。而 MyISAM 不支持事务处理。
并发性能：InnoDB 在并发读写的场景下表现更好，因为它实现了多版本并发控制（MVCC），可以在不阻塞其他事务的情况下执行读操作。而 MyISAM 在同时进行读写操作时，会对整个表加锁，从而导致较低的并发性能。
锁级别：InnoDB 支持行级别的锁定，可以使得多个事务能够同时操作表中的不同行数据。而 MyISAM 只支持表级别锁，所以在多个事务同时访问同一表的不同行时，会出现锁冲突问题。
索引处理方式：InnoDB 的主键索引和辅助索引都是使用B+树进行组织，支持范围查询等高级操作。而 MyISAM 使用的是B树索引结构，在查询时只能执行简单的查找操作。
故障恢复：InnoDB 通过事务日志（redo log）保证了崩溃后的可恢复性，可以将未提交的事务进行恢复。而 MyISAM 则没有类似的机制，所以在发生故障时，可能会导致数据损失。
全文搜索：MyISAM 支持全文索引，对于需要进行全文搜索的应用场景有一定的优势。而 InnoDB 在MySQL 5.6版本之后开始支持全文索引。

8、EXPLAIN 各字段含义：

id：select 查询的序列号，表示查询中执行 select 子句或者操作表的顺序（id相同，执行顺序从上到下；id不同，值越大越先执行）
select_type：表示 SELECT 的类型，常见取值有 SIMPLE（简单表，即不适用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION中的第二个或者后面的查询语句）、SUBQUERY（SELECT/WHERE之后包含了子查询）等
type：表示连接类型，性能由好到差的连接类型为 NULL、system、const、eq_ref、ref、range、index、all。正常来说保证查询到range级别，最好能达到ref级别。
possible_key：可能应用在这张表上的索引，一个或多个
Key：实际使用的索引，如果为 NULL，则没有使用索引
Key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好
rows：MySQL认为必须要执行的行数，在InnoDB引擎的表中，是一个估计值，可能并不总是准确的
filtered：表示返回结果的行数占需读取行数的百分比，filtered的值越大越好

9、b树和b+树的区别

所有的数据都会出现在叶子节点
叶子节点形成一个单向链表

MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能。

10、为什么 InnoDB 存储引擎选择使用 B+Tree 索引结构？

相对于二叉树，层级更少，搜索效率高，减少了IO
对于 B-Tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针也跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低。而B+树所有的数据都会出现在叶子节点
相对于 Hash 索引，B+Tree 支持范围匹配及排序操作（MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能）

11、索引的使用

索引分类

分类	含义	特点	关键字
主键索引	针对于表中主键创建的索引	默认自动创建，只能有一个	PRIMARY
唯一索引	避免同一个表中某数据列中的值重复	可以有多个	UNIQUE
常规索引	快速定位特定数据	可以有多个
全文索引	全文索引查找的是文本中的关键词，而不是比较索引中的值	可以有多个	FULLTEXT

在 InnoDB 存储引擎中，根据索引的存储形式，又可以分为以下两种：

分类	含义	特点
聚集索引(Clustered Index)	将数据存储与索引放一块，索引结构的叶子节点保存了行数据	必须有，而且只有一个
二级索引(Secondary Index)	将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键	可以存在多个

聚集索引选取规则：

如果存在主键，主键索引就是聚集索引
如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引
如果表没有主键或没有合适的唯一索引，则 InnoDB 会自动生成一个 rowid 作为隐藏的聚集索引

最左前缀法则

如果索引关联了多列（联合索引），要遵守最左前缀法则，最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。

如果跳跃某一列，索引将部分失效（后面的字段索引失效）。

联合索引中，出现范围查询（），范围查询右侧的列索引失效。可以用>=或者

索引失效情况

1、在索引列上进行运算操作，索引将失效。

如：explain select * from tb_user where substring(phone, 10, 2) = '15';

2、字符串类型字段使用时，不加引号，索引将失效。

如：explain select * from tb_user where phone = 17799990015;，此处phone的值没有加引号

3、模糊查询中，如果仅仅是尾部模糊匹配，索引不会是失效；如果是头部模糊匹配，索引失效。

如：explain select * from tb_user where profession like '%工程';，前后都有 % 也会失效。

4、用 or 分割开的条件，如果 or 其中一个条件的列没有索引，那么涉及的索引都不会被用到。

5、如果 MySQL 评估使用索引比全表更慢，则不使用索引。

覆盖索引&回表查询

尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中已经全部能找到），减少 select *。

explain 中 extra 字段含义：

using index condition：查找使用了索引，但是需要回表查询数据

using where; using index;：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询

如果在聚集索引中直接能找到对应的行，则直接返回行数据，只需要一次查询，哪怕是select *；如果在辅助索引中找聚集索引，如select id, name from xxx where name='xxx';，也只需要通过辅助索引(name)查找到对应的id，返回name和name索引对应的id即可，只需要一次查询；如果是通过辅助索引查找其他字段，则需要回表查询，如select id, name, gender from xxx where name='xxx';

所以尽量不要用select *，容易出现回表查询，降低效率，除非有联合索引包含了所有字段

面试题：一张表，有四个字段（id, username, password, status），由于数据量大，需要对以下SQL语句进行优化，该如何进行才是最优方案：

select id, username, password from tb_user where username='itcast';

解：给username和password字段建立联合索引，则不需要回表查询，直接覆盖索引

前缀索引

当字段类型为字符串（varchar, text等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO，影响查询效率，此时可以只降字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。

语法：create index idx_xxxx on table_name(columnn(n));

前缀长度：可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，索引选择性越高则查询效率越高，唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。

求选择性公式：

select count(distinct email) / count(*) from tb_user;select count(distinct substring(email, 1, 5)) / count(*) from tb_user;

show index 里面的sub_part可以看到接取的长度。

索引设计原则

针对于数据量较大，且查询比较频繁的表建立索引
针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引
尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高
如果是字符串类型的字段，字段长度较长，可以针对于字段的特点，建立前缀索引
尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价就越大，会影响增删改的效率
如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询

索引的优点

1、保持数据完整性（唯一性索引）

2、优化数据访问性能，提高数据检索的效率，降低数据库的IO成本。

3、改进表的连接操作join

4、对结果进行排序，通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。

4、简化聚合数据操作

索引的缺点

虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、 UPDATE和DELETE。因为更新表时， MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。
实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的。

索引为什么不是越多越好

数据量小的表不需要建立索引，建立索引会增加额外开销；
数据变更需要维护索引，更多的索引要更多维护成本；
更多的索引需要更多的空间，因为索引需要空间来存放；
首先数据量小的表不需要建立索引,因为小的表即使建立索引也不会有大的用处,还会增加额外的索引开销
不经常引用的列不要建立索引,因为不常用,即使建立了索引也没有多大意义
经常频繁更新的列不要建立索引,因为肯定会影响插入或更新的效率
索引并不是一劳永逸的,用的时间长了需要进行整理或者重建

mysql如何创建索引

1.添加PRIMARY KEY（主键索引）

mysql>ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

2.添加UNIQUE(唯一索引)

mysql>ALTER TABLE `table_name` ADD UNIQUE (

`column`

)

3.添加INDEX(普通索引)

mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

4.添加FULLTEXT(全文索引)

mysql>ALTER TABLE `table_name` ADD FULLTEXT ( `column`)

5.添加多列索引

mysql>ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

12、mysql优化方式

处理MySQL性能优化的方法有很多，以下是一些常见的优化方式：

索引优化：创建适当的索引可以提高查询性能。需要根据实际需求选择合适的索引类型和字段，并确保索引与查询语句的条件匹配。
查询优化：避免使用“SELECT *”这样的通配符查询，尽量只查询所需的字段；合理使用JOIN、UNION等操作符；避免在查询中使用函数或计算，尽量将计算移到代码层面。
表结构优化：合理设计表的结构，避免重复字段和冗余数据；使用合适的字段类型和长度，避免使用过大的字段类型；考虑合适的范式化以及反范式化来优化存储。
缓存优化：通过使用缓存技术如Redis或Memcached来减少对数据库的访问，提高响应速度。
配置优化：调整MySQL的配置参数，根据系统资源和负载情况进行合理设置。包括调整缓冲区大小、连接数、线程池大小等参数。
查询缓存：根据业务特点，使用MySQL的查询缓存功能来提高读取性能。但需要注意，查询缓存对于频繁更新的表和大规模写入的场景效果不佳。
分区和分表：对于数据量较大的表，可以考虑使用分区或分表来提高查询性能和数据管理效率。
慢查询优化：通过MySQL的慢查询日志进行分析，找出执行时间较长的SQL语句，并进行调优。

以上只是一些常见的MySQL优化手段，具体的优化策略还需根据实际情况进行。

13、SQL优化

order by优化

根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则
尽量使用覆盖索引
多字段排序，一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）
如果不可避免出现filesort，大数据量排序时，可以适当增大排序缓冲区大小 sort_buffer_size（默认256k）

CREATE INDEX index_name ON table_name (column_name DESC);

limit优化

常见的问题如limit 2000000, 10，此时需要 MySQL 排序前2000000条记录，但仅仅返回2000000 - 2000010的记录，其他记录丢弃，查询排序的代价非常大。

优化方案：一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化

group by优化

在分组操作时，可以通过索引来提高效率
分组操作时，索引的使用也是满足最左前缀法则的

如索引为idx_user_pro_age_stat，则句式可以是select ... where profession order by age，这样也符合最左前缀法则

-- 此语句耗时很长 select * from tb_sku limit 9000000, 10; --通过覆盖索引加快速度，直接通过主键索引进行排序及查询 select id from tb_sku order by id limit 9000000, 10;

update优化（避免行锁升级为表锁）

InnoDB 的行锁是针对索引加的锁，不是针对记录加的锁，并且该索引不能失效，否则会从行锁升级为表锁。

如以下两条语句：

update student set no = '123' where id = 1;，这句由于id有主键索引，所以只会锁这一行；

update student set no = '123' where name = 'test';，这句由于name没有索引，所以会把整张表都锁住进行数据更新，解决方法是给name字段添加索引

count优化：按效率排序：count(字段) < count(主键) < count(1) < count(*)，所以尽量使用 count(*)

select优化：尽量不要用select*,用到什么字段就查什么字段

14、explain type 字段讲解

含义是关联类型或访问类型，MySQL决定如何查询表中的数据，查询数据的大致范围。

从最优到最差分别为：system > const > eq_ref > ref > range > index > ALL

正常来说保证查询到range级别，最好能达到ref级别。

system：表只有一行记录（这通常是一个系统表），这是最简单和速度最快的访问方式。
const：通过索引一次就找到了，例如主键或唯一索引的精确匹配。
eq_ref：类似const类型，但是对于每个索引键值，只有一条记录与之匹配，常见于使用主键或唯一索引进行连接的情况。

ref：具有非唯一性索引的连接，返回所有与索引匹配的行。

range：只检索给定范围的行，使用了索引。
index：使用了索引覆盖扫描（Index Scan），即只需要扫描索引而不需要读取数据行，常见于索引范围扫描。
ALL:全表扫描，扫描你的聚簇索引的所有叶子节点。通常情况下需要增加索引来优化。

system,const:MySQL能对查询的某部分进行优化将其转化成一个常量（可以看show warnings 的结果）。用于 primary key 或unique key 的所有列与常数比较时，所以表最多有一行匹配，读取一次，速度比较快。system是const的特例，表里只有一条数据时为system。

eq_ref ：primary key或unique key 索引的所有部分表连接使用，最多只会返回一条符合条件的记录。这可能是在const之外最好的连接类型了。

ref:相比eq_ref ，不适用唯一索引，而是用普通索引或者唯一索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。

rang:通常出现在in,between,>,=等操作中。还是使用了索引的，如果结果集太大效率不高应该分页或者减少结果集。

index：一般出现在全表查询，扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般是用覆盖索引，二级索引一般比较小（当查询二级索引和一级索引都能满足SQL结果时，MySQL优先选择二级索引，因为一级索引记录的信息比较多，比二级索引大，直接扫描索引的叶子节点（数据结构最低层的那一层）），所以这种通常比ALL快一些。

ALL:全表扫描，扫描你的聚簇索引的所有叶子节点。通常情况下需要增加索引来优化。

15、mysql 锁

MySQL中有多种锁类型，包括乐观锁、悲观锁、全局锁、表级锁、页级锁、行级锁、共享锁、排它锁、意向共享锁、意向排它锁、间隙锁、临建锁和记录锁，下面分别介绍一下各种锁：

1. 乐观锁（Optimistic Locking）：假设并发操作时不会发生冲突，只在提交事务时检查数据是否被其他事务修改过。常用于读多写少的场景。

乐观锁的实现通常通过记录版本号或时间戳来判断数据是否被修改。

2. 悲观锁（Pessimistic Locking）：假设并发操作时会发生冲突，因此在操作期间持有锁来避免冲突。常用于写多读少的场景。

悲观锁的实现通常通过使用SELECT ... FOR UPDATE或使用LOCK IN SHARE MODE语句来加锁。

3. 全局锁（Global Lock）：对整个数据库实例加锁，限制除了超级用户外的所有查询和修改操作。一般用于备份、恢复等操作。

FLUSH TABLES WITH READ LOCK 这个命令是全局读锁定，执行了命令之后所有库所有表都被锁定只读。

4. 表级锁（Table Lock）：对整个表加锁，其他连接无法修改或读取该表的数据，但可以对其他表进行操作。

5. 页级锁（Page Lock）：对数据页（通常是连续的几个行）加锁，控制并发事务对该页的访问。适用于数据较大且并发量较高的场景。

6. 行级锁（Row Lock）：对单个行加锁，只锁定需要修改的数据行，其他行可以被同时修改或读取。并发性高，但锁管理较复杂。

7. 共享锁（Shared Lock）：也称为读锁，多个事务可以同时持有共享锁并读取数据，但不能修改数据。适用于同时读取同一数据的场景。

SELECT * FROM products WHERE id = 1 FOR SHARE;

8. 排它锁（Exclusive Lock）：也称为写锁，事务持有排它锁时，其他事务无法同时持有共享锁或排它锁，用于保护数据的写操作。

SELECT * FROM products WHERE id = 1 FOR UPDATE;

9. 意向共享锁（Intention Shared Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取共享锁。

LOCK TABLES products INTENTIONAL READ;

10. 意向排它锁（Intention Exclusive Lock）：表级锁的辅助锁，表示事务要在某个表或页级锁上获取排它锁。

LOCK TABLES products INTENTIONAL WRITE;

11. 间隙锁（Gap Lock）：锁定一个范围的键，但不包括这些键的实际值。用于防止其他事务在范围内插入数据。

12. 临建锁（Metadata Lock）：锁定数据库对象的元数据，如表结构，用于保证数据定义的一致性。

13. 记录锁（Record Lock）：行级锁的特定类型，锁定单个行，确保其他事务无法同时修改或读取该行。

扩展

MySQL中information_schema是什么

information_schema数据库是MySQL自带的，它提供了访问数据库元数据的方式。什么是元数据呢？元数据是关于数据的数据，如数据库名或表名，列的数据类型，或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。

在MySQL中，把 information_schema 看作是一个数据库，确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。在INFORMATION_SCHEMA中，有数个只读表。它们实际上是视图，而不是基本表，因此，你将无法看到与之相关的任何文件。

information_schema数据库表说明:

SCHEMATA表：提供了当前mysql实例中所有数据库的信息。是show databases的结果取之此表。

TABLES表：提供了关于数据库中的表的信息（包括视图）。详细表述了某个表属于哪个schema，表类型，表引擎，创建时间等信息。是show tables from schemaname的结果取之此表。

COLUMNS表：提供了表中的列信息。详细表述了某张表的所有列以及每个列的信息。是show columns from schemaname.tablename的结果取之此表。

STATISTICS表：提供了关于表索引的信息。是show index from schemaname.tablename的结果取之此表。

USER_PRIVILEGES（用户权限）表：给出了关于全程权限的信息。该信息源自mysql.user授权表。是非标准表。

SCHEMA_PRIVILEGES（方案权限）表：给出了关于方案（数据库）权限的信息。该信息来自mysql.db授权表。是非标准表。

TABLE_PRIVILEGES（表权限）表：给出了关于表权限的信息。该信息源自mysql.tables_priv授权表。是非标准表。

COLUMN_PRIVILEGES（列权限）表：给出了关于列权限的信息。该信息源自mysql.columns_priv授权表。是非标准表。

CHARACTER_SETS（字符集）表：提供了mysql实例可用字符集的信息。是SHOW CHARACTER SET结果集取之此表。

COLLATIONS表：提供了关于各字符集的对照信息。

COLLATION_CHARACTER_SET_APPLICABILITY表：指明了可用于校对的字符集。这些列等效于SHOW COLLATION的前两个显示字段。