mysql错误:Can’t find file: ‘tbl_name’ (errno: 2)

配置好mutt收发邮件之后,才发现cron每天执行的时候,如果执行中有错误提示或者输出,虽然用户看不见,但他会发一封本地邮件给管理员,在mutt中能够收到。比如,我就收到了这么一封邮件:

From: Cron Daemon <root> To: fwolf Subject: Cron <fwolf@fwolf> backup_mysql > /tmp/backup_mysql.log X-Cron-Env: <PATH=/bin:/sbin:/usr/bin:/usr/sbin:~/bin> X-Cron-Env: <HOME=/home/fwolf> X-Cron-Env: <SHELL=/bin/bash> X-Cron-Env: <LOGNAME=fwolf> mysqldump: Got error: 1017: Can’t find file: ‘ads’ (errno: 2) when using LOCK TABLES

我也是这样才发现每天备份数据库的时候都有错误了,表ads的数据根本就没有备份出来,再衍生查询一下,好几个表都这样,恐怖啊,幸亏及时发现,看来费这么大的力气来搞mutt还是有点用处的。

再来看这个错误,“Can’t find file: ‘tbl_name’ (errno: 2)”这个错误产生的原因在mysql手册中有解释,存储数据表的文件名是有大小写的,大小写错误了就会“找不到”,即使是在不去分文件名大小写的操作系统(比如windows)下,查询中引用的表名也应保持大小写的一致性。

而我产生这个错误的表,原来是在windows服务器下使用的,现在转到linux服务器下了,并且在很长的时间里都没有访问,只是一直舍不得扔掉,每次备份的时候都带着。以前这些数据表都保存在fat32分区中,上次倒腾硬盘的时候,都转换成了ext3分区。再查看一下文件名,果然存在文件名大小写的问题。

一般采用分散文件方式保存的mysql数据表(MyIsam默认,InnoDb也可以通过选项innodb_file_per_table设置),每个表一般有三个文件,扩展名分别是.frm .MYD .MYI,注意大小写!我那些提示出错的表,扩展名三个都是小写的!于是把扩展名MYD MYI都改成大写,问题解决!

至于这些表名为什么成了小写,应该是原来在fat32分区上,windows服务器的时候造成的,因为一般windows下文件的扩展名都是小写的。

mysql默认禁止非本机访问

由于DBDesigner不好用,mysql的workbench还在beta,看了一眼也只是“初级阶段”,又换回了windows下的powerdesigner,好在我有两台电脑。

但是,默认却无法从windows主机连接到ubuntu下的mysql,错误:

Can’t connect to MySQL server on ‘192.168.10.18′ (10061)

原来,mysql的默认配置为了增强安全性,禁止了非本机的访问,在ubuntu中是这样,debian中也是。禁止的方式以前是在my.cnf中有一句

skip-network

现在则变成了:

# Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address = 127.0.0.1

就是只监听本机地址。所以,如果要开放局域网内的访问,需要注释掉这一句,或者改成:

bind-address = 0.0.0.0

另外,netstat -ant命令用来查看本机当前监听端口真的不错。

mysql 4.1 数据转换指南

mysql 4.1增加了编码的支持,所以在转换旧数据的时候稍微麻烦一些,但只要注意以下几点,基本没问题的:

1、转换之前一定要先把原有数据dump出来,一般原有数据都是gb2312编码吧,dump命令如下:

mysqldump -u -p database –add-drop-table –extended-insert

–add-drop-table是为了导入的时候省去建表环节,–extended-insert是为了防止在导入的时候一个sql语句过大的情况,想想你的上千条记录写在一条sql语句中是多么的恐怖。

这里假定原有数据库是gb2312编码,需要转换为utf8编码,其它编码之间的转换类似。

2、修改dump出来的sql文件,用Emeditor或iconv把文件的编码转换为utf-8,注意最好不要那个什么“Unicode Signature(BOM)”,因为mysql.exe不认的。再把文件中的gbk_bin替换为utf8_general_ci,把gbk替换为utf8,然后在文件最前面加上

set names utf8;

带上BOM,mysql不识别的错误大体如下:

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the ma nual that corresponds to your MySQL server version for the right syntax to use n ear ‘ï»? /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */’ at line 1

3、重新建mysql库,然后导入备份的sql语句,导入命令如下:

mysql -u -p database < dumpdata.sql

4、如果是以前导出的文件,导入的时候遇到错误:

Got a packet bigger than ‘max_allowed_packet’ bytes or ERROR 1153 (08S01) at line 616: Got a packet bigger than ‘max_allowed_packet’ by tes

就需要修改mysql的最大允许包大小了,编辑my.ini,在[mysqld]部分(不在这部分没用)添加一句:

set-variable=max_allowed_packet=10485760

重启mysql服务就可以了,我这里设置的是大约10M。

到这里数据导入基本就完成了,接下来就是根据各个应用的不同来调整了,一般有的系统已经支持了,但还有的不支持,不过调整方法大概分以下几类:

1、在数据库连接后面加上

mysql_connect(…. mysql_query(“set names ‘utf8′”);

这种情况最多,比如Brim什么的。

2、将语言文件或模板文件的编码设置为utf-8,注意是直接把文件编码转换了就可以,内容不用管,这样的有phpwind, mantis。使用工具可以是iconv,在这里可以下载。

iconv -f gb2312 -t utf-8 gb2312.html > utf-8.html

3、修改模板文件,设置HTML中的

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />

原先是gb2312编码的系统多半需要改这个。

gbk,utf8,左右为难

看《O’Reilly Upgrading to PHP 5》的时候,心血来潮,把MYSQL升级到了4.1.11,由于机器上没有什么正式系统,也就没有注意到它字符集的变化。后来就把正式应用的系统也给升级了,升级之后其它系统都没问题,唯独一个MANTIS有了麻烦,打开页面都成了乱码,幸亏有备份可以恢复,在恢复的过程中就发现了MYSQL升级带来的字符集的问题--如果MYSQL用UTF8字符集,MANTIS数据导入之后,页面显示乱码,无奈只得把MYSQL调为GBK字符集。

其实我还是愿意使用UTF8字符集的,因为没有不兼容的麻烦,作为长久保留的数据,日后转换、整理起来比较省事;在与外部进行数据交换的时候,也不存在编码转换的问题。可是我始终不明白,在使用PHP连接MYSQL接收用户输入数据,并存入数据库的时候,如果数据库编码是UTF8,是否要把SQL数据也转换为UTF8?抽空弄个小程序试试,如果真是这样那可就麻烦大了,不过我在DOS下用命令行操作UTF8字符集的MYSQL服务器是没法输入汉字的。

以前使用SYBASE的时候曾经被字符集的问题困扰了很久,因为SYBASE如果字符集用错了,某些汉字根本就无法输入,比如大写的零“○”,所以字符集从iso_1换到cp850,又从cp850换到cp936,中间舍弃了很多历史数据,MYSQL千万不要让我重蹈覆辙。

see also:
UTF-8还是GB2312称雄blog