31.查询改写
据库中的查询改写(query rewrite)把一个 SQL 改写成另外一个更加容易优化 的 S Q L 。
n 基于规则的查询改写总是会把 SQL 往“好”的方向进行改写，从而增加该 SQL的优化空间
n 基于规则的查询改写并不能总是把 SQL 往“好”的方向进行改写，所以需要代价模型来判断
n 基于代价的改写之后可能又会重新触发基于规则的改写，所以整体上采用 迭代式的方式进行改写
32.
n 单表分区个数最大8192
n 单机partition支持上限: 8万(推荐不超过3万)
33.OceanBase分区表特点
n 可多机扩展
n 提高可管理性
n 提高性能
n 自动负载均衡、自动容灾
n 对业务透明，可以取代“分库分表”方案
n 支持分区间并行
n 单表分区个数最大8192
n 单机partition支持上限: 8万(推荐不超过3万)
34.
OB MySQL模式的Hash分区限制和要求:
l 分区表达式的结果必须是int类型。
l 不能写向量，例如partition by hash(c1, c2)
35.
目前提供对range分区的分区操作功能，能add/drop分区 存在maxvalue的分区的情况，由于add分区现在只能加在最后，所以会添加分区失败。 不存在maxvalue的分区的情况，当插入的数据超出当前分区的最大值，则会插入失败。
36.
对于 RANGE 分区的分区操作 add/drop，必须是 RANGE 分区做为一级分区的方式。所以强烈建议用 RANGE + HASH 的分区方式，而不是 HASH + RANGE。
只有range分区，可以删除任意一个一级range分区
只能以append方式往后添加分区，也就是说，新加分区的range value总是最大的
37.
分区键必须是主键的子集
如果是分区表的唯一索引，则唯一索引必须包含表分区的拆分键。
38.
n 局部索引 局部索引又名分区索引，创建索引的分区关键字是LOCAL，分区键等同于表的分区键，分区数等同于表的分区数，总之，局部索引的分区机制和表的分区机制一样
全局索引的创建规则是在索引属性中指定GLOBAL关键字，与局部索引相比，全局索引最大的特点是全局索引的分区规则
跟表分区是相互独立的，全局索引允许指定自己的分区规则和分区个数，不一定需要跟表分区规则保持一致
全局非分区索引(Global Non-Partitioned Index)
全局分区索引(Global Partitioned Index)
39.
在表的’分区键无关’的字段上建唯一索引
局部索引在“索引键没有包含主表所有的分区键字段”的情况下，此时索引键值对应的索引数据在所有分区中都可能存在。 如下图，employee按照emp_id做了分区，但同时想利用局部索引建立关于emp_name的唯一约束是无法实现的。由于某索引键值在所有分区的局部索引上都可能存在，索引扫描必须在所有的分区上都做一遍，以免造成数据遗漏。这会导 致索引扫描效率低下，并且会在全局范围内造成CPU和IO资源的浪费
40.
全局索引的分区键一定是索引键的前缀
全局非分区索引 :
此时索引的结构和“非分区”表没有区别，只有一个完整的索引树，自然保证唯一性。
并且只有一个完整的索引树，自然没有多分区扫描的问题
全局分区索引 :
数据只可能落在一个固定的索引分区中，因此每个索引分区内保证唯一性约束，就能在全表范围内保证唯一性约束
全局索引能保证某一个索引键的数据只落在一个固定的索引分区中 ，所以无论是针对固定键值的索引扫描，还是针对 一个键值范围的索引扫描，都可以直接定位出需要扫描的一个或者几个分区
如果查询条件里“包含完整的分区键”，使用本地索引是最高效的
如果需要“不包含完整分区键”的唯一约束:用全局索引 或者本地索引，且需要索引列上必须带上表的分区键
其它情况，case by case:
通常来说，全局索引能为高频且精准命中的查询(比如单记录查询)提速并减少IO;
对范围查询则不一定哪种索引效果更好
不能忽视全局索引在DML语句中引入的额外开销:数据更新时带来的跨机分布式事务，事务的数据量越大则分布式事务越复杂
如果数据量较大，或者容易出现索引热点，可考虑创建全局分区索引
本地索引，比如适合索引字段包含主表所有分区字段的的情况。
