嗨，大家好，SQL部落很久没有和大家分享新东西了，BBS近期也很少被Google爬来爬去的了。

前端时间刚换了工作，从5月16日开始，我正式成为了一名专职MySQL DBA（还在试用期），开始一段全新的体验。新就意味着有很多很多的工作要做，规范行为，整理思路，协调工作。回头一看一个月已经过去了，从之前没有写过SQL语句到现在平凡的数据统计、客服查询，一次次惊奇sql还可以这样那样，知道有那么多统计|时间|字符等各种有用的函数，开始一点点体会书本上学的索引在实际语句中的使用，是用表连接还是子查询，执行时间的快慢等等。

突然发现一个问题，感觉很明显，就是很多之前从书上学过了解到的知识，工作中并不会很自然地主动地被想起，而是每次就跟新东西一样，都是在同事的提示后，才恍然大悟，“哦，原来这样，其实，很早就知道这个东西的…..”，基本功不扎实呀！好比，渴了自然就会想到喝水。开始的自信与张扬已是消失殆尽，现在的心态就是：踏实、诚恳、谦虚地去学习，努力做好每件事情。

这一个月无论是工作的压力还是心情的波动，都让我体会颇多。第一次感觉到原来工作是有压力的，以及所背负的责任。我是一个很在意别人看法的人，我希望被每个人所认可，所以每次任务都积极去完成，但由于天生性格的急躁，还是总会弄出些岔子来。尽管开始成熟，但还是缺乏稳重。

下面就和大家抖露抖露我这一个月的“风花雪月”。

1. 头疼的SQL

任务：第一周领导就分配了统计需求的任务。将近20条语句以及数据导出弄了一周。说实话，现在对Tarot库还是一知半解，依然需要现查现看结构注释。

体会：SQL语句的组织并不是很难，刚开始一直被GROUP BY、COUNT()弄的很晕，写SQL是个熟练活，该用什么怎么实现也都很讲究技巧；而重要的是你需要对统计的这个系统本身有更多的了解，也就是业务流是什么，数据在各个表中是一个什么状态，是字典表、业务表还是日志型表，每个字段的确切含义。SQL对我来说几乎就是“零”，功能的实现目前来说都很吃力了，至于执行的性能，更是心有余而力不足，只能后期实际中遇到了再加以改进了。

2. 不小的事故

任务：每周二系统例行维护。对于数据库需要做的是，主库清除前一个月一周内的日志型表中的数据，并在从库进行全备。

体会：由于备份结束后，没有对北方区dump文件进行检查，dump文件只有4K，显然mysqldump出了问题（事实上，dump是正常结束的，困惑？），导致之前主库删除的数据丢失（因为我们的从库开启了log_slave_updates，binlog会记录同步过来所执行的sql语句）。在备份测试机上通过恢复4月的dump文件，将被清除的那一周数据导出，然后用从新做的新dump文件恢复后，将之前导出的数据重新导入到库中，最后在重新做一次全备，得到4.5G的dump文件，tail -n 1 dbname.sql结尾行正常“Dump Completed on …”（感谢realzyy提供的简单快捷的检查方法）。当初觉得，这些历史数据对应用本身并没有影响，只是为运营团队提供后期数据分析，反正已经成功回复，也没有太当回事，之后也没及时向领导汇报，后来领导找我谈话，我才深刻认识到问题的严重性，对于数据一定一定要格外加倍小心，无论是做什么用的，必须保证安全。经过这次风波后，做任何操作我都变得格外小心。做事情的条例很重要，开始的时候，哪怕慢点也要力求稳，不知道不清楚绝对不能操作；我们要知道获得一份信任需要很长的时间，但是让别人放弃你那是瞬间的事情。The first time is also the last time…Keep in mind…Be careful….Fish….我现在时刻背负着被开的风险，只能靠以后积极努力的工作去挽回失去的信任。

3. 完善备份

任务：定期全备与每日增量备份脚本的测试与修改。

体会：一周都在修改shell脚本，有脚本帮我们去完成重复性的操作既方便又可靠，但是脚本不是能实现你的工能就可以了，事实上，我们更想知道执行的结果正常与否，这就需要脚本能够收集这些信息并反馈给我们，所以要生成日志文件便于我们查看，或以邮件方式将报告发给我们。

关于mysqldump的参数选择，我最近体会颇深。之前写过一篇MySQL企业级备份与恢复，现在想下就是标题当，什么狗屁。 mysqldump什么参数都不加，一看就不专业。突然想起来之前去飞信面试，周师傅问我，mysqldump备份的时候加什么参数吗，我很自豪的回答，什么都不加呀，那个默认opt就很好了，现在想想脸红呀，差的不是一点。

4. 语句分析

任务：开发人员反应客服系统中一条SQL语句执行过长，导致系统超时报错，同时呢，还会导致主从复制不一致（Seconds_Behind_Master超过300秒nagios会报警）。

体会：这条语句是做分页的，每次显示50条记录，同时按时间排序，3个表(record_goods,goods,characters)做关联，其中一个是物品交易表(record_goods)，有千万条记录，每次执行该条语句时，我在从库的服务器端show processlist\G去查看该条语句的执行状态，发现stat是locked，被锁住了，同时发现slave中的sql_thread线程也同时有一条update语句locked在那里，但是，惊奇的发现这个被锁的表，却是那3个表中的其中物品信息表(goods)，然后我又show table status goods\G，发现该表竟是MyISAM的，而且那个update time时间在不停的更新。这下明白了，从库保持同步主库上goods表的update操作，这样就会对goods表叫锁，它又是MySIAM表，自然表级锁，当我们在执行那条查询语句时，如果执行时间过长，update操作就会被锁住，导致从库同步落后时长增加，导致nagois报警。之前提到，物品交易表非常庞大，后来我们采用自查询，先对record_goods表和characters表做表联接，查出符合条件间的50条记录，然后再将产生的结果集与goods表做关联查出最后系统所需的结果，执行时间不到1秒。我要从新更新我脑子里面之前那些经验性的总结，至于是表联接性能好，还是子查询性能好，实际中怎么好就怎么来吧。

这一个月的体会就是这么多了，下次再继续分享我的DBA初体验。

建议继续学习：

1. 我对技术方向的一些反思    (阅读：9851)
2. Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩    (阅读：4389)
3. oracle技术方面的路线    (阅读：3311)
4. MySQL DBA修炼秘籍    (阅读：3172)
5. 我的担忧：dba如何在稳定环境中成长    (阅读：3023)
6. DBA最缺的不是技术    (阅读：2673)
7. DBA有什么个人前途?    (阅读：2688)
8. MySQL DBA面试全揭秘    (阅读：2620)
9. 《Oracle DBA手记》一书推荐 - 感谢刘松先生    (阅读：2496)
10. 应用DBA的价值    (阅读：2411)