一 简介:这里汇总了一些mysql常见的问题
二 案例场景
问题1 mysql设置了默认慢日志记录1S,为何会记录不超过1S的sql语句
答案 mysql~log_queries_not_using_indexes变量会记录全表扫描的语句,判断优先级高于执行时间,也就是说,你如果打开这个变量,哪怕执行不到1S的查询也会记录到慢日志中,建议关闭
问题2 程序错误信息 max_allowed_packet 设置过小导致java程序写入失败
答案 1 max_allowed_packet=32M 写入配置文件并重启
2 set global max_allowed_packet=33554432
问题3 mysql崩溃后无法启动,mysql.error中报BUG错误
分析 此问题最常见于断电后数据库无法启动造成的
1数据页损坏
2数据字典损坏
在ibdata1中（或以其他方式命名）文件中的数据与在单个表空间/.ibd / .frm文件的数据之间有明显的关联。当该关联丢失或损坏，可能会发生不好的情况。所以这像这样的数据字典的错误出现，最常见的原因是有些文件被手动移动或修改。它通常归结为：“数据字典预计这一文件或表空间在这里，但它不在！”，或“.ibd / .frm文件预计此项目在数据字典中，但它不在！ “。再次记住，数据字典存储在ibdata文件中，在大多数环境中，就是MySQL数据目录中的ibdata1。
3 日志页损坏
4 版本BUG
通用解决办法：
一 调整恢复级别
1 调整恢复级别,请注意,恢复前先备份下,因为恢复是有代价的
2 设置参数 innodb_force_recovery=N 下面是恢复参数代价
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
3 启动mysql,然后dump出可以dump的数据,进行异地恢复
二 利用工具进行数据页修复
mysql进程停止下
1 /nnochecksum -f /tol/mysql/data/ibdata1 ibdata1文件修复
2 #!/bin/bash ibd文件修复
for i in $( ls /var/lib/mysql/*/*.ibd)
do
innochecksum $i
done
3 进行启动修复
三 mysqlcheck 进行表检测
mysqlcheck dbname