Don't Panic

项目中很多表由于接手人很多，所以管生不管养的建立了大量索引。
造成索引比数据大很多的奇葩现象，于是要找一找什么方式能方便的统计到索引的使用情况。
于是发现了performance_schema库中的表table_io_waits_summary_by_index_usage。
它聚合了所有表索引I / O等待事件

继续关注数据库问题，access记录中有大量超时请求，但慢日志却并没有记录。
随即通过show full processlist发现线上数据库出现大量（数百）的非正常process

前天解决了mysql的索引合并(using intersect)造成的死锁后，变刘鑫观察死锁信息
于是又发现一个造成死锁的常规语句

1

insert into xxx(x,y,z) values(a,b,c) on duplicate key update z = c;

线上日志报警，出现大量死锁

1

Error 1213: Deadlock found when trying to get lock; try restarting transaction 

排查后发现是使用了索引合并，从而在并发较高时触发了死锁

有一项MySQL数据迁移的工作，将原表（2000W+数据量）的数据处理后，分表（256张）存储
是用Go来完成，计划使用相当于表数量的goroutines同时处理
计划很好，代码也简单，按某个字段F取余决定分到某张表，然后按照字段F分组后，每组交由一个go协程处理
然而，运行后不久就会报错

1
2
3

connectex: A connection attempt failed because the connected party did
  not properly respond after a period of time, or established connection failed
  because connected host has failed to respond

由于数据要进行hash处理，所以输入输出处的使用处都需要进行修改
一个方案是输入处进行decode，输出进行encode，改动幅度相当可观
最终决定是定义一个新类型，并通过定义UnmarshalJSON和MarshalJSON方法来实现自动序列化/反序列化

功能重构后的数据迁移，有一张被拆分的表，迁移时直接使用了insert into(xxx) select xxx from的方式，简单高效
然而，实则是挖了个坑，还好发现的早，不然就是严重事故了
都是因为一个ENUM字段

公司产品有一个功能，通过excel导入手机号白名单
输入的手机号在白名单中的用户才能进入页面正常使用
有用户反馈，白名单内的手机号无法识别
且手动输入不行，从白名单复制却可以
最终是Unicode不可见字符的问题
类似U+202D U+202E

在go项目中使用redis时，难免要使用Get/Set存取一些复杂的数据结构
直接缓存会报错

1

redis: can't marshal xxx (implement encoding.BinaryMarshaler)

xxx为对应的数据结构
此时就要自定义一些方法来解决了

发现代码中竟存在大段json数据靠字符串拼接的方式完成，着实尴尬
通过修改记录追溯，果然是从一个小数据量逐渐增量的
如今出了bug才暴露问题
看来’前辈们‘信奉的是又不是不能用.jpg