数据库调优

主角：DBA

• 任务：创建数据库，创建schama，数据库的的输写和调用，数据库运维等，保证数据库刘畅的运行， 满足应用上的需求。可信性（需求上就满足），性能（调优过程中实现）
• 遇到的问题： 数据库的性能问题，因为业务的增长很快（越来越多用户）
• 触发点：像带宽问题上很容易解决，对于数据库就很复杂了。

基本步骤：

• 找到问题所在
• 权衡解决方案：
  • 增加内存、磁盘等，蛮临时的方案，但很方便
  • 修改sql的书写
• 方案实现
• 测试（确定其没有问题）
• 方案实施

性能问题的位置：

• 应用程序构造或查询输写的问题
  • （大部分原因）应用程序没有考虑到性能：在sql的输写方面，如一条查询，拆分成很多条，增加了与数据库的交互）
  • 有可能不怎么使用的应用程序，占用了大部分资源
• 数据库组件的瓶颈
  • 数据库内部性能问题：日志是不是刷的很厉害，锁管理：事务是否打架。
  • 有可能一个组件运行有问题，在另一个组件出现拥堵。实际上整个组件都是一个整体
• 硬件资源的瓶颈：
  • 硬件、设备、平台、部署的环境：网络带宽够不够大。

诊断点（常见的经验）：

• 关键查询是都被高校执行？ （即调用非常频繁的语句。）

  • 了解查询的执行过程，可以在日志中查看，分解开来看

• 系统组件是否有效的利用了硬件资源？

  • 对CPU、IO、硬盘应用是否已经得到资源极限
  • 锁管理器、日志管理器、缓冲区（硬盘上调用到内存上的）
    • 大量占用数据库资源，那么那个就出现问题

• 当发现table scan 直接从磁盘中读的太多（如50%跳过缓冲，到磁盘中读）

  • 缓冲区是否够大
  • 缓冲区是否被某个查询大量使用，导致运行效率太差

• 磁盘碎片：

  • 产生很多空洞（由于一直在改写数据库），导致页面访问性能够差；还有可能一个表被分到不同区域，很分散，导致输写蛮

• 锁管理器：

  • 锁表中管理锁，存在在内存中。当另一个事务，想要更新一个数据，先去锁表中查，是否有锁，如果有，则去locl pening list，当刚刚占用那个数据的结束了之后，会去唤醒那个事务。
  • 成熟的数据库，都有一个监控机制，告诉我们哪个锁 locks pending list很长；
  • 死锁检测：也可以查到。

• 硬件资源是否足够？

  • CPU/硬盘/内存
  • 通常使用操作系统的监视器进行诊断。

注：优化可能到一定地步优化不了了，负载还是很大