经过分析发现,报错信息中的数据库,所有表名都混用了大小写字母,因为创建表之后,系统变量 lower_case_table_names 的值被从 0 修改为 1,导致删除这个数据库时,每个表的 ibd 文件删除成功,frm 文件删除失败。
巡检时发现服务器磁盘空间不足,通过查看大文件进行筛选是发现有几个#sql开头的文件,且存在超过100G及10G以上的文件。
安装环境: 操作系统版本:RHEL 6.5 安装版本:MYSQL 5.1 升级版本:MYSQL 5.6 一、默认库介绍 安装完成之后,mysql会自动创建以下三个默认的库. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | +-
mysql> alter table skatetab add unique index(id, uid), drop primary key, add primary key(uid, id);
海外有一台服务器受到攻击,上面有自建的mysql数据库,要把数据库备份下来,要到地址账号密码登录上去看了一下mysql版本是5.1的
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文目的:指导项目侧人员再遇到此类改动需求时可以自己更改。 需求:mr_intrainterfreq表重建,历史数据全部删掉。
作者:matrix 被围观: 1,412 次 发布时间:2020-08-31 分类:Python 零零星星 | 无评论 »
对于Online DDL,之前简单分析了一些场景MySQL中的Online DDL(第一篇)(r11笔记第3天),其实有一个很关键的点没提到,那就是online DDL的算法,目前有三个操作选项,default,inplace,copy可选 具体可以参考 https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html > select count(*) from newtest; +----------+ | count(*) | +-----
本公司开发使用的开发语言是 PHP Laravel 框架,通过 php artisan migrate 进行操作,导致数据库异常,随后再执行这个SQL语句一直报错,报错提示如下:
本公司开发使用的开发语言是PHP Laravel框架,通过 php artisan migrate 进行操作,导致数据库异常,随后再执行这个SQL语句一直报错,报错提示如下:
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/53908035
背景 MySQL 8.0 DDL 是一个复杂的过程,涉及比较多的模块,例如:MDL 锁,表定义缓存,行格式,Row Log,DDL Log,online 属性,表空间物理文件操作等。本文主要通过与5.
mysql-utilities是mysql的一个工具集合,它是基于----- python2 --- 实现的,从官网查看到最新版本为mysql-utilities-1.6.5.tar.gz
写这篇文章我是非常不情愿的,我现在是在写这篇文章,但是同时我也在恢复我服务器数据库的数据,出这篇文章也是在我的意料之外,由于我正在这件事类,我就出一版这样的mysql.frm.ibd文件数据恢复教程,希望这次教程可以帮助到更多需要恢复的人,我现在是情绪暴涨。
text类型的字段通常用来保存比较大的一些文本对象,除了text,blob类型也经常被使用,这两种类型之间的差别主要是blob能够保存二进制数据,例如图片信息等,而text只能保存字符数据,但是这两种数据类型都会存在一些性能问题,也就常说的表空间碎片,或者称之为表空间空洞,从而影响插入表的性能。解决这种性能问题通常可以采用optimeize table来对这类碎片表进行优化。这里我们还是通过例子来看这个问题:
客户需要做一套库的迁移,因为库的数据量不大,40G左右,并且需要到远程机器上去做全量恢复。所以第一时间想到的自然是 mysqldump 工具来做。但是没想到会发生这种“惨案”。
使用delete删除数据 , 是我们常用的用法 , 但是这样并没有真正的把数据删除掉 , mysql只是标志了一下删除
具体报错如下: Table '.\tablename' is marked as crashed and should be repaired 提示说论坛的帖子表posts被标记有问题,需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下: 找到mysql的安装目录的bin/myisamchk工具,在命令行中输入: myisamchk -c -r ../data/tablename/table.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql,问题就解决了。 问题分析: 1、 错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 2、问题解决办法。 当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示: % myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName 第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。 检查和修复MySQL数据文件 如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧: 如 果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生 成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容: mysql> DELETE FROM tblName; 在 删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。 最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。 如果你的表的 格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一 起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。 启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。
具体报错如下: Table '.\Tablename\posts' is marked as crashed and should be repaired 提示说论坛的帖子表posts被标记有问题,需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下: 找到mysql的安装目录的bin/myisamchk工具,在命令行中输入: myisamchk -c -r ../data/tablename/posts.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql,问题就解决了。 问题分析: 1、 错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 2、问题解决办法。 当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示: % myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName 第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。 检查和修复MySQL数据文件 如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧: 如 果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生 成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容: mysql> DELETE FROM tblName; 在 删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。 最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。 如果你的表的 格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一 起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。 启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。
这个时候所有的mysql的相关进程都会停止,直到drop结束,mysql才会恢复执行。出现这个情况的原因就是因为,在drop table的时候,innodb维护了一个全局锁,drop完毕锁就释放了。
在MySQL中,如果我们使用了默认的存储引擎innodb创建一张表,那么在文件夹下面就会出现表名.frm和表名.ibd两个文件,如果我们使用的是Myisam存储引擎,那么就会出现三个文件,这里我们给出例子:
在测试环境下没有设置过多的详细参数就初始化并启动了服务,后期优化的过程中发现innodb_data_file_path设置过小:
MySQL中的alter table操作对于大表来讲,是一个比较严重的问题,MySQL执行大部分alter table的操作步骤是:
MySQL 8.0 开始支持原⼦ DDL(atomic DDL),数据字典的更新,存储引擎操作,写⼆进制日志结合成了一个事务。在没有原⼦DDL之前,DROP TABLE test1,test2;如遇到server crash,可能会有test1被drop了,test2没有被drop掉。下面来看下在MySQL 8.0之前和MySQL 8.0 数据字典的区别。
分区表是数据库中一种用于优化大型表数据管理和查询性能的技术。它将一个表的数据根据特定的规则或条件分割成多个部分,每个部分称为一个分区。每个分区可以独立于其他分区进行存储、管理和查询,这样可以提高数据处理的效率,尤其是在处理大量数据时。
前几天因为mysql数据库部分数据损坏原因,我尝试了下恢复数据,之后整理以下文档,供各位参考,
查询语句:SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length + data_free) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema;
CSV存储引擎可以将CSV文件作为mysql表来处理,存储格式就是普通的CSV文件。如果把数据存储在myisam和Innodb中,存储数据的文件是不能直接查看的,因为这两种存储引擎都是以二进制文件存储的。而CSV是以文本方式存储的,CSV是不支持索引的,查找的时候要进行全表扫描。
SQL标准在数据存储的物理方面没有提供太多的指南。SQL语言的使用独立于它所使用的任何数据结构或图表、表、行或列下的介质。但是,大部分高级数据库管理系统已经开发了一些根据文件系统、硬件或者这两者来确定将要用于存储特定数据块物理位置的方法。在MySQL中,InnoDB存储引擎长期支持表空间的概念,并且MySQL服务器甚至在分区引入之前,就能配置为存储不同的数据库使用不同的物理路径(关于如何配置的解释,请参见7.6.1节,“使用符号链接”)。
数据库中的表也应该有不同的类型,表的类型不同,会对应mysql不同的存取机制,表类型又称为存储引擎
执行 DROP DATABASE 会删除数据库里的所有表然后再删除数据库,所以执行这条语句的时候一定要慎重。要执行该语句,你需要拥有数据库的 DROP 权限。DROP SCHEMA 和 DROP DATABASE 可以互相替换。
最近某套MySQL因为磁盘挂载问题,异常宕机,拉起后,数据库能正常访问了,但是在error.log一直提示这个错误,
MySQL提供了插件式的存储引擎架构。所以MySQL存在多种存储引擎,可以根据需要使用相应的引擎。MySQL支持的存储引擎有很多,常用的是:InnoDB,MyISAM。MEMORY,MERGE作为了解,其中InnoDB提供事务安全,其他存储引擎是非事务安全表。
基本操作 启动MySQL:net start mysql 创建Windows服务:sc create mysql binPath = mysqld_bin_path 连接服务器 :mysql -h 地址 -P 端口 -u 用户名 -p 密码 显示哪些线程正在运行:SHOW PROCESSLIST 显示系统变量信息:SHOW VARIABLES 数据库操作 查看当前数据库:SELECT DATABASE(); 显示当前时间、用户名、数据库版本:SELECT now(); SELECT user()
五一假期过去一半了,不知道小伙伴们过的如何,相信很多小伙伴都出去玩了吧?我是在家研究了两天Seata源码。
MySQL是我们经常使用的数据库处理系统(DBMS),不知小伙伴们有没有注意过其中的“存储引擎”(storage_engine)呢?有时候面试题中也会问道MySQL几种常用的存储引擎的区别。这次就简短侃一下存储引擎那些事儿。
在 5.1 版本之前,MyISAM 是 MySQL 的默认存储引擎,MyISAM 并发性比较差,使用的场景比较少,主要特点是
同事反馈说某个测试的MySQL数据库误删除了ibdata1文件,导致库启动不了,而且没做备份,能不能恢复?
>- ENUM和CHAR(VARCHAR)类型关联查询,会慢一些,因此,假如预先知道某列需要与CHAR类型关联,那么就不应该将该列设置为ENUM类型 >- ENUM类型的列可有效缩小表所占的空间,书中写可缩小1/3
语法 innobackupex --user=DBUSER --password=DBUSERPASS /path/to/backup/dir/ innobackupex --user=DBUSER --password=DBUSERPASS --backup --target-dir=/path/to/BACKUP-DIR/
当别人问我Mysql的存储引擎的时候,我就知道Myisam和innodb 虽然知道有其他的存储引擎,但是从来没有去了解过今天了解一下扩充知识 查看Mysql的存储引擎 show engines; My
记得有一天快下班的时候,一位开发同事找到我说,需要对一个表做变更,数据量据说有上千万,而当时是使用的MySQL版本是5.5,这可如何是好,对于在线业务要求高的情况下,这种需求真是让人头疼。 而在早期的版本中,这种问题就更让人无语了。在Oracle中这个问题解决的较早,当然在很多技术实现细节上,Oracle和MySQL还是蛮大的差距。Oracle中有在线重定义的方案物化视图prebuilt和在线重定义 (r10笔记第25天),而且本身对于一些DDL的操作代价要比MySQL低。不过在碰到添加字段且加默认值的情况
2用户名密码验证(通过授权表做的验证数据库一启动,会把授权表加载到内存中 mysql.user mysql.db mysql.table_priv mysql.column_priv)
当数据库跑了较长时间后,存储的数据将越来越多,这时候往往也意味着,一旦数据库服务器出现宕机等相关状况,将给我们的业务带来巨大的影响,甚至可能是具备一定的毁灭性的,因此,即使对数据库进行备份是极其重要的。接下来,我们一起来学习全量备份的实现方式。
硬盘空间满导致mysql ibd文件被删后提示Tablespace is missing for table ‘db_rsk/XXX“ 昨天一早,开发人员反馈说一个测试环境报Tablespace is missing for table ‘db_rsk/XXX“,周末刚升级过,特地让开发回去查了下,说脚本中肯定没有drop table的操作。datadir下检查了下,发现frm文件在的ibd文件没有了,bing了下,没发现类似异常。于是先回到mysql.err往回搜索,半天后发现上周五下午mysql出现了一
MySQL里面对于表的默认的配置是每个表都有独立的文件.ibd和.frm文件对应,对于数据恢复来说,会提供很大的便利。
圈出来那一行,yes就是有,no就是没有,default就是系统默认的,一般是开着的,disabled就是有,但是被关了。
MySQL有9种存储引擎,不同的引擎,适合不同的场景,我们最常用的,可能就是InnoDB,应该是从5.5开始,就成为了MySQL的默认存储引擎。
使用MEMORY存储引擎的表,其数据存储在内存中,且行的长度固定,这两个特点使得MEMORY存储引擎非常快。
领取专属 10元无门槛券
手把手带您无忧上云