4月3日数据库问题复盘

4月3日18:55，MySql master主库CPU利用率从10%上升到98%，导致写操作无法响应。

image.png

事故处理

当时情况DBA已经无法登陆数据库，DBA建议重启MySql，会导致MySql 30s内无法写入；同时查找到造成CPU飙升的sql，添加索引。

SELECT *
FROM t_study_statistical
WHERE user_pid = ?
    AND study_day = ?

UPDATE t_study_statistical
SET study_duration = ?, study_audio_count = ?
WHERE record_pid = ?

...

重启之后，添加索引，CPU使用率稳定在10%以下。

事故原因

CREATE TABLE `t_study_statistical` (
  `record_pid` bigint(20) DEFAULT NULL,
  `user_pid` bigint(20) NOT NULL,
  `study_duration` double(11,2) DEFAULT NULL,
  `study_audio_count` int(11) DEFAULT NULL,
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

...

这张表没有添加索引，所以查询、更新是全表查询，效率低；然而更加雪上加霜的是，这个表数据量增长很快，一天按照用户量会添加10万数据；再加上压弯骆驼的最后一根稻草，这个表会频繁更新，1分钟内执行了137次 select update。

反思

当我们在设计表的时候，需要考虑到未来这个表的数据量，然后根据我们所写的sql进行针对性的优化；同时建立代码review机制，如果我们能在内部首先检查到到这个问题，就能避免线上出现问题。