操作审计是监管政策的要求之一。为了方便快速定位、排查数据库问题、提供审计运作，DMS在操作日志基础上推出了操作审计功能，记录了包括SQL窗口产生的SQL语句列表、工单列表、登录列表及操作日志等信息，审计或管理人员可以随时通过控制台页面或Open API获取审计日志。
企业数据开发中，如果上线了低效或有漏洞的SQL，可能会导致数据库故障。传统的SQL审核依赖于人工，效率差且容易出错。
DMS提供了一种SQL审核方案，支持对上传的SQL语序进行审核并提出优化建议，避免无索引或不规范SQL。
DMS提供了3种系统行为动作，包括必须改进、潜在问题和建议改进。其中，必须改进会阻塞SQL执行，必须进行改进直至通过验证。
DMS内置了一些安全规范，如表要有主键、表要有备注、表不能有外键、限制大小写等。
DMS提供了潜在问题、建议改进、必须执行等行为动作，前二者执行后页面会弹出优化建议但不会阻塞执行，后者则必须执行。此外，优化建议也可以进行编辑。
除支持SQL上传审核，DMS也支持多种类型文件的审核，如代码框架XML文件、SQL文本文件、Trick数据库日志文件等。
如图中，开发审核中申请SQL审核不通过，建议改进后执行。
数据库DDL操作在数据量较大的情况下会有所阻塞，MySQL5.6版本提供了原生online DDL，覆盖大部分DDL类型，但仍有部分常见的DDL不支持，如修改列类型、修改字符长度等。
市面上一些开源工具支持更广泛的DDL类型，但其实现方式依赖于通过触发器实现增量数据同步。
Online DDL通过生成新结构临时表同步全量数据，依赖触发器保存增量数据同步到临时表中。通过触发器实现增量数据同步存在一些弊端：
• 触发器本身性能开销较大，实际是将两张表的操作关联到一个事务中。
• 触发器不能暂停或中断，否则就会出现变更中断或数据丢失问题。
• 触发器无法灵活控制，存在主备延迟问题。
DMS无锁表结构变更通过消费binlog事件，将原表增量变换同步到目标表中。这种方式将原表和目标表解耦，目标表的增量数据并不直接来源于原表。
DMS无锁表结构变更可以根据系统负载及主备延迟情况，随时中断或者放慢DDL执行速度。虽然任务执行时间较长，但其影响更小并且更健壮，任务失败只需重试即可。开启了Online DDL的数据在完成DDL操作后，表碎片率会更低。
DML执行大批量数据更新时间较长，大事务可能会导致锁表，造成数据库故障。将大批量数据更新拆分成小批量完成，不仅拆分复杂，如果更新操作没有索引，任务执行效率会变差。
DMS无锁表数据变更能够自动查找唯一键，根据唯一键分批拆分SQL。拆分成单个事务后，单索引SQL效率提高且不会对线上业务造成很大影响。
DMS无锁表数据变更还提供了动态Slip策略，批量执行后系统提供一定的Slip缓冲空间，有效缓解了大事务带来的储备延时问题，也保证主户更加稳定。
针对误删数据或错误更新数据的数据恢复问题，传统DBA管理通过数据库先恢复全量数据再恢复增量数据，这种方式成本高且时间较长，且需要数据库本身具有完善的备份方案。
DMS提供了一种数据追踪方式，只需要提供误操作的时间以及SQL类型、表信息等，就可以快速从 binlog中按需找到目标时间段内的相关更新，汇总形成逆向回滚数据，将回滚SQL语句在数据库中重新执行即可完成数据恢复。
