本文为您介绍只读分析引擎功能的使用限制和兼容性说明。
说明:
除本文中提到的不支持场景与特殊场景外,只读分析引擎兼容目前 MySQL 的所有语法和能力。
产品架构与可用性差异
TDSQL-C MySQL 版的读写实例和只读实例使用 存算分离架构 实现,在弹性性能与扩展性上具备天然优势。但是只读分析引擎与读写实例和普通的只读实例不同。为了确保在复杂查询场景下的极致性能,只读分析引擎使用的是存储与计算集中架构,其数据是存储于计算节点所在的同一服务器的本地磁盘中。基于此区别需要注意存在如下差异点: 只读分析引擎扩缩容需要搬迁数据,故在扩缩容场景下无法与读写实例和普通只读实例的效率保持一致。(当前版本暂不支持扩缩容)
只读分析引擎在单节点场景下,并不具备高可用能力,若节点存在故障则会导致此只读分析引擎不可用。若需要只读分析引擎能够为您提供连续服务,请申请多个只读分析引擎。
数据加载限制
由于只读分析引擎通过列式存储构建数据,在某些特殊的 MySQL 使用场景下,会存在部分场景不支持的情况。如下所示:
无主键且无唯一键的表不支持加载到只读分析引擎
当表没有主键又没有唯一键时,表将无法加载到只读分析引擎中。这要求表必须包含主键,或者包含唯一键。在 LibraDB 引擎中,将默认使用表主键或唯一键进行列式数据构建。
使用 float、double 字段类型作为主键的表不支持加载到只读分析引擎
float、double 字段为浮点字段类型,不支持这两种字段类型作为主键的表将数据加载到只读分析引擎中。
存储过程、自定义函数、触发器、外键约束、event、索引均不会在只读分析引擎加载
不支持在列式存储中构建以上特殊对象。
存在不支持的字段类型的表可加载到只读分析引擎,但是相关列不支持查询
不支持此类字段在只读分析引擎中查询:SET、ENUM、Spatial Data Types、JSON。
所有针对分区表的 DDL 语句将不会在只读分析引擎中生效
分区表默认可以加载到只读分析引擎中并且支持查询。但是在只读分析引擎中,分区表是以单表的形式进行数据构建的,因此无法支持对分区表的分区执行相关 DDL 的同步。例如:重建分区、对分区进行 OPTIMIZE、修护分区、CHECK 分区、交换分区、删除分区、合并分区等操作。同时也不支持在只读分析引擎中单独针对某个子分区进行查询。
注意:
当在 TDSQL-C MySQL 版对分区表进行 drop 子分区、truncate 分区或执行 exchange 分区时,此表在只读分析引擎中将不可查询。若需要恢复使用,则需要将此表移除加载,再重新进行数据加载。
不支持临时表加载到只读分析引擎
由于临时表数据变更不记录日志,因此无法加载临时表的数据到只读分析引擎中。
不支持对表进行关于主键的任何修改
因为列存表会基于行存表的主键或唯一键进行数据重组织,故不能对 TDSQL-C MySQL 版的表进行任何主键的修改,例如:删除主键、修改主键为其他字段、添加字段为联合主键等操作。当表没有主键时,列存表将基于唯一键进行构建,在此类场景中,也不能对唯一键进行修改。
注意:
若在 TDSQL-C MySQL 版中对主键进行修改,则只读分析引擎的此表将停止同步并不可查询。若需要恢复使用,则需要将此表移除加载,再重新进行数据加载。
加载到分析引擎中的表被 rename 后的行为
当某一个表被加载到分析引擎中后,使用 rename 语句将表改名后,被 rename 后的表也将在分析引擎中自动加载。此时再创建一张与被 rename 的表的同名表,此新建的表亦会自动加载到分析引擎。
不支持的表创建操作
当一张表在未创建时就使用命令预加载到分析引擎或者将整库加载到分析引擎时,在 TDSQL-C MySQL 版中执行 create table … select
语句,此时此表将无法自动加载到分析引擎,若想要此表加载到分析引擎,则需要在表完成创建后将此表加载到分析引擎。
不支持列级权限
只读分析引擎默认会同步读写实例中的所有用户关于对象的查询权限,但是不会同步列级权限。
不支持的数据类型
只读分析引擎存在部分 数据类型 不支持,若对象存在不支持的数据类型,则此表将无法加载到分析引擎中。 语法限制
在只读分析引擎中,只能执行只读的查询语句,无法对数据进行任何变更操作,包括 DDL 和 DML 操作。
在只读分析引擎中,仅支持 SELECT 查询语句。而 SELECT 语句中依然存在少量关键字与语法不支持,详细请见 SELECT 语句说明。 只读分析引擎,暂时不支持全文检索语法。
值限制
在只读分析引擎中,默认普通列的支持的值的大小为1MB,最大值为5MB。若存在超过此值的字段,请 提交工单 处理。若存在某列值超出此大小,则在加载到分析引擎中会报错停止。 SQL_MODE
和 MySQL 类似,只读分析引擎支持通过 SET [ SESSION | GLOBAL ] sql_mode='modes'
语句设置 SQL 模式来设置全局或者会话级别的 SQL Mode。也可以通过 SELECT @@sql_mode
来查询当前 SQL 的 SQL Mode。
只读分析引擎支持如下常见的 MySQL 系统 SQL_MODE,未提到的 SQL_MODE 均不支持。但需要注意的是虽然只读分析引擎支持这些 SQL_MODE,但是部分 SQL_MODE 在只读分析引擎中并不适用,如 NO_AUTO_CREATE_USER、NO_ENGINE_SUBSTITUTION 等。
|
PIPES_AS_CONCAT | 将 || 视为字符串连接操作符 (+)(同 CONCAT()),而不视为 OR。 |
ANSI_QUOTES | 将 " 视为识别符,如果启用 ANSI_QUOTES,只有单引号内的会被认为是 String Literals,双引号被解释为识别符,因此不能用双引号来引用字符串。 |
IGNORE_SPACE | 若开启该模式,系统忽略空格。例如:“user”和“user ”是相同的。 |
ONLY_FULL_GROUP_BY | 如果未被聚合函数处理或未被 GROUP BY 的列,出现在 SELECT、HAVING、ORDER BY 中,此 SQL 不合法。 |
NO_UNSIGNED_SUBTRACTION | 在减运算中,如果某个操作数没有符号,不要将结果标记为 UNSIGNED(支持)。 |
NO_BACKSLASH_ESCAPES | 若启用该模式,\\ 反斜杠符号仅代表它自己。 |
STRICT_TRANS_TABLES | 对于事务存储引擎启用严格模式,insert 非法值之后,回滚整条语句。 |
STRICT_ALL_TABLES | 对于事务型表,写入非法值之后,回滚整个事务语句。 |
NO_ZERO_IN_DATE | 在严格模式时,不接受月或日部分为0的日期。如果使用 IGNORE 选项,我们为类似的日期插入“0000-00-00”。在非严格模式时,可以接受该日期,但会生成警告。 |
NO_ZERO_DATE | 在严格模式时,不要将“0000-00-00”作为合法日期。您仍然可以用 IGNORE 选项插入0日期。在非严格模式时,可以接受该日期,但会生成警告。 |
ALLOW_INVALID_DATES | 不检查全部日期的合法性,仅检查月份值是否在1至12之间,以及日期值是否在1到31之间,仅适用于 DATE 和 DATATIME 列,TIMESTAMP 列需要全部检查其合法性。 |
ERROR_FOR_DIVISION_BY_ZERO | 启用该模式,在 INSERT 或 UPDATE 过程中,被除数为0值时,系统产生错误。若未启用该模式,被除数为0值时,系统产生警告,并用 NULL 代替。 |
REAL_AS_FLOAT | 将 REAL 视为 FLOAT 的同义词,而不是 DOUBLE 的同义词。 |
NO_DIR_IN_CREATE | 创建表时,忽视所有 INDEX DIRECTORY 和 DATA DIRECTORY 指令,该选项仅对从复制服务器有用。 |
NO_AUTO_CREATE_USER | 防止 GRANT 自动创建新用户,但指定密码除外(但是在只读分析引擎中没有实际作用)。 |
NO_ENGINE_SUBSTITUTION | 如果需要的存储引擎被禁用或未编译,可以防止自动替换存储引擎(但是在只读分析引擎中没有实际作用)。 |
字符集和排序规则
字符集(character set)是符号与编码的集合。只读分析引擎中的默认字符集是 utf8mb4。
排序规则(collation)是在字符集中比较字符以及字符排序顺序的规则。例如,在二进制排序规则中,比较 A 和 a 的结果是不一样的。
目前只读分析引擎支持的字符集和排序规则如下表:
|
utf8 | UTF-8 Unicode | utf8_bin | 3 |
utf8mb4 | UTF-8 Unicode | utf8mb4_bin | 4 |
注意:
当读写实例中的对象采用其他字符集时,对于数据加载至只读分析引擎不受任何影响,但是某一些特殊字符在只读分析引擎中进行查询时将存在异常,同时也会因为排序规则的不同导致排序结果不一致的情况出现。
其他行为说明
在只读分析引擎中执行 SELECT …… GROUP BY expr
的返回结果与 MySQL 8.0 保持一致,默认不排序,与 MySQL 5.7 会有一定区别,MySQL 5.7 会默认排序。因此,无论是在 MySQL 5.7 版本还是 MySQL 8.0 版本中构建的只读分析引擎,都是如此的逻辑。
本页内容是否解决了您的问题?