转载 http://www.cnblogs.com/zjoch/p/3267131.html

 mysql> select * from test;
 ERROR 1034 (HY000): Incorrect key file for table ‘test’; try to repair it

首先通过repair table修复：

 mysql> repair table test;
 +—————+——–+———-+———————————————————+
 | Table         | Op     | Msg_type | Msg_text                                                |
 +—————+——–+———-+———————————————————+
 | test.test | repair | Error    | Incorrect key file for table ‘test’; try to repair it |
 | test.test | repair | error    | Corrupt 

如果还是没用，运行下面命令

 mysql> repair table test USE_FRM;
 +—————+——–+———-+———————————————————+
 | Table         | Op     | Msg_type | Msg_text                                                |
 +—————+——–+———-+———————————————————+
 | test.test | repair | Error    |Number of rows changed from 0 to 110423 |
 | test.test | repair | status   | OK  

按理应该可以了。
如果还是没用，则退出mysql，执行如下修复动作：

 myisamchk -of /var/lib/mysql/test/test.MYI
 myisamchk -r /var/lib/mysql/test/test.MYI
 myisamchk safe-recover /var/lib/mysql/test/test.MYI

再重启mysql后应该可以正常了。

mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。

① STATEMENT模式（SBR）

每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

ROW模式（RBR）

不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。

MIXED模式（MBR）

以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

binlog复制配置

在mysql的配置文件my.cnf中，可以通过一下选项配置binglog相关

binlog_format           = MIXED                         //binlog日志格式，mysql默认采用statement，建议使用mixed
log-bin                 = /data/mysql/mysql-bin.log    //binlog日志文件
expire_logs_days        = 7                           //binlog过期清理时间
max_binlog_size         = 100m                       //binlog每个日志文件大小
binlog_cache_size       = 4m                        //binlog缓存大小
max_binlog_cache_size   = 512m                     //最大binlog缓存大小

三 MIXED说明

对于执行的SQL语句中包含now()这样的时间函数，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。

现在来比较以下 SBR 和 RBR 2中模式各自的优缺点：

SBR 的优点：

历史悠久，技术成熟
binlog文件较小
binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
binlog可以用于实时的还原，而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高

SBR 的缺点：

不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出问题
使用以下函数的语句也无法被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
INSERT ... SELECT 会产生比 RBR 更多的行级锁
复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事
确定了的 UDF 也需要在从服务器上执行
数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
执行复杂语句如果出错的话，会消耗更多资源

RBR 的优点：

任何情况都可以被复制，这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技术一样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下几种语句时的行锁更少：
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执行 INSERT，UPDATE，DELETE 语句时锁更少
从服务器上采用多线程来执行复制成为可能

RBR 的缺点：

binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题
UDF 产生的大 BLOB 值会导致复制变慢
无法从 binlog 中看到都复制了写什么语句
当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生

另外，针对系统库 mysql 里面的表发生变化时的处理规则如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都采用 SBR 模式记录
注：采用 RBR 模式后，能解决很多原先出现的主键重复问题。

错误日志

查看错误代码

[root@jin ~]# perror 16
OS error code  16:  Device or resource busy

通用查询日志

通常不开启，当需要采样分析时开启，分析结束记得要关闭，不然对服务器的性能会有影响

在mysql中直接设置

set global general_log=1;

修改mysql配置文件

[mysqld]
general-log-file[=path]
general-log=1

慢查询日志

当查询结果超过一定的时间没有返回结果时才会记录
可以查找出执行效率低的sql语句，为数据库优化提供帮助
默认不开启，需要采样分析时开启
采样分析结束后关闭
1.使用配置文件开启慢查询日志

#是否开启慢查询日志,(mysql中 _ 和 - 意义相同，slow_query_log 和 slow-query-log 意义相同)
slow_query_log=on|off
#指定日志文件路径,默认路径为数据库文件所在目录下，名称为hostname-slow.log
slow_query_log_file=path
#指定多少秒未返回结果的查询语句数据慢查询
long_query_time=2-
#记录所有没有使用到索引的查询语句
long-queries-not-using-indexes
#有查找多于了1000次而引发的慢查询，例如全表扫描之类的
min_examined_row_limit=1000
#记录慢的 optimize table, analyze table, alter table 语句
log-slow-admin-statements
# 记录由slave所产生的慢查询
log-slow-slave-statements

2.直接在mysql中修改

set @@global.slow_query_log=1;
#set global slow_query_log=1;#与上一行意义相同
set @@global.long_query_time=3; 

其他参数可以通过如下命令查阅

show variables like "%slow%";

慢查询分析工具

# mysql官方安装包里面就有
mysqldumpslow
# 第三方工具
mysqlsla
#percona-toolkit中的pt-query-digest

二进制日志

记录对数据发生或潜在发生更改的sql语句
二进制格式保存
用途广泛,包括，查看数据库变更历史，数据库增量备份，数据库灾难恢复，mysql赋值
1.在mysql中直接开启

set @@global.log_bin=1;
set @@global.binlog_size=37268;#单位 bytes
show variables like "%bin%";#查看其他相关参数

2.在配置文件中开启

#开启并指定二进制日志保存路径及文件名，默认值为 hostname-bin.xxx
log-bin=
#设置单个二进制日志文件的最大值，默认为1GB,最大为1GB
max-binlog-size=500m
#记录sql语句的方式,有三种STATEMENT,ROW,MIXED,默认为STATEMENT,STATEMENT性能较高，但某些情况可能导致主从服务器数据不同步，ROW能保证数据的一致性，但是性能较低，日志文件较大，MIXED是两种方式的混合，详情可查看 http://jinblog.com/archives/704.html
binlog_format=STATEMENT
#指定二进制日志文件记录哪些数据库的操作
binlog-do-db=test# 指定记录哪些库
bingo-ignore-db=test1# 指定忽略那些库
#二进制日志缓存大小
binlog-cache-size=100m
#每隔n秒将缓存中的二进制日志记录写回硬盘，默认为0。不过，你经常会陷入group commit函数与I/O之间二选一的矛盾(commit是并发的，而binlog的记录是串行的)。如果在replication环境中，由于考虑到耐久性和一致性，则需要设置为1，同时还需要设置innodb_flush_log_at_trx_commit=1以及innodb-support-xa=1(默认开启)
sync-binlog=n

暂停日志

set sql_log_bin=(0|1);

查看二进制日志

mysqlbinlog hostname-bin.000002

使用二进制日志恢复数据

mysqlbinlog host-bin.000002 | mysql

或

mysqlbinlog host-bin.000001 > backup.sql
mysqlbinlog host-bin.000002 >> backup.sql
mysql dbname < backup.sql

删除二进制日志

二进制日志会不断增长，并产生多个文件，因此需要制定备份计划和管理策略，无用的二进制日志文件需要及时删除
删除二进制日志的三种方法
1.操作系统直接删除二进制日志文件
2.reset master
3.purge

purge {master|binary} logs to 'log_name';
purge {master|binary} logs before 'date';

例子

# 删除000003之前的二进制日志文件(000001和000002)
purge master logs to 'host-bin.000003';

关掉mysql
使用 mysql_safe 命令开启mysql，跳过权限验证,如下

mysqld_safe --skip-grant-tables &

然后登陆mysql就不要密码了，进入mysql修改密码就行

mysql权限

权限介绍

用户权限(user表)->数据库权限(db数据表)->主机权限(host表)->执行权限(procs_priv表)
用户权限(user表)->数据库权限(db数据表)->主机权限(host表)->表权限(tables_pri表)->列权限(columns_pri表)
和上面一样，从上到下，只要有一条符合就通过权限验证

用户(user)权限

记录允许连接到服务器的连接
全局权限控制

数据库(db表)权限

记录用户对数据库的操作权限

主机(host表)权限

记录某个主机对数据库的操作权限
配合db表可以做更加细致的控制

表(tables_priv)权限

用来设置用户对表的权限

列(columns_priv)权限

设置用户对列的权限

账户管理

grant与revoke

创建用户

创建方式1

create user 'username'@'host' [identified by 'PASSWORD'];#创建的用户不具有任何权限

创建方式2

grant <all|priv1,priv2,...privn> on [object]
[identified by 'password']
[with grant option];# 是否允许权限下放
object:table|function|procedure
grant option:
max_queries_per_hour count
max_updates_per_hour count
max_connections_per_hour count
max_user_connections count

创建用户并赋予权限

grant all on test.* 'jin'@'192.168.1.62' identified by '123456';#给予用户所有的权限
grant alter select,insert,update,delete,create,drop on test.* from 'jin'@'192.168.1.99';# 给予用户单个权限

删除用户

drop user 'jin'@'192.168.1.99';

查看用户权限

show grants for jin@192.168.1.99\G;#查看指定用户的权限
show grants;#查看自己的权限

刷新权限

在修改完用户的权限信息之后，需要刷新缓存才能生效

flush privileges;

添加用户权限

grant insert on test.t4 to jin@192.168.1.99;

移除用户权限

revoke insert on test.* from 'jin'@'192.168.1.99';
flush privileges;#刷新权限

设置用户密码

set password=password('123456');# 给用户自己设置密码
set password for jin@192.168.1.99=password('123456');#给指定用户设置密码
update mysql.user set password=password('12345') where User='jin' and Host='192.168.1.99'; #直接修改用户表，这个需要刷新权限菜能生效
mysqladmin -h 192.168.1.99 -ujin -p12345 password "123456"#使用mysqladmin命令工具改变密码