MySQL里默认的几个库是干啥的?

本文深入解析MySQL自带的information_schema、performance_schema、sys、mysql四个核心数据库的功能与作用,涵盖权限管理、性能监控、系统配置等关键信息。

本文涉及:MySQL安装后自带的4个数据库:information_schema、

performance_schema、sys、mysql的作用及其中各个表所存储的数据含义

information_schema

information_schema是mysql自带的一个信息数据库,其保存着关于mysql服务器所维护的所有其他数据库的信息,如数据库名,数据库的表,表栏的数据类型与访问权限等

也就是说当你建立一个新的数据库,或者在已有的数据库中增删改表的话,都会记录在information_schema库中

相关表:

  • character_sets:存储数据库相关字符集信息(memory存储引擎)

  • collations:字符集对应的排序规则

  • collation_character_set_applicability:字符集和连线校对的对应关系

  • schema_privileges:提供了数据库的相关权限

  • table_privileges:  提供的是表权限相关信息

  • column_privileges :表授权的用户的权限

  • user_privileges:提供的是用户表权限相关信息

  • columns:存储所有表的所有字段信息

  • innodb_sys_columns :innodb的元数据

  • engines :引擎类型,是否支持这个引擎,描述,是否支持事物,是否支持分布式事务,是否能够支持事物的回滚点

  • events :记录mysql中的事件,类似于定时作业

  • files :这张表提供了有关在mysql的表空间中的数据存储的文件的信息,文件存储的位置

  • parameters :参数表存储了一些存储过程和方法的参数,以及存储过程的返回值信息

  • plugins :mysql的插件信息,是否是活动状态等信息

  • routines:关于存储过程和方法function的一些信息

  • schemata:这个表提供了实例下有多少个数据库,而且还有数据库默认的字符集

  • triggers :触发器的信息

  • views :视图的信息

  • referential_constraints:这个表提供的外键相关的信息

  • table_constraints :这个表提供的是 相关的约束信息

  • innodb_sys_foreign_cols :innodb关于外键的元数据信息

  • key_column_usage  :数据库中所有有约束的列

  • global_status:系统状态

  • global_variables:系统变量

  • session_status:session状态

  • session_variables:session变量

  • partitions :mysql分区表相关的信息

  • processlist:当前线程列表

  • innodb_cmp_per_index,innodb_cmp_per_index_reset:关于压缩innodb信息表的时候的相关信息

  • innodb_cmpmem ,innodb_cmpmem_reset:innodb的压缩页的buffer pool信息

  • innodb_buffer_pool_stats :表提供有关innodb 的buffer pool相关信息

  • innodb_buffer_page_lru,innodb_buffer_page :维护了innodb lru list的相关信息

  • innodb_buffer_page :buffer里面缓冲的页数据

  • innodb_sys_datafiles :这张表就是记录的表的文件存储的位置和表空间的一个对应关系

  • innodb_temp_table_info :所有的innodb的所有用户使用到的信息

  • innodb_metrics :提供innodb的各种的性能指数

  • innodb_sys_virtual :表存储的是innodb表的虚拟列的信息

  • innodb_cmp,innodb_cmp_reset:存储的是关于压缩innodb信息表的时候的相关信息

  • tables:数据库中表的信息

  • tablespaces:活跃表空间

  • innodb_sys_tables:表格的格式和存储特性,包括行格式,压缩页面大小位级别的信息

  • statistics:关于表的索引信息

  • innodb_sys_indexes:innodb表的索引的相关信息

  • innodb_sys_tablestats:mysql数据库的统计信息

  • innodb_sys_fields :innodb的表索引字段信息,以及字段的排名

  • innodb_ft_config :这张表存的是全文索引的信息

  • innodb_ft_default_stopword:stopword 的信息

  • innodb_ft_index_cache :这张表存放的是插入前的记录信息,也是为了避免dml时候昂贵的索引重组

  • optimizer_trace :提供的是优化跟踪功能产生的信息

  • profiling:服务器执行语句的工作情况

  • innodb_ft_being_deleted:nnodb_ft_deleted的一个快照

  • innodb_locks: innodb现在获取的锁

  • innodb_lock_waits:系统锁等待相关信息,包含了阻塞的一行或者多行的记录,而且还有锁请求和被阻塞改请求的锁信息等

  • innodb_trx:包含了所有正在执行的的事物相关信息,而且包含了事物是否被阻塞或者请求锁

performance_schema

主要用于收集数据库服务器性能参数

相关表:

  • setup_actors:配置用户纬度的监控,默认监控所有用户

  • setup_consumers:配置events的消费者类型,即收集的events写入到哪些统计表中

  • setup_instruments:配置具体的instrument

  • setup_objects:配置监控对象,默认对mysql、performance_schema和information_schema中的表都不监控,而其它所有表都监控。

  • setup_timers:配置每种类型指令的统计时间单位

  • cond_instances:系统中使用的条件变量的对象

  • file_instances:系统中打开了文件的对象,包括ibdata文件,redo文件,binlog文件,用户的表文件等

  • mutex_instances:系统中使用互斥量对象的所有记录

  • rwlock_instances: 系统中使用读写锁对象的所有记录

  • socket_instances:活跃会话对象实例

  • events_waits_current:记录了当前线程等待的事件

  • events_waits_history:记录了每个线程最近等待的10个事件

  • events_waits_history_long:记录了最近所有线程产生的10000个事件

  • events_stages_current:记录了当前线程所处的执行阶段

  • events_stages_history:记录了当前线程所处的执行阶段10条历史记录

  • events_stages_history_long:记录了当前线程所处的执行阶段10000条历史记录

  • events_statements_current:最顶层的请求,SQL语句或是COMMAND

  • users:记录用户连接数信息

  • hosts:记录了主机连接数信息

  • accounts:记录了用户主机连接数信息

  • events_waits_summary_global_by_event_name:按等待事件类型聚合

  • events_waits_summary_by_instance:按等待事件对象聚合

  • events_waits_summary_by_thread_by_event_name:按每个线程和事件来统计

  • events_stages_summary_global_by_event_name:按事件阶段类型聚合

  • events_stages_summary_by_thread_by_event_name:按每个线程和事件来阶段统计

  • events_statements_summary_by_digest:按照事件的语句进行聚合

  • events_statements_summary_global_by_event_name:按照事件的语句进行聚合

  • events_statements_summary_by_thread_by_event_name:按照线程和事件的语句进行聚合

  • file_summary_by_instance:按事件类型统计(物理IO维度)

  • file_summary_by_event_name:具体文件统计(物理IO维度)

  • table_io_waits_summary_by_table:根据wait/io/table/sql/handler,聚合每个表的I/O操作(逻辑IO纬度)

  • table_io_waits_summary_by_index_usage:按索引维度统计

  • table_lock_waits_summary_by_table:聚合了表锁等待事件

  • socket_summary_by_instance:socket聚合统计表

  • performance_timers:系统支持的统计时间单位

  • threads:监视服务端的当前运行的线程

sys

Sys库是一个简单版的performance_schema

相关表:

  • sys_config:用于sys schema库的配置

相关视图(以_*结尾的代表多个表):

  • host_* : 以ip分组相关的统计信息

  • innodb_* : innodb buffer 相关信息

  • io_* : 数据内不同维度展的io相关的信息

  • memory_* : 以ip,连接,用户,分配的类型分组及总的占用显示内存的使用

  • metrics : db的内部的统计值

  • processlist : 线程相关的信息

  • ps_check_lost_instrumentation: 没有工具统计的一些变量

  • schema _*: 表结构相关的信息

  • session : 用户连接相关的信息

  • statement_analysis : 基于语句的统计信息

  • statements_*: 出错的语句,进行全表扫描、运行时间超长等

  • user_* : 和host_开头的相似,只是以用户分组统计

  • wait_*:  等待事件

  • waits_* : 以ip,用户分组统计出来的一些延迟事件

mysql

存储数据库的用户、权限设置、关键字等mysql自己需要使用的控制和管理信息

相关表:

  • user:用户表

  • db:存储了某个用户对一个数据库的权限

  • host:存储了某个主机对数据库的操作权限

  • tables_priv:可以对单个表进行权限设置

  • procs_priv:可以对存储过程和存储函数进行权限设置

  • columns_priv:可以对单个列进行权限设置

  • server_cost:CPU的代价模型

  • engine_cost:IO的代价模型

  • event:记录MySQL中的事件

  • func:记录MySQL中的自定义函数

  • general_log:所有的sql执行日志(一般不开启)

  • gtid_executed:二进制日志

  • help_category:关于帮助主题类别的信息

  • help_keyword:与帮助主题相关的关键字信息

  • help_relation:帮助关键字信息和主题信息之间的映射

  • help_topic:帮助主题的详细内容

  • innodb_index_stats: innodb中索引的统计数据

  • innodb_table_stats: innodb中表的统计数据

  • ndb_binlog_index:binlog相关信息

  • plugin:插件相关的表

  • proc:基础信息相关的表

  • proxies_priv:数据库用户权限表

  • servers:节点相关信息

  • slave_master_info、slave_relay_log_info、slave_worker_info:主从相关表

  • slow_log:慢日志记录表

  • tables_priv:表权限表

  • time_zone、time_zone_leap_second、time_zone_name、time_zone_transition、time_zone_transition_type:时间相关表

640?wx_fmt=jpeg

万水千山总是情,点个 “在看” 行不行!!!

640?wx_fmt=png 

<think>嗯,用户问的是MySQL可以有几个。我需要先回忆一下MySQL的主从复制结构。传统的主从复制通常是一个主对应多个从,对吧?那从能不能有多个主呢? 对了,MySQL默认的复制模式是单向的,也就是主到从。这种情况下,一个从只能有一个主。但是用户可能想知道有没有办法让一个从同时从多个主接收数据,或者有没有其他的配置方法。 这时候应该考虑多源复制(Multi-Source Replication)。我记得MySQL在5.7版本之后引入了多源复制,允许一个从同时从多个主复制数据。这样的话,从可以有多个主,每个主对应一个通道,数据会合并到同一个从中。 不过需要注意版本问题,用户可能用的是旧版本,比如5.6或更早,这些版本不支持多源复制,只能单主。另外,多源复制的配置步骤和单主不同,需要为每个主设置独立的通道,可能会有冲突或者数据一致性的问题需要处理。 还要提醒用户,使用多源复制时,应用场景通常是数据聚合或者数据分析,这样多个主的数据汇总到一个从,方便查询。同时,资源消耗可能会更高,毕竟要处理多个数据流,需要足够的硬件资源。 另外,有没有其他方法呢?比如使用中间件或者第三方工具来实现多个主同步到一个从,但原生支持的话还是多源复制更直接。 总结的话,应该分两种情况回答:传统单主模式下一个从只能有一个主;而MySQL 5.7+支持多源复制,允许一个从有多个主,但需要注意配置和资源问题。</think>MySQL配置主的数量取决于复制模式,以下是分步说明: 1. **传统单向复制模式** - 📌 默认情况下,MySQL采用单向主从架构 - ✅ 每个从(Slave)只能配置1个主(Master) - 🔧 通过`CHANGE MASTER TO`语句指定单一主信息 - ⚠️ 此模式适用于5.7以下版本 2. **多源复制模式(MySQL 5.7+)** - 🆕 5.7版本新增多源复制功能 - ✅ 允许单个从同时连接多个主 - 🔧 通过不同复制通道管理多个主: ```sql -- 创建通道1 CHANGE MASTER TO MASTER_HOST='master1_ip' FOR CHANNEL 'channel_1'; -- 创建通道2 CHANGE MASTER TO MASTER_HOST='master2_ip' FOR CHANNEL 'channel_2'; ``` - 📊 典型应用场景: • 多数据中心数据聚合 • 跨业务系统数据整合 3. **注意事项** - 🔄 多主复制需要保证不同主的数据无冲突 - ⚠️ 表结构差异可能导致复制中断 - 📈 需更高的硬件配置(CPU/内存/网络) - 🔍 建议使用`SHOW SLAVE STATUS FOR CHANNEL 'channel_name'`监控各通道状态 4. **替代方案** - 🌐 使用中间件(如MaxScale)实现多主数据路由 - 🧩 通过Tungsten Replicator等第三方工具实现异构数据合并 结论: 原生MySQL最多可连接的主数量=服务器资源上限,但需根据具体版本选择实现方案。建议优先使用多源复制方案,并在测试环境充分验证数据一致性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值