Cause:
At present, the primary key of the tianmu engine does not fully support delete and update statements.
Temporary solution:
Modify the execution plan of the SQL layer so that the delete and update statements do not follow the primary key logic

feat(tianmu)The tianmu engine throws exception modification and specific exception information to the client

Cause:
no_dims is a destination number of dimensions.
It needs to be increased according to the number of executions.
But the logic here is that whether the table is involved in execution or not, it will lead to the increase of (no_dims),
This in turn causes the subsequent pack index to exceed the length of the index array.
Solution:
Optimize the logic of (no_dims) increasing to make it increase reasonably

    fix issuse 468 461 mtr result

    The reason for the error lies in that in Item_cond_or condition,
    sub-conditions similar to a=a will be cleared after
    elimination of equivalent conditions,
    but the tianmu engine does not do additional scene
    processing for the remaining conditions after elimination
    of equivalent conditions of Item_cond_or.
    Results in a scenario where
    only the remaining predicates are processed
    and the or predicates are not considered.

    The corresponding issuse:
    https://github.com/stoneatom/stonedb/issues/301
    https://github.com/stoneatom/stonedb/issues/733

    revert code style

* feat(website): Upgrade the official website

Rebuild and upgrade the official website

style(clangformat): change the parameter of clangformat AllowShortIfStatementsOnASingleLine to Never

Cause:
Execution plan error when AND/OR sql logical operator in condition occurs at the same time
Resolvent:
Optimize multiple equal execution plan logic

Cause of the problem:
The tianmu engine created join objects in syntax optimization, but did not explain them
Modify Scheme:
Release the join object after use

refine the return comment description

Cause of the problem:
In the mode where the type is ref, the line number returned by the tianmu engine is 10 by default.
Modify Scheme:
Delete the logic that returns 10 rows by default, and return the number of rows in the table instead.

[summary]
1 change tianmu status var scope from SHOW_SCOPE_UNDEF to SHOW_SCOPE_GLOBAL;

    remote

        CREATE TABLE t1 (a int not null,b int not null)ENGINE=TIANMU;
        CREATE TABLE t2 (a int not null, b int not null, primary key (a,b))ENGINE=TIANMU;
        CREATE TABLE t3 (a int not null, b int not null, primary key (a,b))ENGINE=TIANMU;
        insert into t1 values (1,1),(2,1),(1,3);
        insert into t2 values (1,1),(2,2),(3,3);
        insert into t3 values (1,1),(2,1),(1,3);
        select * from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b;
        delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b;
        # This should be empty
        select * from t3;
        drop table t1,t2,t3;

        delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b;
        select * from t3;
        ab

        delete t2.*,t3.* from t1,t2,t3 where t1.a=t2.a AND t2.b=t3.a and t1.b=t3.b;
        select * from t3;
        ab
        11
        21
        13

    because of https://github.com/stoneatom/stonedb/issues/678

    -- error ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE
    DELETE t2 FROM t1 JOIN t2 WHERE t1.a = 10;

    remove explain, Currently, the query plan is
    in the process of change and modification,
    and the consistency check of the query plan is not performed

    remove explain, Currently, the query plan is
    in the process of change and modification,
    and the consistency check of the query plan is not performed

    remove explain, Currently, the query plan is
    in the process of change and modification,
    and the consistency check of the query plan is not performed

    remove explain, Currently, the query plan is
    in the process of change and modification,
    and the consistency check of the query plan is not performed

    Test results for reference:
    https://blog.csdn.net/adofsauron/article/details/127228984?spm=1001.2014.3001.5501

    TODO: Q4 and Q21
    The case is an exists subquery
    because the Tianmu engine converts
    the syntax tree to an inner join
    on an association surface.
    For details, see
    https://blog.csdn.net/adofsauron/article/details/127228984?spm=1001.2014.3001.5501

fix(handler): fix the bug for create table #mysql50#q.q should return failure and actually return success (#487)
	[summary]
	1.When creating a table in the tianmu engine, add code to determine whether the table name is empty.
	2.Add issue corresponding to mtr test case.

[summary]
1 innodb(in 5.7) system variable "innodb_large_prefix" default value is ON, follow it;