- 第二十七期 数据库设计-使用篇2
- 1 事务
- 2 换一个环境
- 3 DBA
- 4 总结
没啥说的，被卷了继续写一篇。
1 事务针对关系型数据库或者某些支持事务的非关系型数据库，事务是啥，这个不用多说，这里也不做过多的解释。但是这里要提一下一般事务完成（主要是commit）以后，其实会进行一系列操作，包括但不限于刷内存、写在线日志、写归档or二进制or其他同类日志、数据写磁盘、标记undo（如果有）、全局一致性记录等等一系列操作。下面用俩在Oracle上遇到问题的案例说一下我对事务设计的理解：
1.在Oracle数据库中基于commit比较常见的等待就是log file sync（日志写不赢了）。当然日志写不赢的原因有好些：IO不行了、日志组太小了、事务太碎了等等。这里说下事务太碎的问题，之前遇到过一个批处理，只要这个批处理跑起来数据库就会慢，和业务侧一起排查发现里面有很多非常零碎的DML操作，而且每完成一个DML操作commit一次，造成了大量的相关等待。梳理业务逻辑后将commit位置进行了调整，调整后会在一系列DML操作之后才统一提交，减少了大量log file sync的等待。因此我认为事务要足够大，来减少事务频繁提交造成大量资源消耗。
2.事务除了commit后前滚，也可能出现回滚的现象，在出现非常大的事务（其实往往不需要设计的这么大），在出现需要回滚（业务需求或异常）的时候，在回滚的时候就会造成对undo和内存数据的大量操作。回顾祖上那几期，其实就因为bug加上大事务回滚造成过数据库hang死的现象（当然这个不常见），但是大事务本身还是会造成很多问题（资源损耗、占用等等啊，据说对MySQL影响更大）。因此我再次认为，事务也要足够小，在覆盖需求的情况下，控制事务本身的资源占用。
这里用另一个处理过的问题来引出这一节的论点，但是我隐约记得祖上有一篇提到过。一个上云的事情，相同的业务，在本地内网中，运行的飞起。但是上云之后，各种卡各种慢。为啥呢？其实上云没上云AWR报表里面，就数据库运行本身没有啥变化，数据库本身性能还是杠杠的，但是多了很多网络侧收发包的等待。这又是为啥呢？原来以前在本地，机房内网内，网络延迟仅在1ms以内，而上云之后，网络延迟达到了40ms。但仅仅是网络延迟不应该造成如此大的影响，经过对业务逻辑进行分析发现，所有的操作都是线性的，都是上一条语句完了下一条语句在跑，以分页查询为例，没有先计算分页数量，是不管多少数据直接查询1000个分页，而且必须是上一个分页完成以后查下一个分页，无效分页也必须运行完成以后才能统一输出结果。这样的逻辑设计就造成了那40ms的延迟被无限放大了，当然其他类似设计还有很多。虽然这样的设计本身就有问题，但是在网络延迟很低的环境中确实不会造成太大影响。因此数据库的设计需要考虑的还有很多，比如网络环境。
3 DBADBA，Database Administrator，数据库管理员，管理数据库的人（又是听吾一句话如听一席话）。DBA到底该干些啥呢（扩展出去应该是运维该干些啥）？我们先看看现在做了些啥：常规的搭建、维护数据库，然后就是贯穿我所有文章里面的重点内容——擦屁股了。经常都是出现了数据库相关的问题，或者我们发现问题了再去排查分析解决处理。其实在我文章里面解决的绝大多数问题都是都是因为业务侧引起的问题：SQL语句的问题、业务逻辑的问题、连接池的问题、程序安全的问题等等。其实很多问题在业务设计阶段如果DBA介入一起讨论，都是可以避免的。然鹅在我这里的现状就是，很多业务厂商压根没有DBA，由于是多租户我相当于大家共用的DBA，但有分属不同的公司，没法从设计阶段就介入开发。另外一方面呢，很多开发并没有了解数据库运行机制，甚至是很多开发能力经验不足（又不少都是快餐培训出来的），那语句写的简直都没法看，而且说句难听点的遇到过的，很多开发打心底里瞧不起运维，很多时候去沟通的时候一副高高在上的姿态甚至很歪（四川话）。回过来又说，很多地方确实把DBA当成了兜底的救火队员，感觉无论出了任何事情，DBA都能给救回来，我还是那句话，人都是有极限的，如果环境的整体配置（高可用、容灾、备份等）稍微差一点，DBA都不能成为神仙。
这里小结一下，其实DBA的要求挺高的，除了对数据库本身要有十分程度的了解，对于其运行的操作系统也要有一定了解（这里其实我很不喜欢某些DBA完全不了解操作系统，一些公司也把二者分的很开），一个优秀的DBA甚至还要对数据库运行环境中的服务器、网络、存储等有一定的了解。除了基础知识，经验也很重要，而且也不仅仅是数据库本身的相关经验，对于开发、运行环境等经验也需要相当的程度。所以我认为一个合格的DBA是需要时间、场景、环境甚至是优秀导师来培养的。
那么回到本节最早的问题，DBA该做些啥？除了要有足够的知识及经验解决数据库运维的各类问题，防患于未然也是很重要，首先对数据库要有有效的监控手段，监控数据库运行的各项指标，持续的监控可以有效预先发现问题，比如检查SQL语句执行情况可以协助进行优化。再借用上海某公司数据库总监薛总写的近期一篇文章（详见公众号“四海内皆兄弟”），告警配置是十分重要的，监控是有效的巡检和溯源手段，但是人不能时时刻刻都盯着，因此需要将监控中的问题（比如数据库日志异常、超阈值指标等）及时通知到DBA。
当然DBA需要做的，需要具备的能力还有很多，以后想到了慢慢扩展。
这篇文章章节少了些，本来想单独写一篇DBA该干些啥，但上一篇又感觉缺了点东西，还是加上那句口头禅吧：不晓得写了些啥。
