11.1 正在考虑的功能包括：
YEAR 和 DATE 的索引用法
使用 MDEV-8320 时，一些使用 DATE 或 YEAR 函数的查询会快得多，因为优化器现在可以在某些情况下使用索引。采用以下方法（从创建包含 1000 个日期的表 t3 开始）。
create table t0(a int); insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); create table t1(a int); insert into t1 select A.a + B.a* 10 from t0 A, t0 B; create table t2 (pk int primary key, a datetime, b date, key(a), key(b)); insert into t2 select A.a*10+B.a, date_add(date_add('2017-01-01', interval A.a*8 day), interval B.a hour), date_add('2017-01-01', interval A.a*7 day) from t1 A, t0 B; SELECT * FROM t2 LIMIT 3; +----+---------------------+------------+ | pk | a | b | +----+---------------------+------------+ | 0 | 2017-01-01 00:00:00 | 2017-01-01 | | 1 | 2017-01-01 01:00:00 | 2017-01-01 | | 2 | 2017-01-01 02:00:00 | 2017-01-01 | ... | 997 | 2019-03-04 07:00:00 | 2018-11-25 | | 998 | 2019-03-04 08:00:00 | 2018-11-25 | | 999 | 2019-03-04 09:00:00 | 2018-11-25 | +-----+---------------------+------------+ explain select * from t2 where date(a) <= '2017-01-01'\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t2 type: range possible_keys: a key: a key_len: 6 ref: NULL rows: 10 Extra: Using index condition
直到 MariaDB 11.0，优化器才会使用索引：
explain select * from t2 where date(a) <= '2017-01-01'\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t2 type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 1000 Extra: Using where
索引可以与 YEAR 和 DATE 函数一起使用，也可以与任何 >、<、>=、<= 或 = 运算符一起使用：
explain select * from t2 where year(a) < 2017\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t2 type: range possible_keys: a key: a key_len: 6 ref: NULL rows: 1 Extra: Using index condition explain select * from t2 where year(a) = 2019\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: t2 type: range possible_keys: a key: a key_len: 6 ref: NULL rows: 80 Extra: Using index condition
UPDATE/DELETE 的半连接优化
MariaDB 有很多半连接优化。以前，单表 UPDATE/DELETE 语句无法利用这些，因为半连接优化是一种不能用于单表 UPDATE/DELETE 的子查询优化。现在，优化器可以自动将单表 UPDATE 和 DELETE 转换为多表 UPDATE/DELETE，从而为它们启用半连接优化。如果你在 UPDATE 或 DELETE 中使用子查询，这些语句可能会快得多（MDEV-7487 ) 例如，比较样本数据集中的这两个 EXPLAIN 结果。首先，在 MariaDB 11.1 之前：
explain delete from partsupp where (ps_partkey, ps_suppkey) in (select p_partkey, s_suppkey from part, supplier where p_retailprice between 901 and 910 and s_nationkey in (select n_nationkey from nation where n_name='PERU'))\G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: partsupp type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 700 Extra: Using where *************************** 2. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: nation type: ref possible_keys: PRIMARY,i_n_regionkey,i_n_name key: i_n_name key_len: 26 ref: const rows: 1 Extra: Using where; Using index *************************** 3. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: part type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: func rows: 1 Extra: Using where *************************** 4. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: supplier type: eq_ref possible_keys: PRIMARY,i_s_nationkey key: PRIMARY key_len: 4 ref: func rows: 1 Extra: Using where
然后，MariaDB 11.1 EXPLAIN 的等效查询：
explain delete from partsupp where (ps_partkey, ps_suppkey) in (select p_partkey, s_suppkey from part, supplier where p_retailprice between 901 and 910 and s_nationkey in (select n_nationkey from nation where n_name='PERU'))\G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: nation type: ref possible_keys: PRIMARY,i_n_name key: i_n_name key_len: 26 ref: const rows: 1 Extra: Using where; Using index *************************** 2. row *************************** id: 1 select_type: PRIMARY table: supplier type: ref possible_keys: PRIMARY,i_s_nationkey key: i_s_nationkey key_len: 5 ref: test.nation.n_nationkey rows: 1 Extra: Using index *************************** 3. row *************************** id: 1 select_type: PRIMARY table: partsupp type: ref possible_keys: PRIMARY,i_ps_partkey,i_ps_suppkey key: i_ps_suppkey key_len: 4 ref: test.supplier.s_suppkey rows: 1 Extra: *************************** 4. row *************************** id: 1 select_type: PRIMARY table: part type: eq_ref possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: test.partsupp.ps_partkey rows: 1 Extra: Using where
JSON 模式验证
JSON_SCHEMA_VALID 函数已根据 JSON Schema Draft 2020 实现 ( MDEV-27128 ) 。如果给定的 json 对模式有效，则该函数返回 true，否则返回 false。
SET @schema= '{ "properties" : { "number1":{ "maximum":10 }, "string1" : { "maxLength": 3} } }'; SELECT JSON_SCHEMA_VALID(@schema, '{ "number1":25, "string1":"ab" }'); +----------------------------------------------------------------+ | JSON_SCHEMA_VALID(@schema, '{ "number1":25, "string1":"ab" }') | +----------------------------------------------------------------+ | 0 | +----------------------------------------------------------------+ SELECT JSON_SCHEMA_VALID(@schema, '{ "number1":10, "string1":"ab" }'); +----------------------------------------------------------------+ | JSON_SCHEMA_VALID(@schema, '{ "number1":10, "string1":"ab" }') | +----------------------------------------------------------------+ | 1 | +----------------------------------------------------------------+
InnoDB defragmentation
InnoDB defragmentation 是一个很少使用的功能，它使 OPTIMIZE TABLE 不会像往常一样重建表，而是导致索引 B-trees 就地优化。但是，该选项使用了过多的锁定（独占锁定索引树），从未覆盖 SPATIAL INDEXes 或 FULLTEXT INDEXes，并且从未回收存储空间。由于它不是特别有用，在很多情况下不起作用，并且造成维护负担，它已被删除（MDEV-30545）。
其他特性
- MDEV-16329 ALTER ONLINE TABLE 已在存储引擎层之上实现，模仿了自 MariaDB 10.0 以来 InnoDB 所做的工作。
- Mariabackup 是用于执行物理在线备份的工具。它最初是 Xtrabackup 的一个分支，不支持 MariaDB 10.1 的静态数据加密。然而，文件仍然被命名为
xtrabackup_*. 它们现在被命名为mariadb_backup_*( MDEV-18931 )
链接
