常见的 MysqL 异常及处理方法

在使用 MysqL 的过程中，我们会碰到各种各样的问题，如数据库突然响应很慢、表碎片空间占比过大等。本小节我们一起来学习一些常见的 MysqL 异常，以及响应的处理方法。

1. 主从同步数据异常，如何跳过错误？

由于种种原因，有时候从库可能会出现因主从数据导致的无法执行的 sql 语句，那么此时就要跳过该sql 语句了。

1.1 binlog+position 模式

-- 在从库上操作
) 跳过错误报错
MysqL> stop slave;
MysqL> set global sql_slave_skip_counter =;
MysqL> start slave;

) 查看同步状态
MysqL> show slave status\G

1.2 GTID 模式

方法一：直接跳过错误：

-- 在从库上操作
) 停止slave进程
MysqL> STOP SLAVE;

) 设置事务号，事务号从Executed_Gtid_Set获取，在session里设置gtid_next，即跳过这个GTID
如从show slave status拿到Executed_Gtid_Set为xxxx:-
MysqL> SET @@SESSION.GTID_NEXT= 'xxxx:5'

) 设置空事物
MysqL> BEGIN; COMMIT;

) 恢复事物号
MysqL> SET SESSION GTID_NEXT = AUTOMATIC;

) 启动slave进程
MysqL> START SLAVE;

方法二：重置master方法跳过错误

-- 在从库上操作
-- 如从show slave status拿到Executed_Gtid_Set为xxxx:1-4,以下命令表示，忽略xxxx:1-5这个GTID事务，下一次事务接着从 6 这个GTID开始，即可跳过上述错误。
) 停止slave进程
MysqL> STOP SLAVE;

) 重置MASTER
MysqL> RESET MASTER;

) 设置GTID_PURGED
MysqL> SET @@GLOBAL.GTID_PURGED ='xxxx:1-5';

) 启动slave进程
MysqL> START SLAVE;

2. 如何清理表碎片

当某张表删除完大量数据，或 MysqL 运行很长时间（一般指半年）后，难免会产生表碎片，这时就要对表进行碎片清理。

) 查询表碎片大小（一般碎片率超过%，可以考虑清理表碎片）
MysqL> select t.table_name, t.table_schema, t.ENGINE, t.TABLE_ROWS, ROUND(t.DATA_LENGTH//,) DATA_LENGTH_MB, ROUND(t.INDEX_LENGTH//,) INDEX_LENGTH_MB,
  ROUND((t.DATA_LENGTH+t.INDEX_LENGTH)//,) SUM_LENGTH_MB, ROUND(t.DATA_FREE//,) DATA_FREE_MB, CONCAT(ROUND((t.DATA_FREE / (t.DATA_LENGTH + t.INDEX_LENGTH + t.DATA_FREE)) * ,),'%') FRAGMENT_RATE 
  from @R_846_4045@ion_schema.tables t
where =
and t.DATA_FREE != 
and (t.DATA_FREE / (t.DATA_LENGTH + t.INDEX_LENGTH + t.DATA_FREE)) >=  -- 碎片率超过30%
and t.TABLE_ROWS >= 
and ROUND(t.DATA_FREE//,) >= 
order by t.DATA_FREE / t.DATA_LENGTH desc

) 清理表碎片
-- MyISAM存储引擎
MysqL> OPTIMIZE TABLE tbl_name

-- Innodb存储引擎
MysqL> ALTER TABLE tbl_name ENGINE = Innodb;

3. cpu突然爆表，如何解决？

cpu 使用率突然暴增至 90% 以上，数据库响应非常缓慢，一般都是某个 sql 出现性能问题，耗光 cpu 资源。

) 定位问题sql
-- 找到执行时间很长，且占用会话比较多的sql
MysqL> show processlist\G
MysqL> select * from @R_846_4045@ion_schema.processlist order by info desc\G

) 分析执行计划，判断sql是否存在优化空间
MysqL> explain select * from xxx where xxx=xxx\G

) 实施优化措施
这里就比较考验优化功力了，根据不同的问题sql，快速判断需要采取何种优化措施。最简单的例子，sql的where条件没有走索引，而且字段的选择性比较高，那这时就要考虑给字段创建相应的索引来解决。

4. 如何处理锁表问题？

当发生死锁问题时，一般通过 imformation_schema 的表来查询相关的事务和锁信息，找到产生死锁的源头会话，将该会话kill掉。

) 查找产生死锁的源头会话
--以下sql能看到谁阻塞和谁在等待，以及等待多久的查询。
MysqL> SELECT
     IFNULL(wt.trx_MysqL_thread_id, ) BLOCKING_THREAD_ID,t.trx_MysqL_thread_id WAITING_THREAD_ID, CONCAT(p. USER, '@', p. HOST) USER,
     p.info sql_TEXT, l.lock_table LOCK_TABLE, l.lock_index LOCKED_INDEX, l.lock_type LOCK_TYPE, l.lock_mode LOCK_MODE,
     CONCAT(FLOOR(HOUR (TIMEDIFF(Now(), t.trx_wait_started)) / ),'day ',MOD (HOUR (TIMEDIFF(Now(), t.trx_wait_started)),),':',
     MINUTE (TIMEDIFF(Now(), t.trx_wait_started)),':',SECOND (TIMEDIFF(Now(), t.trx_wait_started))) AS WAIT_TIME,
     t.trx_started TRX_STARTED, t.trx_isolation_level TRX_ISOLATION_LEVEL, t.trx_rows_locked TRX_ROWS_LOCKED, t.trx_rows_modified TRX_ROWS_MODIFIED
     FROM @R_846_4045@ION_SCHEMA.INNODB_TRX t
     LEFT JOIN @R_846_4045@ion_schema.innodb_lock_waits w ON t.trx_id = w.requesting_trx_id
     LEFT JOIN @R_846_4045@ion_schema.innodb_trx wt ON wt.trx_id = w.blocking_trx_id
     INNER JOIN @R_846_4045@ion_schema.innodb_locks l ON l.lock_trx_id = t.trx_id
     INNER JOIN @R_846_4045@ion_schema. PROCESSLIST p ON t.trx_MysqL_thread_id = p.id
     ORDER BY \G

5. 小结

本小节主要总结了一些经常碰到的 MysqL 异常及相应处理方法，除此之外，在实际使用过程当中，大家肯定还会碰到各种各样的疑难杂症，经常进行总结可以积累丰富的实战经验。

常见的 MySQL 异常及处理方法