新手 SQL查询语句出错,MYSQL服务器版本: 5.0.45-community-nt-log.这是个论坛发帖的数据库,求大虾指点..

新手 SQL查询语句出错,MYSQL服务器版本: 5.0.45-community-nt-log.这是个论坛发帖的数据库,求大虾指点..,第1张

解决方案如下:

1 进入管理mysql的phpmyadmin

2 在左则选中自己的数据

3 在右则勾选中错误信息中的那个’wxpetdata’表

4 滚动屏幕到下面,有个下拉菜单(With selected:),选择”Repair table”

---------------------------------------------------------------------

或者可以这样

wxpetdata被标记有问题,需要修复。于是赶快恢复历史数据,上网查找原因。最终将问题解决。解决方法如下:

找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:

myisamchk -c -r /data/dedecmsv4/dede_archivesMYI

然后myisamchk 工具会帮助你恢复数据表的索引。重新启动mysql,问题解决。

问题分析:

1、错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种 *** 作都有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

问题的编号为145

2、问题解决办法。

当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复 *** 作遗留下来的。

这三种修复方法如下所示:

% myisamchk --recover --quick /path/to/tblName

% myisamchk --recover /path/to/tblName

% myisamchk --safe-recover /path/to/tblName

第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件

如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧:

如果你怀疑表的索引文件(MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(MYD)和数据格式文件(frm)重新生成它。首先制作一个数据文件(tblNameMYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容:

mysql> DELETE FROM tblName;

在删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblNameMYD)覆盖新的(空)数据文件。最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的格式文件(tblNamefrm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。

3、myisamchk工具介绍(见mysql的官方手册)

可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应MYI和MYD文件的表)。

调用myisamchk的方法:

shell> myisamchk [options] tbl_name

options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk --help得到选项列表。

tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk,你必须指定数据库目录的路径,因为myisamchk不知道你的数据库位于哪儿。实际上,myisamchk不在乎你正在 *** 作的文件是否位于一个数据库目录;你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复 *** 作。

如果你愿意,可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ MYI”后缀)来指定一个表。它允许你通过使用模式“MYI”指定在一个目录所有的表。例如,如果你在数据库目录,可以这样在目录下检查所有的MyISAM表:

shell> myisamchk MYI

如果你不在数据库目录下,可通过指定到目录的路径检查所有在那里的表:

shell> myisamchk /path/to/database_dir/MYI

你甚至可以通过为MySQL数据目录的路径指定一个通配符来检查所有的数据库中的所有表:

shell> myisamchk /path/to/datadir//MYI

推荐的快速检查所有MyISAM表的方式是:

shell> myisamchk --silent --fast /path/to/datadir//MYI

如果你想要检查所有MyISAM表并修复任何破坏的表,可以使用下面的命令:

shell> myisamchk --silent --force --fast --update-state \

-O key_buffer=64M -O sort_buffer=64M \

-O read_buffer=1M -O write_buffer=1M \

/path/to/datadir//MYI

该命令假定你有大于64MB的自由内存。关于用myisamchk分配内存的详细信息,参见5955节,“myisamchk内存使用”。

当你运行myisamchk时,必须确保其它程序不使用表。否则,当你运行myisamchk时,会显示下面的错误消息:

warning: clients are using or haven't closed the table properly

这说明你正尝试检查正被另一个还没有关闭文件或已经终止而没有正确地关闭文件的程序(例如mysqld服务器)更新的表。

如果mysqld正在运行,你必须通过FLUSH TABLES强制清空仍然在内存中的任何表修改。当你运行myisamchk时,必须确保其它程序不使用表。避免该问题的最容易的方法是使用CHECK TABLE而不用myisamchk来检查表。

Shift键删除空白页,首先将光标定位在文档末尾,然后按住「Shift」键不松,鼠标单击选中空白页面,然后按下「Backspace或Delete」键即可删除空白页。

分页符删除空白页有一些空白页,即便是使用了Shift键删除法也无法删除,那么这个时候就要看看是不是插入了分页符,才会导致空白页的。表格删除空白页如果是以表格结束而产生的空白页,这个时候我们可以稍微调整下表格的大小,因为通常这种情况下都是因为表格太大占据了整整一页,使得最后一个回车在第二页无法删除,就形成了空白页。所以我们将表格调整的小一点,再按「Backspace」键就可以删除空白页了。

调整段落行距删除空白页如果还是以表格结尾而产生的空白页,除了利用方法三删除外,你也可以用这个方法来删除。首先将光标定位到空白页处,鼠标右键点击「段落」,将「行距」设为「固定值」,将「设置值」选择「1磅」,点击「确定」按钮也可以删除以表格结束的空白页。

查找替换删除空白页如果一个文档里出现了很多空白页,这个时候我们可以用替换功能来进行批量删除。首先按「Ctrl+H」键直接打开查找替换的窗口,在「特殊格式」中选择「手动分页符」,最后点击「全部替换」,就可以一下子把所有空白页都删除了!注意这个方法只适用于被隐藏的“分页符”导致的空白页,其它原因产生的空白页则不行。

    具体问题具体分析,举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态,而是急剧下降。为什么数据库的性能有非常明显的分界点,原因是什么?

    相信大部分做数据库运维的朋友,都遇到这种情况。 数据库在前一天性能表现的相当稳定,数据库的响应时间也很正常,但就在今天,在业务人员反馈业务流量没有任何上升的情况下,数据库的变得不稳定了,有时候一个最简单的insert *** 作, 需要几十秒,但99%的insert却又可以在几毫秒完成,这又是为什么了?

dba此时心中有无限的疑惑,到底是什么原因呢 磁盘IO性能变差了?还是业务运维人员反馈的流量压根就不对? 还是数据库内部出问题?昨天不是还好好的吗?

 当数据库出现响应时间不稳定的时候,我们在 *** 作系统上会看到磁盘的利用率会比较高,如果观察仔细一点,还可以看到,存在一些读的IO 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的,但只要存在少量的读IO,则性能开始出现抖动,存在大量的读IO时(排除配备非常高速磁盘的机器),对于在线交易的数据库系统来说,大概性能就雪崩了。为什么 *** 作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢?

如果亲之前没有注意到上述的现象,亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前,作者阅读了大量跟的IO相关的代码,如异步IO线程的相关的,innodb_buffer池相关的,以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点,看起来不那么累,因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页,可能存在以下几种情况。

提问 数据页不在buffer bool 里面该怎么办?

  回答:去读文件,将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数,作用是将物理数据页加载到buffer pool, 中显示

buffer_read_page函数栈的顶层是pread64(),调用了 *** 作系统的读函数。

buf_read_page的代码

 如果去读文件,则需要等待物理读IO的完成,如果此时IO没有及时响应,则存在堵塞。这是一个同步读的 *** 作,如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中,无法直接使用该数据页,必须等待 *** 作系统完成IO

再接着上面的回答提问:

当第二会话线程执行sql的时候,也需要去访问相同的数据页,它是等待上面的线程将这个数据页读入到缓存中,还是自己再发起一个读磁盘的然后加载到buffer的请求呢?   代码告诉我们,是前者,等待第一个请求该数据页的线程读入buffer pool。

试想一下,如果第一个请求该数据页的线程因为磁盘IO瓶颈,迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长,则造成等待该数据块的用户线程就越多。对高并发的系统来说,将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read,下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数,我们知道其实通过首先自旋加锁pin的方式,超过设定的自旋次数之后,进入等待,等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题: 如果会话线程A 经过物理IO将数据页1001读入buffer之后,他需要修改这个页,而在会话线程A之后的其他的同样需要访问数据页1001的会话线程,即使在数据页1001被入读buffer pool之后,将仍然处于等待中。因为在数据页上读取或者更新的时候,同样需要上锁,这样才能保证数据页并发读取/更新的一致性。

由此可见,当一个高并发的系统,出现了热点数据页需要从磁盘上加载到buffer pool中时,造成的延迟,是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页,响应时间也就越长,这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题,mysql数据库出现性能下降时,可以看到 *** 作系统有读IO。 原因是,在数据库对数据页的更改,是在内存中的,然后通过检查点线程进行异步写盘,这个异步的写 *** 作是不堵塞执行sql的会话线程的。所以,即使看到 *** 作系统上有大量的写IO,数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时,则会从磁盘上读取,在一个热点数据页不是非常多的情况下,我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页,因此一般都不会出现缺页的情况,也就是在 *** 作系统上基本看不到读的IO。  当出现读的IO时,原因时在执行buf_read_page_low函数,从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降,当出现大量的读IO,数据库的性能会非常差。

sql运行问题?

数据库运行过程中常见的故障有3类:事物故障、系统故障、介质故障。

恢复策略:

1、事物故障:

发生事务故障时,被迫中断的事务可能已对数据库进行丁修改,为了消除该事务对数据库的影响,要利用日志文件中所记载的信息,强行回滚该事务,将数据库恢复到修改前的初始状态。

为此,要检查日志文件中由这些事务所引起的发生变化的记录,取消这些没有完成的事务所做的一切改变,这类恢复 *** 作称为事务撤销。

2、系统故障:

系统故障的恢复要完成两方面的工作,既要撤销所有末完成的事务,还要重做所有已提交的事务,这样才能将数据库真正恢复到一致的状态。

3、介质故障:

介质故障比事务故障和系统故障发生的可能性要小,但这是最严重的一种故障,破坏性很大,磁盘上的物理数据和日志文件可能被破坏,这需要装入发生介质故障前最新的后备数据库副本,然后利用日志文件重做该副本后所运行的所有事务。

“数据故障恢复”和“完整性约束”、“并e799bee5baa6e4b893e5b19e31333431353364发控制”一样,都是数据库数据保护机制中的一种完整性控制。所有的系统都免不了会发生故障,有可能是硬件失灵,有可能是软件系统崩溃,也有可能是其他外界的原因,比如断电等等。

数据库运行的突然中断会使数据库处在一个错误的状态,而且故障排除后没有办法让系统精确地从断点继续执行下去。这就要求DBMS要有一套故障后的数据恢复机构,保证数据库能够回复到一致的、正确地状态去。

简单情况下:进入原来mysql安装路径下的data文件夹下,找到相应的库和ibdata1,进行copy,就可回复原来的数据。

复杂情况下:

从另一台机上把MySQL数据库的mysql文件夹拷贝到本地机上,目的是恢复本地机对数据的访问和 *** 作。经过如下几种情况的 *** 作。

1 在本地重装MySQL(安装目录D:\Program Files\MySQL\MySQL Server 50),直接把mysql文件夹拷贝至D:\Program Files\MySQL\MySQL Server 50\。结果,失败:数据库连接错误。

2 卸载后重装MySQL,将D:\Program Files\MySQL\MySQL Server 50\下的数据备份,只把mysql\data文件夹全部内容拷贝到D:\Program Files\MySQL\MySQL Server 50\data下。结果,失败:数据库连接错误。将备份的数据还完覆盖。结果,失败,还是连接不上数据库。

3 卸载后重装MySQL,将mysql\data文件夹里的cf1,last文件夹(这两个是原来MySQL里的数据库)拷贝进D:\Program Files\MySQL\MySQL Server 50\data。连接成功,在Navicat for MySQL里看到数据库cf1和last,但是不能访问,因为数据全为零。明白了原来data里以数据库命名的文件存储的是数据库的表结构,不是元数据。下一步,把data文件夹里的ibdata1文件(34G大,明显存储了元数据)拷贝到D:\Program Files\MySQL\MySQL Server 50\data里,代替原来的ibdata1文件。重启电脑,打开Navicat for MySQL,连接成功,数据可以访问 *** 作。

至此, *** 作终于成功。其实当初在那台机上把数据导出来,而不是现在直接把文件夹mysql复制过来会更容易恢复。但那台机已经重装了系统,也就是说MySQL失效了。

1、可以的,这也是一个冷备份数据库和迁移数据库的方法,如果别人能复制整个data目录,确实不安全。

2、data下每个目录是一个database,比如mysql目录里面包含的系统表userMYD包含了mysql用户信息

3、不同的存储引擎用的不同的文件存储数据,

a)如果是MyISAM存储引擎的一个table存成了三个文件

tablefrm(表结构)

tableMYD(表数据)

tableMYI(表索引)

这种存储引擎你可以只复制一个table(即三个文件)或者一个数据库(即整个目录)。

b)如果是InnoDB存储引擎用到了表空间文件ibdata1

所以要复制需要包含数据库目录,还要包含表空间文件ibdata1等。

通过数据库网关连接罗克韦尔1756-L72的以太网端口标签方式采集数据,将数据存入MySQL数据库,以下描述具体的 *** 作步骤。PLC数据MQTT多主题发布/订阅西门子PLC数据采集到数据库

网关模块安装在设备侧,不用电脑软件,随设备上电启动自动运行,保证设备数据采集与设备运行同步,简单高效的完成了数据采集;已批量用于多种行业的智能工厂,大大提高MES等工业互联网项目的实施效率。IGT-DSER带有两种数据缓存功能:

1 高频次采集数据缓存,打包后一次性上报到数据库;

2 断网、服务器维护上报异常时,将数据缓存,待故障解除后重新上报到数据库

网关支持西门子、三菱、欧姆龙、施耐德等几乎所有的PLC品牌,通过以上参数软件自行切换即可;关于网关模块的详细介绍可查看CSDN的这篇文章,或者到这里下载PDF手册。以下是详细的 *** 作步骤:

首先用Navicat连接服务器数据库,建立一个数据表,名称为'abplcdata',数据表设计视图如下:

然后在PC上运行网关的参数设置软件,网线连接IGT-DSER网关的网口1,先配置网络参数(默认IP:1921681244,确认PC的网口与网关默认IP同网段),通过‘工具’->‘搜索在线网关’,搜索到网关后,修改IP地址等参数,具体如下:

网口1PLC设备末段IP设置为0表示有多台同系列同网段的PLC,每台PLC的IP地址在PLC数据地址表里面配置,后面有描述;设置完成后通过‘参数’->‘参数写入到网关’,下载参数,会有以下提示:

点‘是(Y)’即可,参数下载成功后将网关断电,网口1接入PLC的交换机网络,同时修改PC的网口参数为PLC同网段,重新搜索网关读取参数后,通过‘功能’->‘数据上报与下载’进入数据服务配置页面,选择SQL远程数据库,配置数据库地址、PLC标签的参数;

配置完成后要下载参数,通过‘工具’->‘重启网关’,重启后,网关即进入工作状态,通过读取参数可查看网关的实际数据,双击配置表对应的数据序号可查看数据值,如下图:

序号001是日期时间,取自网关的RTC时钟;002和003是PLC的控制器二维数组;004、005和006是控制器一维数组;007为程序变量,字符串类型;008是程序数组;009是控制器变量,BOOL类型;

设备/站号栏目的数值9,表示PLC的IP地址(19216809)末段(前三段与网关的网口1相同),如果需要增加另外的同系列同网段PLC,在这里设置对应的IP末段地址即可,不同的PLC对应不同的数据表,或者不同的记录行;

需要注意配置表‘数据地址’栏是PLC的数据标签,不能错误,否则读不到数据,所以最好是通过PLC的编程软件从PLC导出CSV文件,然后复制到配置表,如下图:

再打开Navicat查看数据库中的数据,如下图:

这样就完成了数据采集,没间隔5秒网关会自动上报一次数据,这个周期可以调整,也可以设置成触发模式,根据数据变化上报数据;

相关资源:利用PLC实现数据采集_plc数据采集并存入数据库,plc数据采集-专业

————————————————

版权声明:本文为CSDN博主「肉褚」的原创文章,遵循CC 40 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:>

以上就是关于新手 SQL查询语句出错,MYSQL服务器版本: 5.0.45-community-nt-log.这是个论坛发帖的数据库,求大虾指点..全部的内容,包括:新手 SQL查询语句出错,MYSQL服务器版本: 5.0.45-community-nt-log.这是个论坛发帖的数据库,求大虾指点..、mysql数据库运行过程中可能发生的故障包括、如何判断MSSQL数据库磁盘出现了瓶颈等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/sjk/9420300.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-28
下一篇 2023-04-28

发表评论

登录后才能评论

评论列表(0条)

保存