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