数据库优化，都优化些什么

Posted 2021-07-19 白鳝的洞穴

数据库优化是很多企业都在做的事情，很多人觉得数据库优化很难，做起来没有把握，请第三方的服务团队来做似乎短期效果很好，不过时间长了还是觉得效果没有那么好。其实数据库优化的工作方式有很多种，包括专题性优化、集中式优化、常态化优化等。这些优化形式可以解决不同的问题。

专题性优化是企业遇到了某个或者某些比较典型的性能问题，需要专家协助，消除相关问题瓶颈，这种优化方如果自己的技术人员能够完成，则自行解决；如果自己的人解决不了，需要专业的专家才行，那么花一定的经费，请相关专家来协助解决是最好的方法。

集中式优化是我们具体也不清楚系统的主要问题在哪，如何才能解决这些问题，那么我们就需要请专业的系统优化团队对系统进行整体检查，找出系统中存在的关键性问题，然后逐一提出优化方案，把能做的优化尽可能都完成。这种优化中包含了配置优化、存储优化、网络优化、OS优化、SQL优化、应用架构优化、中间件配置优化等多个方面，很多企业把这种优化做成了纯粹的SQL优化，实际上也是不合适的。

常态化优化是企业日常需要做的工作，实际上绝大多数企业并未开展这项工作，日常运行中系统出现一些问题，只要还没有严重影响业务，业务部门能够忍受的时候，是不会去考虑做优化的。很多系统问题就在这种情况下越积累越多，最终大爆发，逼的没办法了，才找专业团队来做优化。常态化优化工作应该成为企业中的一个日常工作，看看系统的容量空间等是否存在问题，IO延时是否正常，索引和表的碎片是不是需要整理了，历史数据是不是可以做一下归档，OS的各项资源使用情况是否合理，是不是有一些SQL语句开销过大，能不能让开发商去优化优化。如果企业有专职的DBA，那么这一切工作其实是可以在企业的日常工作中开展起来的。可能有些朋友觉得这项工作难度太大，自己的DBA可能没有这个能力，也许是的，不过培养这种基础能力实际上并不难，只要试着做一做，很快那些领导觉得水平不够高的DBA也很快就能掌握了。

上面我用思维导图简单的花了一张数据库优化的概要工作内容图。其实数据库优化也不神秘，大体上做好四个方面的优化，数据库就可以比较高效的运行了。

合规性检查是数据库上线前的一次性工作，也是很多企业忽视的一个问题。系统还没有正是上线或者在试运行阶段，其实很多检查规则还不是个性化的。我们可以采取一种略微僵化的规范来规定数据库安装部署，参数配置的规范，根据这个规范来严格审核某个此阶段系统中的数据库。如果不满足合规性的要求就不可以上线。这个规定中，哪怕规范僵化一些，并不配置优化，是最优的也不怕，有了这层保障，可以减少90%以上数据库上线后的配置问题。

因为合规性检查是做一个略微僵化的规范性检查，因此某些配置并不一定是最优的。最优的配置需要在系统运行过程中不断地去发现地。因此系统运行地一定阶段，比如几个月后，一年后，三年后等时间节点上，都需要根据系统实际地运行情况、数据量增长、业务增长、负载情况、并发情况等，对系统地配置进行多次优化调整。

对象优化是确保数据库系统长期稳定运行的十分关键的优化工作。总体目标是让数据量的增长尽可能少的影响数据库的性能。具体的手段是通过数据库大表分区、碎片整理、历史数据归档、索引重建、索引整体优化等方式优化数据库对象的结构，从而避免数据量增长导致的性能问题。

SQL优化是数据库优化中永恒的问题，也是很多企业数据库运维团队觉得如从入手的部分。实际上大多数数据库运维团队都具备发现TOP SQL的能力，很多数据库都有相关的工具能够帮助我们抓取到TOP SQL。但是我们如果把发现的TOP SQL发给研发团队，研发团队一句“我们分析过了，这SQL没法再优化了”，就可以让我们无能为力。确实是的，SQL优化需要对SQL访问的数据逻辑的理解与对优化器的理解，普通的DBA可能无能为力。不过如果DBA能够读懂SQL的执行计划，知道某条SQL执行的逻辑，那么一些复杂SQL的优化工作也是可以做一做了。你可以把这条SQL在数据库中的执行逻辑整理出来，交给开发人员，让开发人员确认执行逻辑是不是合理的，如果不合理再去想办法解决。似乎这条路走得通，不过实际工作中阻力会不小，首先开发部门不一定会配合，其次DBA要弄清楚SQL执行逻辑，也需要一定的专业技能。在一些大企业中，有开发DBA专门协助开发人员解决SQL性能问题，那么运维DBA只需要把TOP SQL的执行计划采集好交给研发部门就可以了。如果企业中没有这样的人员，那么找专业团队来干可能是最佳的方案。

数据库优化实际上也分为伪需求和真需求，如果企业用户真实的感受系统的性能问题，而且不解决就已经影响了企业的业务，那么这种优化需求是真实的，性能问题也是必须解决的，这种情况下，数据库优化的工作效果会比较好。而有一些为了优化而优化的工作，大多数情况下就会劳民伤财，一无所得了。