数据库调优-慢查询发现与分析：数据库调优的维度

调优金字塔

参考：千金良方：MySQL性能优化金字塔法则，这本书提出的，它认为调优的成本由下往上越来越高，而效果由上往下越来越好，因此我们应该在比较低的维度调优，也能做到更好的投入产出比；

业务需求

• 不合理的需求，可能会造成很多问题，而且有些问题还是很难解决的
  • 例子：比如说一个账目列表，它要求这个列表必须展示每套账目的各种汇总信息，比如说同比增长、环比增长等，而且这个结果一定要精确展示，导致我们必须N张表联合查询，还不允许分页，必须展示当前登录的会计所管理的所有的账，这样的查询语句是很慢的
  • 存储过程优化：使用存储过程实现相同的业务逻辑，能相对的提升一点查询速度；
    • 为什么存储过程能提速？
      • 存储过程在创建的时候编译就可以了，而SQL每次执行都需要被数据库编译
      • 存储过程可以降低网络开销，像上面的业务，如果使用Java代码，需要把SQL发送给数据库，而存储过程本身就是存储在服务器端的，在调用的时候，只需要直接使用CALL语句直接传入参数就可以了，因此会节省一些网络
  • 业务层面优化：不直接在列表页展示汇总信息，同比增长、环比增长就不显示了，如果想要查看汇总信息，可以点击列表上的详情按钮，再去看汇总信息，这样做之后列表页的SQL能做到大幅度的简化，性能也能得到大幅度的提升，而用户想要查看汇总信息的话，又变成了针对单个账目的查询，也是可控的

系统架构

• 做架构设计的时候，应充分考虑业务的实际情况，考虑好数据库的各种选择
  • 读写分离？高可用？实例个数？分库分表？用什么数据库？
    根据项目读的压力考虑要不要做读写分离
    根据项目的可用性需求考虑要不要为数据库实现高可用
    根据项目的并发量，创建合理数据库个数的实例，因为实例太多会资源浪费，实例太少又满足不了业务的需求
    根据数据量合理的分库分表
    一些业务场景下可能并不适合使用关系型数据库，使用非关系型数据库可能更加合适，还有的场景比较适合用缓存

SQL及索引

• 根据需求编写良好的SQL，并去创建足够高效的索引

表结构

• 设计良好的表结构

数据库参数设置（这个维度一般DBA比较关注）

• 设置合理的数据库性能参数
  • eg.join buffer、sort buffer...
    我们知道数据库有很多各种各样的性能参数，比如说MYSQL处理join的时候，有join buffer，处理排序的时候有sort buffer，如果buffer设置的非常离谱，对性能的影响还是比较大的

系统配置（这个维度一般运维和DBA比较关注）

• 操作系统提供了各种资源使用策略，设置合理的配置，以便于数据库充分利用资源
  • eg.swap -> swappiness
    Linux提供了swap，也就是交换区，并且提供了swappiness参数用来控制什么情况下使用swap，如果swappiness=0，操作系统将会在几乎没有内存的情况下才去使用swap；对于数据库，应该把swappiness设置的尽可能小，从而保证热点数据保留在物理内存

硬件

• 选用什么配置的机器？
  • 硬盘、内存、CPU、网卡等等的选择