MySQL FAQ

其实很简单，就是利用linux下的 watch 工具来做监控，方法如下：

[yejr@localhost imysql]# watch -d -n 10 "egrep 'MySQL thread|Log|Modified db pages' innodb_status.3249 "     
Every 10.0s: egrep 'MySQL thread|Log|Modified db pages' innodb_status.3249                                               Thu Apr  9 10:01:12 2009

原文参考：http://www.xaprb.com/blog/2009/03/25/mysql-command-line-tip-compare-resu...

利用mysql客户端的pager功能即可：

mysql> pager md5sum -
PAGER set to 'md5sum -'
mysql> select * from user;
b20bd3864962507e2e05cd8706440ffd  -
3 rows in set (0.00 sec)
mysql> select * from user;
b20bd3864962507e2e05cd8706440ffd  -
3 rows in set (0.00 sec)
mysql> select * from user;
b20bd3864962507e2e05cd8706440ffd  -
3 rows in set (0.00 sec)

还不错吧，哈哈

同事碰到麻烦，寻求帮忙，问题是这样的：
有个InnoDB表，想要用 LOAD DATA INFILE 的方式倒数据进去，发现报错：table is full。
我看了一下，日志中没有相关可用信息，该表使用的是共享表空间，总共6个ibdata*文件，只有2个文件的修改时间是最新的，觉得可能不是因为表空间慢的缘故，于是尝试插入少量数据试试看先。分多次插入10,20,100条记录都没问题，一次性插入500多条记录时，就又报table is full了。看来，事务没有问题，再把焦点转会表空间问题上来。尝试性的关闭mysqld，新加一个表空间文件，启动，再插入更多数据，发现这次没问题了，搞定。

一朋友发来消息，说他的mysql报错，日志大致如下：

090318 15:16:35 InnoDB: WARNING: over 4 / 5 of the buffer pool is occupied by
InnoDB: lock heaps or the adaptive hash index! Check that your
InnoDB: transactions do not set too many row locks.
InnoDB: Your buffer pool size is 16 MB. Maybe you should make
InnoDB: the buffer pool bigger?
InnoDB: Starting the InnoDB Monitor to print diagnostics, including
InnoDB: lock heap and hash index sizes.

前言：我想，对于新手来说，有个很重要的问题，就是在mysql发生问题时，就束手无策，不知道该做什么了。要么到论坛里发“冰天雪地裸体跪求帮助”或“急急急”之类的帖子，要么在群里狂喊，对解决问题毫无帮助。这个时候，新手们要做的就是，学会看日志，并且找到问题所在，然后尝试自己动手解决，或者把问题描述清楚，让有经验的人士帮忙。本文说下几种常见问题，以及解决问题的丝路。

前言: 今天帮同事处理了一个关于mysql授权的问题，虽是小事，不过不注意的话，还挺头大的，呵呵。
先对比看看下面2个授权信息之间的区别吧：

GRANT SELECT, DELETE, UPDATE, INSERT ON *.* TO 'yejr'@'192.168.0.1' IDENTIFIED BY PASSWORD '*1088950C531DC1BE311435F60B57145D8A49019C'

和

GRANT SELECT, DELETE, UPDATE, INSERT ON `*`.* TO 'yejr'@'192.168.0.1' IDENTIFIED BY PASSWORD '*1088950C531DC1BE311435F60B57145D8A49019C'

呵呵，看起来都很像，没什么问题吧，实际反映到数据库授权表结果变成了：

调用存储过程时，发生报错，信息如下：

ERROR 1267 (HY000): Illegal mix of collations (gb2312_chinese_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '='

很明显，这是字符集方面的问题。
查看数据表，字符集是gb2312没错，连接字符集，服务器端字符集也全都是gb2312。怀疑是字段的字符集有问题，修改了一下，也不行。
后来创建一个临时变量，设定其字符集为gb2312，仍然不行：

set @name = in_name collate gb2312_chinese_ci;

调用存储过程时，碰到错误，大致信息如下：

error 1449 “There is no ‘username’@'host’ registered”

这是因为该存储过程的所有者/定义者(definer)不存在导致的，可能是由于管理员不小心给删除了等引起的，只需要重新创建对应账户，或者将该存储过程的定义者修改成一个已存在的账户，例如：root@localhost即可。

附：触发器也会有这个问题，5.1版本中的Event Scheduler应该也有，需要注意下。