数据库(MySql)
Sep 4
解决 mysql ERROR 1017:Can't find file: '/xxx.frm' 错误0013
出现这个问题的原因不是'/xxx.frm'这个文件不见了,而是这些文件的权限(应该要是mysql)不知道为什么变成了root。
解决方法:cd到xxx.frm文件所在目录下,执行一下命令:chown mysql mysql * 将所有文件的权限都改过来就可以了!
MySql的MyiSAM表很有可能会出现
Tags:
Sep 9
网站迁移,因为数据库是MYISAM .为了方便。直接把数据库文件 打包后复制到新的服务器.
在添加了数据库用户和授权后,网站访问报错。
mysql 管理员用户登录后 今日业务数据库 也是报错。
MariaDB [mysql]> use itlife365_mydb
Database changed
MariaDB [itlife365_mydb]> show tables;

MariaDB [itlife365_mydb]> 
ERROR 1018 (HY000): Can't read dir of './itlife365_mydb/' (errno: 13)


百度一下,原来是复制的时候,权限没有授权给mysql导致无法访问。
处理如下:
To fix this problem you need to set correct permission on /var/lib/mysql/dbname/ directory. Use the command as follows:
[root@server1.itlife365 mysql]# ll /var/lib/mysql/itlife365_mydb
total 152
-rw-rw---- 1 root  root    61 Sep  2 11:53 db.opt
-rw-rw---- 1 root  root  9072 Sep  2 11:59 ic_admin.frm
-rw-rw---- 1 root  root  8606 Sep  2 11:59 ic_admintype.frm

[root@server1.itlife365 mysql]#chown mysql:mysql itlife365_mydb/ -R
[root@server1.itlife365 mysql]# ll /var/lib/mysql/itlife365_mydb
total 152
-rw-rw---- 1 mysql mysql    61 Sep  2 11:53 db.opt
-rw-rw---- 1 mysql mysql  9072 Sep  2 11:59 ic_admin.frm
-rw-rw---- 1 mysql mysql  8606 Sep  2 11:59 ic_admintype.frm
重新访问即可
Tags: ,
Jun 19

ispconfig3 新增的数据库使用phpMyAdmin登录报#1045 无法登录 MySQL 服务器的处理即如何修改mysql用户密码
 新增了数据库和用户密码后,而且开启了可以远程访问的权限后,还是无法通过phpmyadmin 访问新增的库报1045.
 我的处理方式是通过登录mysql服务器后台修改密码
处理密码的几种方式登记如下:

方法一:
(适用于管理员或者有全局权限的用户重设其它用户的密码)
进入命令行模式
mysql -uroot -p
mysql>use mysql;
mysql> UPDATE user SET password=PASSWORD("new password") WHERE user='username';
mysql> FLUSH PRIVILEGES;
mysql> quit;
 
方法二:
mysql -u root -p
mysql>use mysql;
mysql> SET PASSWORD FOR   username=PASSWORD('new password');
mysql> QUIT
 
方法三:
 mysqladmin -u root "old password" "new password"
注:new password请输入你想要设置的密码。

--phpmyadmin-1045-by-modify-user-password

Tags: ,
Feb 15

Mysql Incorrect key file for table '/tmp/....' try to repair it错误的发现和简单的解决方法(网络收藏)
我在window 查询的时候碰到了错误如下:
insert into jdj_keyword_pc(name)
SELECT t1.name FROM `ic_keywordcollectna801` t1
WHERE NOT EXISTS ( SELECT 1
FROM jdj_keyword_pc t2
WHERE t2.name = t1.name
);


MySQL 返回:

#126 - Incorrect key file for table 'C:\Windows\TEMP\#sql_81c_0.MYI'; try to repair it
查看如下问题解决:
mysql> show variables like 'tmpdir';
默认是在C:\WINDOWS\TEMP
在文件:
D:\mysoft\APMServ5.2.6\MySQL5.1\my.ini 添加
tmpdir=D:\downloadTemp\mysqlquerytemp 后重启MYSQL数据库后得到解决。
因为我的是windows ,c 盘剩下3G,D盘还有31G, 修改目录后临时文件得到解决。

以下为网络参考


欢迎转载,请注明作者、出处。

作者:张正

    突然接到开发打来电话说MySQL数据库执行SQL报错,让排查一下原因。
登陆MySQL服务器看了一眼错误日志:

        140904 12:06:20 [ERROR] /usr/local/mysql5.5/bin/mysqld: Incorrect key file for table '/tmp/#sql_5608_1.MYI'; try to repair it
        140904 12:06:20 [ERROR] Got an error from unknown thread, /tmp/mysql5.5_install/tmp/mysql-5.5.30/storage/myisam/mi_write.c:223


看到/tmp下的问题,先看一眼tmpdir:
mysql> show variables like 'tmpdir';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| tmpdir        | /tmp  |
+---------------+-------+
1 row in set (0.00 sec)

      说/tmp下有表需要修复,通过tmpdir可知,是临时排序表所致。在网上查了一下,说产生这个问题是由于tmpdir目录下空间不足。
查看一下磁盘空间:
[root@localhost data]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   15G   31G  33% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data
/tmp属于/ 根目录下,空间还有31G,觉得不可能。

     查看慢日志,找到一条很可疑的语句,拿50万的数据来排序,还有的语句拿200多万的数据来排序,而且从时间上也与开发说的时间很吻合:
# Time: 140904 16:13:50
# User@Host: staff_reader[staff_reader] @  [10.35.15.68]
# Query_time: 133.653564  Lock_time: 0.000186 Rows_sent: 5384178  Rows_examined: 20886933
use hotel_inventory;
SET timestamp=1409818430;
SELECT col1,col2,col3....,col7
  FROM  table1 nolock WHERE
 available_time >= '2014-09-03' AND available_time <=  DATE_ADD('2014-09-03', interval 91 day)
 order by hotel_id,room_type_id,available_time;

看一下该语句访问的表的具体情况:
表行数为20886994:
mysql> select count(*) from table1;
+----------+
| count(*) |
+----------+
| 20886994 |
+----------+
表大小为7G: 
 [root@localhost]# du -sch *|grep sum_inv_room.ibd
6.9G    sum_inv_room.ibd
该机器上有4个实例:
[root@192.168.97.149 hotel_inventory]# ps -ef|grep mysqld_safe
root     21185     1  0  2013 ?        00:00:00 /bin/sh /usr/local/mysql5.5/bin/mysqld_safe --defaults-file=/data/mysql6025/etc/my6025.cnf
root     22525     1  0  2013 ?        00:00:00 /bin/sh /usr/local/mysql5.5/bin/mysqld_safe --defaults-file=/data/mysql6027/etc/my6027.cnf
root     24275     1  0  2013 ?        00:00:00 /bin/sh /usr/local/mysql5.5/bin/mysqld_safe --defaults-file=/data/mysql6024/etc/my6024.cnf
root     37864     1  0  2013 ?        00:00:00 /bin/sh /usr/local/mysql5.5/bin/mysqld_safe --defaults-file=/data/mysql6026/etc/my6026.cnf
root     60463  5879  0 16:18 pts/6    00:00:00 grep mysqld_safe

总大小有30G左右,都是同时抽取数据:
[root@192.168.97.149 hotel_inventory]# du -sch /data/mysql602*/data/hotel_inventory/* |grep sum_inv_room.ibd
6.9G    /data/mysql6024/data/hotel_inventory/sum_inv_room.ibd
7.1G    /data/mysql6025/data/hotel_inventory/sum_inv_room.ibd
7.9G    /data/mysql6026/data/hotel_inventory/sum_inv_room.ibd
6.5G    /data/mysql6027/data/hotel_inventory/sum_inv_room.ibd
    既然看到这些现象,那么我肯定就是这条语句同时执行所致。这时候给开发反馈,而开发说[staff_reader] @  [10.35.15.68] 这个用户不是他们那边的。没办法了,继续找。我就手动那上面那条语句去执行,发现根本没产生多少临时文件。这时候可以断定不是这个语句造成的了。
所以这个时候只能等问题再次重现。看了一下磁盘空间,正常情况下,/ 根目录可用空间是31G,然后我就写了个脚本一直监测可用空间是否是31G,如果不是,就给我QQ邮箱发邮件。
过了一会,果然收到邮件了,这时候上服务器看磁盘空间,在持续增长:
查看磁盘空间情况:
[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   30G   17G  65% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data
[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   33G   14G  71% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data

[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   35G   11G  77% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data

[root@192.168.97.149 tmp]# du -sch *
88K     mha4mysql-node-0.53
2.1G    #sql_5608_0.MYD
4.0K    #sql_5608_0.MYI
3.6G    #sql_5608_1.MYD
4.0K    #sql_5608_1.MYI
1.9G    #sql_5b44_0.MYD
4.0K    #sql_5b44_0.MYI
4.9G    #sql_5b44_1.MYD
4.0K    #sql_5b44_1.MYI
2.0G    #sql_621a_0.MYD
4.0K    #sql_621a_0.MYI
749M    #sql_621a_1.MYD
4.0K    #sql_621a_1.MYI
2.2G    #sql_9753_0.MYD
4.0K    #sql_9753_0.MYI
4.2G    #sql_9753_1.MYD
4.0K    #sql_9753_1.MYI
22G     total

[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   37G  9.5G  80% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data

[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   41G  5.2G  89% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data
[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   46G   29M 100% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data
[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   46G   22M 100% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data

[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   46G     0 100% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data
空间满的同时,看到/data/mysql6025/log/mysqld.err中又出现错误:
140904 16:03:59 [ERROR] /usr/local/mysql5.5/bin/mysqld: Incorrect key file for table '/tmp/#sql_5608_1.MYI'; try to repair it
140904 16:03:59 [ERROR] Got an error from unknown thread, /tmp/mysql5.5_install/tmp/mysql-5.5.30/storage/myisam/mi_write.c:223

通过慢日志来看,又出现了上面那条很可疑的语句。可是之前已经排除了其的可能性,那就只能继续找,发现一条很简短的语句,看起来没什么,但是执行时间很长:
SELECT MIN(sum_inv_room_id), MAX(sum_inv_room_id) FROM (select s.*, 20140909 as dw_insert_dt_wid from sum_inv_room s WHERE  (1 = 1) ) AS t1;

出错的这段时间,基本上就这两条SQL在跑。
报错之后,磁盘空间逐渐恢复:
........................................................
[root@192.168.97.149 tmp]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   38G  8.6G  82% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data

[root@192.168.97.149 log]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              49G   15G   31G  33% /
tmpfs                  32G     0   32G   0% /dev/shm
/dev/sda1             985M   44M  891M   5% /boot
/dev/sda4             219G  6.5G  201G   4% /opt
/dev/sdb1             1.4T  176G  1.2T  14% /data


最后空间使用率恢复正常

于是手动拿这个语句执行了一下:
SELECT MIN(col1), MAX(col1) FROM (select s.*, 20140909 as dw_insert_dt_wid from table1 s WHERE  (1 = 1) ) AS t1;
果然看到磁盘空间立马飙升,找到原因所在。单条语句执行,看到其产生的临时文件最大到了10多G。一共31G的空间,4个实例,都产生10多G,当然扛不住。
(至于具体为什么这样的语句会产生这么大的临时文件,本人对其中的原理不是太理解,先做此记录。)
经过与开发沟通,开发说那个是定时抽取数据。而且机器上的4个实例是同时开始的。
所以给出以下解决办法:
1.将MySQL中参数tmpdir设置到大的目录下去,但是这个需要参数是read_only变量,需要重启数据库
2.将这4个语句串行执行
3.修改抽取数据的SQL
最后开发选择了第2种方法,将定点抽取数据的SQL串行执行,问题暂时得到解决,至少半个多月都没再出现这个问题了。

mysql-Incorrect-key-file-for-table-try-to-repair-it

Tags: ,
Mar 9
--begin by itlife365
现在比较少使用mysql了,突然要查通过日期过滤今天生成的数据,居然忘了
select * from student where age=***;
百度如下MySQL DATE_FORMAT() 函数用法如下:
MySQL DATE_FORMAT()定义和用法
DATE_FORMAT() 函数用于以不同的格式显示日期/时间数据。

语法  DATE_FORMAT(date,format)
date 参数是合法的日期。format 规定日期/时间的输出格式。
可以使用的格式如下表格

格式描述
%a缩写星期名
%b缩写月名
%c月,数值
%D带有英文前缀的月中的天
%d月的天,数值(00-31)
%e月的天,数值(0-31)
%f微秒
%H小时 (00-23)
%h小时 (01-12)
%I小时 (01-12)
%i分钟,数值(00-59)
%j年的天 (001-366)
%k小时 (0-23)
%l小时 (1-12)
%M月名
%m月,数值(00-12)
%pAM 或 PM
%r时间,12-小时(hh:mm:ss AM 或 PM)
%S秒(00-59)
%s秒(00-59)
%T时间, 24-小时 (hh:mm:ss)
%U周 (00-53) 星期日是一周的第一天
%u周 (00-53) 星期一是一周的第一天
%V周 (01-53) 星期日是一周的第一天,与 %X 使用
%v周 (01-53) 星期一是一周的第一天,与 %x 使用
%W星期名
%w周的天 (0=星期日, 6=星期六)
%X年,其中的星期日是周的第一天,4 位,与 %V 使用
%x年,其中的星期一是周的第一天,4 位,与 %v 使用
%Y年,4 位
%y年,2 位
MySQL DATE_FORMAT() 实例 demo

我们使用 NOW() 来获得当前的日期/时间:
DATE_FORMAT(NOW(),'%b %d %Y %h:%i %p')
DATE_FORMAT(NOW(),'%m-%d-%Y') 
DATE_FORMAT(NOW(),'%d %b %y')
DATE_FORMAT(NOW(),'%d %b %Y %T:%f')

我的查询条件出来了
select * from student where age=date_format('2015-03-09','%Y-%m-%d'); 
how to use mysql DATE_FORMAT
--end by itlife365
分页: 1/8 第一页 1 2 3 4 5 6 7 8 下页 最后页 [ 显示模式: 摘要 | 列表 ]