第07章-MySQL高级特性 7.1 分区表 一个表最多只有1024个分区
分区表达式必须是整数，或者返回整数的形式
分区字段中有主键或唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
分区表中无法使用外键约束
7.1.1 分区表的原理 7.1.2 分区表的类型 MySQL支持多种分区表。我们看到最多的是根据范围进行分区：
1 2 3 4 5 6 7 8 createtablesales(order_datedatetimenotnull,)engine=innodbpartitionbyrange(year(order_date))(paritionp_2010valueslessthan(2010),paritionp_2010valueslessthan(2011),paritionp_2010valueslessthan(2012),paritionp_catchallvalueslessthanmaxvalue); MySQL还支持键值、哈希和列表分区
7.1.3 如何使用分区表 两个策略：
全量扫描数据，不要任何索引 索引数据，并分离热点 7.1.4 什么情况下会出问题 NULL值会使分区过滤无效 第一个分区是一个特殊分区，存放分区计算为NULL的值 分区列和索引列不匹配 如果定义的索引列和分区列不匹配，会导致查询无法进行分区过滤 选择分区的成本可能很高 可通过限制分区数量来缓解此问题 键分区和哈希分区没有这样的问题 打开并锁住所有底层表的成本可能很高 当查询访问分区表的时候，MySQL需要打开并锁住所有底层表，这是分区表的另一个开销。这个操作在分区过滤之前发生，所以无法通过分区过滤降低此开销，并且此开销也和分区类型无关，会影响所有的查询。 维护分区的成本可能很高 7.1.5 查询优化 分区的最大优点就是优化器可以根据分区函数来过滤一些分区
对于访问分区表来说，很重要的一点是要在where条件中带入分区列
7.1.6 合并表 7.2 视图 视图本身是一个虚拟表，不存放任何数据
不能对视图创建触发器，不能使用drop table命令删除视图
视图的两种实现：
合并算法 临时表算法 如果视图中包含group by、distinct、任何聚合函数、union、子查询等，只要无法在原表记录和视图记录之中建立一一映射的场景，MySQL都将使用临时表算法来实现视图。具体的可以使用explain，查看select_type是不是derived来确定。...
第08章-优化服务器设置 8.1 MySQL配置的工作原理 配置文件位置
which mysqld
8.1.1 语法、作用域、动态性 8.1.2 设置变量的副作用 即使非常小的排序操作，排序缓存也会分配全部大小的内存 （震惊）
可以这么做：
1 2 3 set@@session.sort_buffer_size:=<value>;-- 业务sql set@@session.sort_buffer_size:=DEFAULT; 8.1.3 入门 在改配置之前，应该优化查询和schema
用户高峰和低谷对配置的影响
8.1.4 通过基准测试迭代优化 控制变量法
8.2 什么不该做 8.3 创建MySQL配置文件 数据的位置：/var/lib/mysql
InnoDB基础配置
设置缓冲池大小的方法：
从服务器内存总量开始 减去系统的内存占用 减去其他程序的占用 减去MySQL自身需要的内存，例如为每个查询操作分配的一些缓冲 减去足够让操作系统缓冲InnoDB日志文件的内存，至少是足够缓冲最近经常访问的部分。留一些内存至少可以缓冲二进制日志的最后一部分。 减去其他配置的MySQL缓冲和缓存需要的内存 除以105%，这差不多接近InnoDB管理缓存池增加的自身管理开销（？？？） 四舍五入，向下取整 一个192GB内存的例子
建议：当配置缓存区时，宁可小一点，也不大一点。小了只是影响效率，而大了可能会导致内存交换、磁盘抖动、内存耗尽和硬件死机
open_files_limit
8.3.1 检查MySQL服务器状态变量 8.4 配置内存的使用 8.4.1 MySQL可以使用多少内存 系统的glibc库也可能限制每次分配的内存大小
8.4.2 每个连接需要的内存 MySQL保持一个连接只需要少量的线程
知道高峰期MySQL消耗多少内存是非常有用的
8.4.3 为操作系统保留内存 8.4.4 为缓存分配内存 InnoDB缓冲池 InnoDB日志文件和MyISAM数据的操作系统缓存 MyISAM键缓存 查询缓存 无法手工配置的缓存，例如二进制日志和表定义文件的操作系统缓存 8....
9.1 什么限制了MySQL的性能？ 9.2 如何为MySQL选择CPU？ 9.2.1 哪个更好：更快的CPU还是更多的CPU 9.2.2 CPU架构 9.2.3 扩展到多个CPU核心 两种类型的数据库并发问题：
逻辑并发问题：应用程序可以看到资源的竞争，如表或行锁的争用 内部并发问题：信号量，访问InnoDB缓冲池页面的资源争用，等等 频率调整
boost技术
9.3 平衡内存和磁盘资源 9.3.1 随机IO和顺序IO 9.3.2 缓存，读和写 缓存的好处：
多次写入，一次刷新（刷盘） IO合并 9.3.3 工作集是什么 工作集的大小取决于应用程序
工作集可以定义为基于时间的百分比。
对于读取的某一行，InnoDB读取它所在的整个页，这会有额外的内存开销。
9.3.4 找到有效的内存/磁盘比例 缓存命中率实际上也会决定是用来多少CPU，所以评估缓存命中率的最好方法是查看CPU使用率。 如果CPU使用了99%的时间工作，用了1%的时间等待IO，那缓存的命中率还是不错的。
9.3.5 选择硬盘 例如，若需要快速写日志，就不能通过增加大量有效内存来避免磁盘写入。这种情况下，投资一个高性能的IO系统与带电池支持的写缓存或固态存储，可能是个更好的主意。
磁盘选取因素：
存储容量 传输速度 访问时间 主轴转速 物理尺寸 复制通常在更快的驱动器上表现得更好，因为备库的更新是单线程的。
9.4 固态存储 9.4.8 使用flashcache 9.5 为备库选择硬件 备库硬件主要考虑的是成本：需要在备库硬件上花费跟主库一样多的成本吗？可以把备库配置得不一样以便从备库上获得更多性能吗？如果备库跟主库工作负载不一样，可以从不一样的硬件配置上获得隐含的收益吗？这一切取决于备库是否只是备用。
9.6 RAID性能优化 9.7 SAN和NAS 9.8 使用多磁盘卷 9.9 网络配置 9.10 选择操作系统 9.11 选择文件系统 9.12 选择磁盘队列调度策略 9....