读《MySQL 性能调优与架构设计》笔记
文章目录
2014-06-09 更新
看完上边后又在看《高性能 MySQL》第三版 2013 年初版的，美国人写的，这本是MySQL的经典之作，比上边那本更好吧。就是内容详细，啥都有。详细的基准测试方法、特性细节（原理）、架构考虑，这几年 MySQL 升级的特性（如分区等），讲述的 MySQL 版本已经新到5.5，少许 5.6 前瞻。还有作者都是相关经验很多年的大拿。内容写的也不枯燥，很像那些编程方面的经典书的书写风格。
时间宝贵，推荐看《高性能 MySQL》这本就行了。
背景
这几天在 Review 公司项目 MySQL 这块的架构，网上 Google 出来的东西大多是皮毛，特别一些中文站点里的有些还明显有些错误。
之前看《HTTP 权威指南》的甜头还在（加上有些积累现在看技术书速度也快了），所以赶紧找些质量高的 MySQL 方面的书看，找到一本阿里人写的《MySQL 性能调优与架构设计》，Fenng 也有做序推荐。
正文部分为阅读笔记。
硬件关键指标
下边列出是常见性能指标，具体指标的取舍也要看具体应用场景。具体设计时再回头参考书里里讲的例子。
- IO 性能高的部件主要由磁盘和内存，各种与 IO 相关的板卡相关。 IO 性能分为和 IOPS（每秒可提供的 IO 访问次数）和每秒的 IO 总流量（IO 吞吐量）。
- CPU（SQL parse 和优化），并发高的时候 CPU 每秒需要处理的请求就高，相应 CPU 处理能力需要比较强劲。
- 网络设备
性能优化
商业需求合理化
书里例子：实时更新一个论坛帖子总量的统计。
select count(*) 语句简单，但是 InnoDB 引擎还是耗时间。而这个需求的强实时更新没多少用户真正关心这个。定时更新可提高很大的性能。
这条自己已经知道了。
系统架构最优化
- 有几类数据不适合存到数据库中：
- 二进制多媒体数据（图片、音频、视频等），这类数据对数据库空间资源耗费非常严重，且这些数据的数据存储很消耗数据库主机的 CPU 资源。
- 流水队列数据，支持事务的存储引擎为了事务安全性和可恢复性，需要记录所有变更的日志信息，而流水队列数据会不断的被 INSERTUPDATEDELETE，导致日志量很大。使用成熟的第三方队列软件处理，性能将会成倍提升。
- 超大文本数据，从 5.0.3 开始，VARCHAR，实际数据小于 255 字节时，实际存储空间和实际数据长度一样，可一旦长度超过 255 字节之后，所占用存储空间是实际数据长度的两倍。不光性能低下，还是浪费空间。
- 是否合理利用了应用层的 Cache。
- 数据层的存取实现都是最精简的吗。在程序里不要过度依赖面向对象思想。
- 过度依赖数据库 SQL 语句的功能造成数据库操作效率低下。 尽量减少与 MySQL 的交互次数和 SQL 复杂度。不要对可扩展性过度追求，导致系统设计时开分太离散，导致需要大量 JOIN 语句。
- 重复执行相同的 SQL 造成资源浪费。
逻辑实现精简化
硬件设施理性化
合理利用锁机制来优化 MySQL
Query 优化
主要优化思路和原则：
- 优化更需要优化的 Query。
- 定位优化对象的性能瓶颈。
- 明确的优化目标。
- 从 explain 入手。
- 多使用 profile。
- 永远用小结果集驱动大的结果集。
- 尽可能在索引中完成排序。
- 只取出自己需要的 columns。
- 仅仅使用最有效的过滤条件。
- 尽可能避免复杂的 JOIN 和子查询。
Schema 设计的性能优化
- 高校的模型设计
- 不一定要追求范式。
- 适度冗余——让 Query 尽量减少 JOIN。
- 大字段垂直分拆。字段特别大，访问频率又很低的字段拆出去。因为记录存储是一条一条的存放，查询某些数据时，也会读取到这个访问不高的大字段，比较浪费 IO 资源。
- 大表水平分拆——基于类型的分拆优化。把少量访问频率极高的记录水平拆分出去。例如论坛里的置顶帖子从普通讨论贴里分拆出去为单独的表。
- 统计表——准实时优化 。
- 合适的数据类型
选择更小的数据类型，可以降低 IO 消耗。另外不同数据类型的 CPU 处理方式也不一样。例如通过整数类型代替浮点数或者字符类型。 - 规范的对象命名
这条对性能没啥影响，但是对数据库的维护影响非常大。库的字段越来越多……
MySQL Server 性能优化
存储引擎优化
架构设计
- 可扩展设计的基本原则
- MySQL Replication
- 数据切分
水平切分和垂直切分，之前项目里做架构时已基本了解。 - Cache和 Search 的利用
Cache就是 Memcache 之类的。Search 主要用来做全文检索。 - MySQL Cluster
- 高可用设计之思路及方案
- 高可用设计之 MySQL 监控
