不管是Oracle还是MySQL,新版本推出的新特性,一方面给产品带来功能、性能、用户体验等方面的提升,另一方面也可能会带来一些问题,如代码bug、客户使用方法不正确引发问题等等。
MySQL中数据字典是数据库重要的组成部分之一,INFORMATION_SCHEMA首次引入于MySQL 5.0,作为一种从正在运行的MySQL服务器检索元数据的标准兼容方式。用于存储数据元数据、统计信息、以及有关MySQL server的访问信息(例如:数据库名或表名,字段的数据类型和访问权限等)。
在做自动化运维开发过程中,需要从information_schema.tables获取MySQL表相关的元信息,发现MySQL8.0和5.7存在的差异还是比较大的;在MySQL8.0以前,通常会通过infomation_schema的表来获取一些元数据,例如从tables表中获取表的下一个auto_increment值,从indexes表获取索引的相关信息等。
客户需要做一套库的迁移,因为库的数据量不大,40G左右,并且需要到远程机器上去做全量恢复。所以第一时间想到的自然是 mysqldump 工具来做。但是没想到会发生这种“惨案”。
MySQL优化器的工作之一是选择索引。通过选择索引,找到一个最优的执行方案,以最小的代价去执行语句。而评估代价大小的因素之一,就是扫描行数。因为扫描的行数越少,访问磁盘数据的次数越少,消耗的CPU资源就相应越少。另外,优化器还会结合是否使用临时表、是否排序等因素进行综合判断。
MySQL数据库中进行表空间整理,可以用的一种操作就是optimize table,
网名“北在南方”,资深 DBA,主要负责数据库架构设计和运维平台开发工作,擅长数据库性能调优、故障诊断。
同事咨询个问题:某个业务基于 INFORMATION_SCHEMA 统计表的信息(比如最大值)向表里面插入数据。
在MySQL8.0以前,通常会通过infomation_schema的表来获取一些元数据,例如从tables表中获取表的下一个auto_increment值,从indexes表获取索引的相关信息等。
事务性数据字典与原子DDL,是MySQL 8.0推出的两个非常重要的新特性,之所以将这两个新特性放在一起,是因为两者密切相关,事务性数据字典是前提,原子DDL是一个重要应用场景。
在开发或测试环境在碰到mysql相关故障时,大多数朋友可能会通过论坛发帖,QQ群讨论方式来获取帮助。该方式是获取帮助的有效途径之一。然而如果在生产环境,在没有网络的环境下,这些方式就无助于问题的解决。无论何种数据库,从官方网站获取帮助是最直接最有效的方式。其次没有网络的环境下,我们可以通过MySQL客户端工具自带的帮助信息来解决问题。
该表提供查询关于表级别权限信息,该表中的内容来自mysql.tables_priv
墨墨导读:MySQL8.0 数据字典(Data Dictionary)也在进化中。MyISAM系统表全部换成InnoDB表 ,支持原子DDL。复杂度增加了。考虑过是否跟业务数据库有资源抢夺的现象,这些都是实际使用中需要观察关注的问题。
MySQL 的InnoDB引擎会维护着用户表每个索引的统计信息,来帮助查询优化器选择最优的执行计划,详细的来说,key的分布情况能决定多表join的顺序,也能够决定查询使用哪一个索引。这些统计信息可以由专门的后台线程刷新,也可以由用户也可以显示的调用Analyze table的命令来刷新统计信息,本文基于最新的 MySQL 8.0 来具体分析一下刷新统计信息的具体实现。
当前创建的 数据库 testForTable 字符集和校验集分别为 utf8 和 utf8_general_ci,这是由配置文件中的默认编码集决定的
导读 软件测试人员在工作使用SQL语言中的查询是使用得最多的,而查询也是SQL语言中最复杂的,很多测试人员只使用到其中最简单的查询 1.数据库的使用 现在在任何项目中都有数据的存在,那么在测试过程中查看数据库中的数据是必不可少的步骤,那什么情况下测试人员会查看数据库呢? 比如有一个测试场景是注册新用户,用户在前端页面上添加了一个新用户,点击提交后,弹出提示用户注册成功。 这时预期结果中就应该包含查询数据库: 查询user表中新增一条数据,数据字段的信息与注册信息一致; 查询password表中新增一条数据
MySQL 5.7.11引入了InnoDB表空间加密,该加密启用了对每表文件表空间的支持,此博客中将讨论此功能。
查询目前哪些表有主键,可以通过information_schema.key_column_usage表来确定哪些列使用了主键约束,这个表中包含如下列,每个列的含义如下: CONSTRAINT_CATALOG :约束所属目录的名称。 该值始终为def。 CONSTRAINT_SCHEMA :约束所属schema(database)名称 CONSTRAINT_NAME :约束名称 TABLE_CATALOG :表所属目录的名称。 该值始终为def。 TABLE_SCHEMA :表所属schema(database)名称 TABLE_NAME :具有约束的表的名称 COLUMN_NAME :具有约束的列的名称。 如果约束是外键,则这是外键的列,而不是外键引用的列。 ORDINAL_POSITION :列在约束内的位置,而不是列在表中的位置。列位置从1开始编号。 POSITION_IN_UNIQUE_CONSTRAINT:NULL对于唯一和主键约束。对于外键约束,此列是正在引用的表的键中的序号位置。 REFERENCED_TABLE_SCHEMA :约束引用的schema(数据库)的名称。 REFERENCED_TABLE_NAME :约束引用的表的名称。 REFERENCED_COLUMN_NAME :约束引用的列的名称。 我们来看看这个表中的记录吧:
注意:having是对聚合后的结果进行条件过滤,where是在聚合前就对记录进行过滤
[MySQL学习笔记] 3.mysqldump命令详解 Part 2 -备份全库
MySQL 是一个关系型数据库管理系统,由瑞典 MySQL AB 公司开发,后来目前属于Oracle 公司。MySQL 是一种关联数据库管理系统,关联数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。
information_schema数据库是MySQL自带的,它提供了访问数据库元数据的方式。什么是元数据呢?元数据是关于数据的数据,如数据库名或表名,列的数据类型,或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。 在MySQL中,把 information_schema 看作是一个数据库,确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名,数据库的表,表栏的数据类型与访问权 限等。在INFORMATION_SCHEMA中,有数个只读表。它们实际上是视图,而不是基本表,因此,你将无法看到与之相关的任何文件。 information_schema数据库表说明:
学习了mysql的连接层之后,要来看一下mysql的server层了。这一层聚集了mysql的最多的逻辑,包括了请求解析、查询缓存、语义分析、查询优化、各种计算函数、扫描记录、binlog、缓存、锁、内存管理等等。
MySQL的dd表是用来存放表结构和各种建表信息的,客户端建的表都存在mysql.table和mysql.columns表里,还有一个表mysql.column_type_elements比较特殊,用来存放SET和ENUM类型的字段集合值信息。看一下下面这张表的mysql.columns表和mysql.column_type_elements信息。为了缩短显示长度,这里只展示几个重要的值。
简称DDL(Data Defifinition Language),用来定义数据库对象:数据库,表,列等。关键字:create,alter,drop等。
本篇文章虽大部分内容为参考原文作者的相关内容,但对原文对于文章的逻辑与排版上进行了大范围修改,方便阅读与理解。原文链接在底部
在MySQL中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入。如果某一个表数据量很大,导出dump文件很大的情况下,使用导出导入工具其实会花费不少的时间. 怎么样提高效率呢,可以有一种想法就是直接拷贝数据文件到目标环境,当然在早期版本中这么做是不可取的,因为会有很多关联数据在ibdata中,InnoDB的数据存在对应的数据字典信息,是存放在共享表空间中,无法直接剥离出来,而在5.6/5.7中,就推出了一个很不错
在上一期《数据库对象信息记录表|全方位认识 mysql 系统库》中,我们详细介绍了mysql系统库中的元数据记录表,本期我们将为大家带来系列第四篇《统计信息记录表|全方位认识 mysql 系统库》,下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧。
作用: 记录mysql数据库的一般状态信息及报错信息,是我们对于数据库常规报错处理的常用日志。
这已经是这个系列的第五期了,从PS到SYS,基本上这两个可以获取整体的MYSQL8的性能信息(目前学到的需要整体在8.022版本才有之前介绍的所有的功能,8.018可以有90%的功能)。所以选择MYSQL 从高可用的角度以及监控的角度来看,版本至少应该在8.022以上。
今天看着MySQL的数据字典,突然想到一个问题:为什么MySQL数据字典 information_schema中的表名是大写,而performance_schema和其他库中的是小写? 带着这个问题,我开始了一些猜测和自我论证。 首先大小写的这个情况是相对不兼容的。 比如在performance_schema中,根据关键字user可以找到两个相关的表。 mysql> show tables like 'user%'; +--------------------------------------+ | T
目前MySQL 8.0最新版本为8.0.23版本,针对8.0的新特性,从春节前开始做了一些相关学习和测试,后续会不阶段的分享一些8.0的新特性,供大家一起参考和学习;
不管对于哪种服务,对于其优化,无非是从两个方面着手,第一个是对于硬件方面的优化,第二个是对系统以及服务本身的优化。 1、查询连接MySQL服务器的次数
小编寄语 想必大家都知道,Oracle ACE李真旭(Roger)是国内最专业的Oracle 数据库恢复专家。但知识都是触类旁通,真正的专家,从来不会局限在一个方向上。今天分享的内容,是他在MySQL数据恢复上所做的尝试。 本文主要分享在没有备份的情况下,MySQL数据库如何恢复被删除的表。 包含两个主要的场景: 1、drop table后的恢复 2、truncate table后的恢复 正文: 我们都知道,MySQL Server都很多存储引擎,并不是每种都可以进行异常情况之下都恢复,比如drop ta
有时候,遇到同样的 SQL 语句在正式环境的主库和只读实例的执行时间相距甚远时,第一时间就会想到是不是采样信息不一致,导致执行计划不准,从一个高效的查询变成了慢查询。找到问题所在之后,自然是 analyze 一下,重新采集信息就好,这个时候,却发现 analyze 表上的所有 select 突然卡住了,不返回任何结果。
create database if not exists tlxy default charset=utf8;
注意这里/* !12345 */ 不是注释 (/* */ 是MySQL的多行注释符)
经过分析发现,报错信息中的数据库,所有表名都混用了大小写字母,因为创建表之后,系统变量 lower_case_table_names 的值被从 0 修改为 1,导致删除这个数据库时,每个表的 ibd 文件删除成功,frm 文件删除失败。
Columns 列;Indexes 索引;Views 视图;Events 事件;Fields 字段;
MySQL刷新权限,将某些权限从硬盘刷新到内存中(修改root密码自带隐式刷新权限操作)
比如本人使用的云服务器,其中MySQL预装版本为老版本5.1.x。而最新的mysql版本在性能、功能、安全性等方面都有了很多的改进。 要从最新版本获益,你需要把现有系统升级到5.5+(最新的版本是5.7),我保守一点,升级到5.6.37。
在一次日常测试中发现,kill 一个会话后,SQL语句依然在运行并没终止;被kill的会话重新连接并继续执行原来的SQL语句。
MySQL Replication是MySQL非常重要的特性。用好了,可以发挥很大的作用,做负载均衡,做读写分离,做备份等等,能在关键时刻救DBA一命;用不好,那就是给DBA自己找麻烦了,处理不尽的故障。所以我这边给大家分享两个关于复制的案例。
管理MySQL的命令 以下列出了使用Mysql数据库过程中常用的命令: USE 数据库名 : 选择要操作的Mysql数据库,使用该命令后所有Mysql命令都只针对该数据库。 mysql> use RUNOOB; Database changed SHOW DATABASES: 列出 MySQL 数据库管理系统的数据库列表。 mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ |
一、创建表 1、创建新表 #语法: create table 表名( 字段名1 类型[(宽度) 约束条件], 字段名2 类型[(宽度) 约束条件], 字段名3 类型[(宽度) 约束条件] ); #注意: 1. 在同一张表中,字段名是不能相同 2. 宽度和约束条件可选 3. 字段名和类型是必须的 mysql> create table auth( -> id int(10) primary key auto_increment, -> name varchar(10) not null,
之前做了一个初版的生命周期设计,导致对于实现的难度低估,在实际设计的时候,碰到了一些意料之外的边界问题。
TiDB-DM(Data Migration)是用于将数据从 MySQL/MariaDB 迁移到 TiDB 的工具。该工具既支持以全量备份文件的方式将 MySQL/MariaDB 的数据导入到 TiDB,也支持通过解析执行 MySQL/MariaDB binlog 的方式将数据增量同步到 TiDB。特别地,对于有多个 MySQL/MariaDB 实例的分库分表需要合并后同步到同一个 TiDB 集群的场景,DM 提供了良好的支持。如果你需要从 MySQL/MariaDB 迁移到 TiDB,或者需要将 TiDB 作为 MySQL/MariaDB 的从库,DM 将是一个非常好的选择。
前几篇多多少少学习了一些MySQL相关的知识,例如安装、配置、字符集等,本篇想要介绍下安装好的MySQL有哪些数据库。了解MySQL的内置库对于数据库管理员和开发者来说是非常重要的,它们提供了丰富的功能和工具,有助于更好地管理和优化数据库。
领取专属 10元无门槛券
手把手带您无忧上云