3.  Mysql 运维优化

3.1. 存储引擎类型

• Myisam 速度快，响应快。表级锁是致命问题。
• Innodb 目前主流存储引擎
  • 行级锁
    • 务必注意影响结果集的定义是什么
    • 行级锁会带来更新的额外开销，但是通常情况下是值得的。
  • 事务提交
    • 对i/o效率提升的考虑
    • 对安全性的考虑
  • HEAP 内存引擎
    • 频繁更新和海量读取情况下仍会存在锁定状况

3.2. 内存使用考量

• 理论上，内存越大，越多数据读取发生在内存，效率越高
• 要考虑到现实的硬件资源和瓶颈分布
• 学会理解热点数据，并将热点数据尽可能内存化
  • 所谓热点数据，就是最多被访问的数据。
  • 通常数据库访问是不平均的，少数数据被频繁读写，而更多数据鲜有读写。
  • 学会制定不同的热点数据规则，并测算指标。
    • 热点数据规模，理论上，热点数据越少越好，这样可以更好的满足业务的增长趋势。
    • 响应满足度，对响应的满足率越高越好。
    • 比如依据最后更新时间，总访问量，回访次数等指标定义热点数据，并测算不同定义模式下的热点数据规模

3.3. 性能与安全性考量

• 数据提交方式
  • innodb_flush_log_at_trx_commit = 1 每次自动提交，安全性高，i/o压力大
  • innodb_flush_log_at_trx_commit = 2每秒自动提交，安全性略有影响，i/o承载强。
• 日志同步
  • Sync-binlog =1 每条自动更新，安全性高，i/o压力大
  • Sync-binlog = 0 根据缓存设置情况自动更新，存在丢失数据和同步延迟风险，i/o承载力强。
• 性能与安全本身存在相悖的情况，需要在业务诉求层面决定取舍
  • 学会区分什么场合侧重性能，什么场合侧重安全
  • 学会将不同安全等级的数据库用不同策略管理

3.4. 存储压力优化

• 顺序读写性能远高于随机读写
• 日志类数据可以使用顺序读写方式进行
• 将顺序写数据和随机读写数据分成不同的物理磁盘，有助于i/o压力的疏解，前提是，你确信你的i/o压力主要来自于可顺序写操作（因随机读写干扰导致不能顺序写，但是确实可以用顺序写方式进行的i/o操作）。

3.5. 运维监控体系

• 系统监控
  • 服务器资源监控
    • Cpu, 内存，硬盘空间，i/o压力
    • 设置阈值报警
  • 服务器流量监控
    • 外网流量，内网流量
    • 设置阈值报警
  • 连接状态监控
    • Show processlist 设置阈值，每分钟监测，超过阈值记录
  • 应用监控
    • 慢查询监控
      • 慢查询日志
      • 如果存在多台数据库服务器，应有汇总查阅机制。
    • 请求错误监控
      • 高频繁应用中，会出现偶发性数据库连接错误或执行错误，将错误信息记录到日志，查看每日的比例变化。
      • 偶发性错误，如果数量极少，可以不用处理，但是需时常监控其趋势。
      • 会存在恶意输入内容，输入边界限定缺乏导致执行出错，需基于此防止恶意入侵探测行为。
    • 微慢查询监控
      • 高并发环境里，超过01秒的查询请求都应该关注一下。
    • 频繁度监控
      • 写操作，基于binlog，定期分析。
      • 读操作，在前端db封装代码中增加抽样日志，并输出执行时间。
      • 分析请求频繁度是开发架构 进一步优化的基础
      • 最好的优化就是减少请求次数！
    • 总结：
      • 监控与数据分析是一切优化的基础。
      • 没有运营数据监测就不要妄谈优化！
      • 监控要注意不要产生太多额外的负载，不要因监控带来太多额外系统开销