Warm Up
上来先放五个在社区论坛中常见的和分区相关的小问题，难度依次递增。看看你能回答哪几个？
- 为什么分区能让查询变快？
- 为什么主键必须包含全部分区键？
- 分区表应该优先考虑哪种分区方式？
- 如何进行手动分区分裂？
- 如何设置自动分区分裂？
边学边练，效果拔群
正所谓 “纸上得来终觉浅，实践才能出真知”，强烈推荐大家点击下面的链接，根据在线体验页面左边的实验文档，亲手体验一把分区带来的性能提升，以及自动分区分裂带来的易用性。
-
在线实验地址：《OceanBase 自动分区分裂》。
-
这个实验需要先执行两条命令，完成环境准备，然后再通过实验文档里的连接串，连接目标机器。
这次的在线体验实验，是自动分区分裂的研发同学凭舟专门为这期课程设计的。感谢凭舟！
-
-
或者直接通过
obclient -h0.0.0.0 -P2883 -uroot@sys -A -Dtest连接 sys 租户去搞些你更感兴趣的东西。说明：
因为是实验环境，所以可以偷懒使用 sys 租户。
但生产环境中尽量不要在 sys 租户里直接创建数据库对象，尽量在用户租户里进行相关操作。
-
课后小测地址：【DBA 实战营】OceanBase 自动分区分裂。
- 大家完成课后小测，并在小测中上传实验截图，判卷通过后就会自动获取 10 积分，并自动获得抽奖资格。有机会获得实体礼物或高额积分奖励。
小提示：
- 需要先登录 OceanBase 账号，才能初始化屏幕右边的实验环境进行实验。
- 在实验环境里，干什么都可以。大家不要受限于屏幕左边的实验手册，可以天马行空地做一些你感兴趣的事情，或者验证一些你对 OceanBase 官网文档的疑问、以及自己的猜想等等（甚至可以尝试怎么搞能把这个实验环境里的 OBServer 给弄崩）。
- 欢迎大家平时在学习 OceanBase 的过程中，也都能充分利用在线体验页面为您提供的一些实验环境，来体验 OceanBase 中您感兴趣的新特性。
大家如果都不来做实验的话，老板以后就不会再让兹拉坦更新这些教程文档了。大家的对在线实验的支持，是兹拉坦的老板让兹拉坦更新这些教程内容的动力！
闲言少叙，正文开始。
OceanBase 分区的前置知识点
对于这部分内容，大家可以选择性地进行阅读。
为什么分区能让查询变快？
在 OceanBase 社区论坛中，一个很常见的用户问题问题：“按日期分区是否能达到让查询变快的目的？”
个人理解，分区除了可以让一张超级大表的数据比较均衡地负载在不同的数据库节点上，另外一个目的就是加速查询。因为查询时会利用过滤条件里面的分区键进行分区裁剪。
例如下面这两个例子：
- 如果过滤条件里有分区键，计划中可以看到 partitions(p0)，说明只扫描了 p0 这一个分区的数据。
- 如果过滤条件里没有分区键，计划中可以看到 partitions(p[0-1])，说明扫描了 p0 和 p1 全部所有分区的数据。其中 PX PARTITION ITERATOR 算子就是用来循环扫描所有分区的迭代器。
为什么主键必须包含全部分区键？
很多社区用户会问：“有一张订单流水表，数据很大，想考虑按年份对数据进行分区。现在只有 ID 列是主键。尝试了一下好像无法按日期进行分区。是必须要把日期做成和 ID 的联合主键才可以分区么？”
答案是对的，主键必须包含所有分区键。
因为主键的唯一性检查是在各个分区内部进行的，如果主键不包含全部分区键，这个检查就会失效。所以 MySQL 及其他数据库，一般情况下，也都会有这个要求。
-- 如果主键不包含全部分区键，建表就会失败报错，报错信息也挺明确的。
create table t1(c1 int,
c2 int,
c3 int,
primary key (c1))
partition by range (c2)
(partition p1 values less than(3),
partition p1 values less than(6));
ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function
说明：
对于这个限制，前一阵儿还有一位数据库界的 KOL 老师认为上面的写法过于绝对了，尝试举出反例，最后终于找到一个叫 pg_pathman 的第三方 pg 插件。
这类第三方插件为了提升设置分区的灵活性，不要求分区键是主键或者唯一键的子集，但往往也会导致数据库中的主键和唯一键都不再保证唯一性，进而可能引入比较严重的正确性问题。不过终究也算是打破了这个限制。
最后在上面那段话中，又加入了 “一般情况下” 这几个字。
下面举个例子解释下原因：
- 我们创建了一张表，主键是 c1 和 c2，分区键是 c2，小于 3 的值在 p0 分区，大于等于 3 且小于 6 的值在 p1 分区。然后插入了两个行，第一行在 p0 分区，第二行在 p1 分区。
create table t1(c1 int,
c2 int,
c3 int,
primary key (c1, c2))
partition by range (c2)
(partition p0 values less than(3),
partition p1 values less than(6));
Query OK, 0 rows affected (0.146 sec)
obclient [test]> insert into t1 values(1, 2, 3);
Query OK, 1 row affected (0.032 sec)
obclient [test]> insert into t1 values(1, 5, 3);
Query OK, 1 row affected (0.032 sec)
obclient [test]> select * from t1;
+----+----+------+
| c1 | c2 | c3 |
+----+----+------+
| 1 | 2 | 3 |
| 1 | 5 | 3 |
+----+----+------+
2 rows in set (0.032 sec)
- 如果主键只有 c1 而没有 c2，那么在 p0 和 p1 分区内对 c1 列的唯一性检测都会成功，因为在各个分区内 c1 列的值都不重复（每个分区都只有一行数据，在分区内自然不会重复），然后就会判定插入的数据符合主键约束。
obclient [test]> select * from t1 PARTITION(p0);
+----+----+------+
| c1 | c2 | c3 |
+----+----+------+
| 1 | 2 | 3 |
+----+----+------+
1 row in set (0.033 sec)
obclient [test]> select * from t1 PARTITION(p1);
+----+----+------+
| c1 | c2 | c3 |
+----+----+------+
| 1 | 5 | 3 |
+----+----+------+
1 row in set (0.034 sec)
- 但实际上在分区间会有重复值 c1 = 1，数据并不符合主键约束（主键只有 c1 列），所以所有数据库在分区时，都要求主键包含全部分区键。
分区表应该优先考虑哪种分区方式？
分布式数据库的优势在于对于空间问题和请求访问问题分而治之。针对每个分区的访问，由该分区所在的节点响应即可。 即使该 SQL 并发很高，由于访问的是不同的分区，分别由不同的节点提供服务。每个节点自身也有一定能力满足一定的 QPS，所有节点集中在一起就能提供更大的 QPS。这个时候如果扩容节点数量，该 SQL 总的 QPS 也能获得相应的提升，这是分布式数据库里最好的情形。
分区的目标是将大量数据和访问请求均匀分布在多个节点上，一是想充分利用资源进行并行计算，消除查询热点问题；二是想利用分区裁剪来提升查询效率。 如果每个节点均匀承担数据和请求，那么理论上 10 个节点就应该能承担 10 倍于单节点的数据量和访问量。然而如果分区是不均匀的，一些分区的数据量或者请求量会相对比较高，出现数据偏斜（skew），这个可能导致节点资源利用率和负载也不均衡。偏斜集中的数据我们又称为热点数据。避免热点数据的直接方法就是数据存储时随机分配（没有规则）给节点，缺点是读取的时候不知道去哪个分区找该记录，只有扫描所有分区了，所以这个方法意义不大。实际常用的分区策略都是有一定的规则。
用户必须在业务查询条件明确的情况下，根据真实业务场景进行分区规划，不要在场景不明确的情况下随意进行分区规则。 在规划分区时，建议尽量保证各个分区的数据量相对均衡。
最常用的三种分区方式如下：
- HASH 分区：一般适用于分区列 NDV（不同值的种类）较大，且难以划分出明确范围的情况。优点是容易让没有特定规则的数据也能够在不同的分区内均匀分布，缺点是在范围查询时难以进行分区裁剪。
- RANGE 分区：一般适用于分区键容易划分出明确的范围的情况，例如可以把记录流水信息的大表，根据表示信息时间的列做 RANGE 分区。
- LIST 分区：一般适用于需要显式控制各行数据如何映射到具体的某一个分区时，优点是可以对无序或无关的数据集进行精准分区，缺点是在范围查询时难以进行分区裁剪。
为了更好地支持并行计算和分区裁剪，OceanBase 还支持二级分区。OceanBase 数据库 MySQL 模式目前支持 HASH 、RANGE 、LIST 、KEY 、RANGE COLUMNS 和 LIST COLUMNS 六种分区类型，二级分区为任意两种分区类型的组合。
例如在用户账单领域，数据库往往需要按照 user_id 做 HASH 一级分区，然后再在各个一级分区内部，继续按照账单创建时间做 RANGE 二级分区。
尽管 OceanBase 数据库在组合分区上支持 RANGE + HASH 和 HASH + RANGE 两种组合，但是对于 RANGE 分区的分区操作 add / drop，必须是 RANGE 分区做为一级分区的方式。所以针对例如数据量较大的流水表，为了维护方便（新增和删除分区），建议使用 RANGE + HASH 组合方式（时间列 range 一级分区 + 业务列 hash 二级分区）。
总结一下：
- 分区优先考虑用时间列 range 一级分区 + 业务 hash 二级分区。
- 否则要根据数据聚集维度和常用查询语句来设计分区。
参考自 OceanBase 社区公众号 “老纪的技术唠嗑局” 中的一篇文章 《OceanBase PoC 经验总结（二）—— AP 业务》，欢迎扫码关注~
如何进行手动分区分裂？
这期课程主要是讲自动分区分裂，这里顺带也提一下手动分区分裂。
OceanBase 数据库支持在分区表中手动进行分区分裂（REORGANIZE）操作，即将一个已有的分区拆分为多个分区。这个功能可以指定需要分裂的分区和新分区的分裂位点进行手动执行分区分裂命令，根据需求和数据增长情况对分区进行调整。
OceanBase 当前（4.4.0 及以下版本）仅支持对 Range / Range Columns 分区的一级分区表进行手动分区分裂操作。
示例：
- 创建 Range 分区的一级分区表
test_tbl1。
CREATE TABLE test_tbl1(col1 INT, col2 INT, PRIMARY KEY(col1))
PARTITION BY RANGE(col1)
(PARTITION p0 VALUES LESS THAN(100),
PARTITION p1 VALUES LESS THAN(200),
PARTITION p2 VALUES LESS THAN(300),
PARTITION p_max VALUES LESS THAN (MAXVALUE));
- 把
test_tbl1表的分区p0分裂成三个新的分区，分裂的位置是在30和60这两个值所对应的行上。分裂后，原来的分区p0被分成三个新的分区p0_1、p0_2和p0。
ALTER TABLE test_tbl1
REORGANIZE PARTITION p0 INTO (
PARTITION p0_1 VALUES LESS THAN (30),
PARTITION p0_2 VALUES LESS THAN (60),
PARTITION p0 VALUES LESS THAN (100));
- 把
test_tbl1表的分区p_max分裂成三个新的分区，分裂的位置是在400和500这两个值所对应的行上。分裂后，原来的分区p_max被分成三个新的分区p_max_1、p_max_2和p_max_3。
ALTER TABLE test_tbl1
REORGANIZE PARTITION p_max INTO (
PARTITION p_max_1 VALUES LESS THAN (400),
PARTITION p_max_2 VALUES LESS THAN (500),
PARTITION p_max_3 VALUES LESS THAN (MAXVALUE));
- 查看表
test_tbl1的结构和定义。
SHOW CREATE TABLE test_tbl1 \G
返回结果如下：
*************************** 1. row ***************************
Table: test_tbl1
Create Table: CREATE TABLE `test_tbl1` (
`col1` int(11) NOT NULL,
`col2` int(11) DEFAULT NULL,
PRIMARY KEY (`col1`)
) ORGANIZATION INDEX DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC
partition by range(col1)
(partition `p0_1` values less than (30),
partition `p0_2` values less than (60),
partition `p0` values less than (100),
partition `p1` values less than (200),
partition `p2` values less than (300),
partition `p_max_1` values less than (400),
partition `p_max_2` values less than (500),
partition `p_max_3` values less than (MAXVALUE))
1 row in set (0.003 sec)
自动分区分裂
以下内容，是自动分区分裂的研发负责人仓氐专门为这期课程写的。
感谢仓老师~
背景
随着数字化的发展，当今数据库的业务数据量很大，单表往往也能达到非常大的数据量规模。此时，使用单机数据库往往无法容纳过大体量的业务，需要使用分布式数据库的可扩展能力，将数据打散在多个节点进行承载，达到负载均衡的效果。
在 OceanBase 中，我们将表进行分区，按照分区粒度将数据划分到集群的不同节点上，来实现负载均衡的目标。但这依赖用户能设计比较好的分区规则才能更好地使用水平扩展能力，这不仅要求用户具备对各种分区方式有充分的理解，并且还要求用户对业务使用数据库的方式有深入的了解，甚至在有些场景中，采用手动分区很难达到各方面都比较优的效果。
自动分区分裂特性能自动地根据用户设定的分区阈值大小自动进行分区分裂，使得用户在对分区规划关注较少的前提下，也能用好 OceanBase 数据库的分布式能力。本篇文章将首先介绍手动分区存在的痛点问题，接着描述自动分区是如何解决手动分区这些问题的，最后我们将围绕自动分区功能，展开介绍它的特点，使用场景，使用方式以及限制等。
使用手动分区的痛点
分布式数据库负载均衡的目标是让各个节点的资源使用尽量达到均衡，要达到这个目标，就需要设计出合理的分区，使得分区间的资源占用比较适中，无论是分区多大或者分区过小都可能存在问题。分区过大可能存在负载不均衡，后台操作空间放大等问题，分区过小可能会导致元数据过多，性能不优等问题。
在自动分区发布之前，我们通常是手动设计分区规则，这个过程通常是比较困难的，我以一个抽象的业务场景为例来说明手动分区的痛点问题。
假设有一个系统，里面有一张表，它的主键是（公司 ID，员工 ID），现在将这个系统部署在 OceanBase 上，它上面当前有一条 SQL 查询，按照公司 ID，员工 ID 进行点查，客户对数据库的期望
- 希望能充分利用 OceanBase 的分布式的能力，将表的负载均衡
- 希望尽量让 SQL 的性能比较优
为了满足点查的 SQL 性能比较优的需求，很自然地想到基于（公司 ID，员工 ID）进行 Key 分区，Key 分区基本上能保证数据量均衡，并且，也能够高效地按照公司 ID，员工 ID 进行查询。
目前，业务的需求都得到了满足，我们来看看如果业务发生一些变化后，会出现什么情况？业务变化有两种，一种是业务的请求发生变化，另一种是业务的数据发生变化。我们先来看业务的 SQL 发生变化的场景。
业务请求发生变化
业务系统新增一个新的功能需求，它希望对每个公司的员工，进行按批处理，对应的 SQL 请求是一个范围扫描。如果在原来的 Key 分区上做范围扫描，会导致每个分区都参与范围扫描查询，特别是按批处理的场景如果每个批次数据量不大时，会带来比较多的 IO 放大和网络放大，SQL 的性能是不优的。
为了解决这个问题，一个解决办法就是按照 range (公司 ID，员工 ID）进行分区，但比较难以设置划分的分区的边界，因为运维人员或者开发人员很难知道每个公司的员工数量，也就比较难以进行均衡的划分。即使这个是老的业务，我们提前知道数据，我们可以手工统计目前数据的分布，划分出一些边界，但这也会有新的问题。随着业务的发展，每个公司可能在员工信息上会有变化，也就是业务数据变化，那么就可能存在新的问题。
业务数据发生变化
假如某些公司因业务发展需要，招聘并入职了大量员工，如果不做任何的处理，新入职的员工可能会分布在某个分区上，使得该分区的数据量远超其他分区，集群会重新变得不均衡。为了避免该问题，可能运维人员需要规划好新的机器，并提前创建好新的分区，以便新的分区能够负责新的数据，防止已有分区的数据量过大的问题，这给业务运维带来了复杂度。
总结下来，通过手动分区的方式，存在如下痛点：
- 负载均衡与 SQL 性能在部分业务场景可能难以兼顾，使用 Key 分区能够将负载打散，但对范围查询不够友好，使用 Range 分区又存在无法手动操作的可能性。
- 手动设计的分区规则只适用于当前的业务情况，如果业务发生变化，可能需要重新设计分区规则。
- 设计分区规则时，运维人员和开发人员需要做充分的沟通，确保业务中的 SQL 正确使用上了分区键，存在一定的沟通成本。
自动分区分裂如何解决问题
在讨论自动分区如何解决问题之前，我们先来简单的了解下 OceanBase 的自动分区的大致流程，在 OceanBase 中，当一个分区的数据量达到数据量阈值后，会自动地将数据按照主键或者主键前缀的 Range 进行一分为二，这里面有两个好处：
- 有了自动分区后，每个分区的数据量会维持在大小适中的状态，当每个分区的数据量都差不多时，对负载均衡比较友好。
- 自动分区是按照 Range 自动分区的，它既适合范围查询，也适合点查询。
如果使用自动分区，按照一定数据量阈值，进行自动拆分 range 分区，那么就能够解决上述需求。
- 业务的第一个需求是负载均衡，自动分区分裂能够按照数据量阈值大小进行分裂，有助于负载均衡模块达到更好的均衡效果；
- 业务的第二个需求是按照公司 ID，员工 ID 进行点查询，在 Range 分区下，进行一次分区裁剪就能定位到对应的分区，之后在对应的分区查询，效率是比较高的；
- 业务的第三个需求是对员工进行批处理查询，本质上主键的范围查询，在自动分区下通常只会查询其中某个分区，效率也是比较高的；
- 业务的第四个需求是已有分区的数据出现变化，此时达到数据量阈值后，会重新切分成大小适中的分区，达到动态均衡。
总体来看自动分区存在三个业务价值：
- 自动分区的能够满足不同工作模式下的负载的性能需求。自动分区采用主键或者主键前缀的 Range 分区方式，它能够很好地满足数据库中的范围和点查询的需求，并且能够避免手动 Range 分区无法找到合适切分点的问题。
- 自动分区能够满足分布式数据库的负载均衡需求，它会自动地按照数据量对分区进行分裂，在用户无须关注分区键的数据分布规则的前提下，自动生成数据量适合且均衡的分区，使得数据库内部更容易在机器间进行负载均衡。
- 自动分区能够轻松应对变化，当业务的数据分布发生了变化后或业务的数据量发生变化后，可能导致不同分区的数据不均衡，此时自动分区能够按照阈值重新分裂不均衡的分区，使得分区间重新均衡；当业务访问量发生变化，新增了机器后，可能导致机器间的不均衡，此时，自动分区已经切分好了多个大小适合的分区，可以将已有机器上的分区 transfer 到新加的机器上，使得机器间能够更加均衡。
自动分区能够很好地解决手动分区存在的痛点问题，在用户准备用 OceanBase 自动分区之前，通常会关注自动分区对业务的影响以及使用的便捷性等，我将通过对 OceanBase 自动分区的特点介绍，来解答用户关注的问题。
自动分区分裂的特点
OceanBase 自动分区具备三个特点：
- Online：不阻塞业务的普通 DML 和查询。
- 使用资源少：分裂过程中使用的资源量较少。
- 使用简单：只需要打开两个租户级的配置项，就能使用上自动分区分裂功能。
为了避免分裂对正常业务的影响，我们主要做了两方面的工作，一方面，当表上存在业务的普通 DML 和查询时，如果此时做自动分裂，会将查询和 DML 的流量自动转移到新分区继续处理，对正在执行的 DML 和查询的性能影响比较小；另一方面，我们做了一些优化使得分裂操作本身占用的资源比较少，包括重用大部分的数据、网络只同步逻辑操作等，充分节省了磁盘空间、带宽、网络带宽、CPU 和内存资源等。
我们在系统中只有一个分区的情况下，对这个分区进行分裂，模拟分裂带来影响最显著的场景，观察分裂对性能的影响。在面向 OLTP 场景的 sysbench 场景的测试，我们测试了点查，范围查和写入，性能影响在 4% ~ 8% 左右，参考下图。
实际生产环境中，分区数有很多个，同时在分裂的分区数只有一少部分，此时，分裂的影响会更小。
为了让用户方便的使用自动分区，我们对于一些场景，例如全局索引，HBase 等 KV 场景，默认放开了分裂，用户无须配置即可使用，对于其他场景，用户也只需要配置两个租户级的参数，即可使用上自动分裂。
使用场景
当前 OceanBase 在行存表模式下支持了自动分区分裂，所以，它适用于的业务场景主要是行存表所适用的业务场景，包括 KV 场景，例如 OB-HBase，以及 OLTP 场景。
KV 场景
在尚未支持的自动分区的 OceanBase 版本中，默认推荐的是按照 Key 方式进行预分区，分区数量一般设置数百到上千，这种使用方式通常能较好地将数据量进行打散，支持点查的负载，但对于范围扫描的负载不够友好，需要扫描所有的分区，同时 Key 分区的方式把新老数据打散了，不方便做分区级的数据管理。
由于 OceanBase 自动分区一期支持的自动 Range / Range Columns 分区，它继承了 Range 分区的优势之一，比较适合范围扫描的场景，同时它还有普通 Range 分区所不具有的自动按照数据量分裂的能力，将数据量打散。为了避免写热点，在自动分区下，尽量避免按照主键追加写入。如果业务上在读、写没有明显的按照主键范围的热点，那么即使业务负载都是点查，也能够使用自动分区将业务的负载打散。
自动扩展的 OLTP
在尚未支持自动分区的 OceanBase 版本中，如果为了更好地利用分布式集群的能力，用户需要结合业务规则设计相关的相关的分区，以便将数据量，业务负载打散到各个节点上。而支持自动分区后，我们可以默认对所有的表都是自动分裂的，用户在业务开始阶段就创建普通的非分区表，当业务体量增长时，由数据库本身自动的进行分区分裂，达到自动的负载均衡。
使用方法
使用入门
要使用自动分区功能，只需要关注两个配置项：
- enable_auto_split：租户级别配置项，控制这个租户是否开启自动分区功能，默认关闭。
- auto_split_tablet_size：租户级别配置项，控制这个租户开启自动分区功能之后触发分裂的阈值，默认值 2GB。
如果用户需要开启自动分区，并且内存资源足够，我们使用 ALTER SYSTEM SET enable_auto_split = true; 来打开自动分区。由于租户内存资源一般有限制，而我们支持的 tablet 数量跟租户内存大小有关，一般经验计算公式是 1GB 能分配 2W 个 tablet，所以，为了避免 tablet 数量过多，我们可以调整 auto_split_tablet_size 来避免因数据量太大而分配太多的 tablet。
进阶使用
通过租户级的配置使得用户能够很容易地将自动分区使用起来，但这种使用方式是将租户内所有的业务全部打开自动分区模式。在实际场景中，有可能使用灰度的方式，将业务慢慢地使用上自动分区功能，两个常见的场景：
- 用户的一个新集群或者新业务，打算上 OceanBase，先对部分表尝鲜自动分区功能，那么可以使用建表时是否开启自动分区来控制
-- 创建自动分区的非分区表（使用默认配置的 128MB 为分裂阈值)
CREATE TABLE auto_pt2 (c1 int, c2 int, primary key(c1));
PARTITION BY RANGE ();
-- 创建自动分区的非分区表（分裂阈值为 1024MB，使用用户配置)
CREATE TABLE auto_pt3 (c1 int, c2 int, primary key(c1))
PARTITION BY RANGE () SIZE('1024MB');
- 用户的原有的OceanBase集群，升级到支持自动分区的OceanBase版本，并想部分表试用自动分区功能，那么可以使用修改自动分区属性来控制
-- 业务从老版本 OceanBase 升级来的表 t1，未开启自动分区
CREATE TABLE t1 (C1 INT, C2 INT, PRIMARY KEY(C1))
PARTITION BY RANGE(C1) SIZE('10GB')
(PARTITION p0 VALUES LESS THAN(100),
PARTITION p1 VALUES LESS THAN(200),
PARTITION p_max VALUES LESS THAN (MAXVALUE)
);
-- 修改表 t1 为自动分区表
ALTER TABLE t1 PARTITION BY RANGE() SIZE('128MB');
限制点
当前OceanBase自动分区存在如下限制点：
- 不支持自动分裂 List、Hash 分区表。
- 不支持自动分裂二级分区表。
- 不支持被自动分裂的表的分区键与主键前缀不一样。
- 不支持无主键表的自动分区分裂。
- 不支持列存表的自动分区分裂。
- 不支持列存副本的自动分区分裂。
- 如果表所在的
TABLEGROUP（表组）里面包含了多张表时，不支持自动分区分裂；如果这个TABLEGROUP中只有这张表，则支持自动分区分裂。 - 不支持物化视图的自动分区分裂。
- 不支持全文索引的自动分裂。
- 不支持 GIS 索引的自动分裂。
- 不支持向量索引的自动分区分裂。
