mariadb/mysql-test/t/analyze.test

#
# Bug #10901 Analyze Table on new table destroys table
# This is minimal test case to get error
# The problem was that analyze table wrote the shared state to the
# file and this didn't include the inserts while locked. A check was
# needed to ensure that state information was not updated when
# executing analyze table for a locked table.  The analyze table had
# to be within locks and check table had to be after unlocking since
# then it brings the wrong state from disk rather than from the
# currently correct internal state. The insert is needed since it
# changes the file state, number of records.  The fix is to
# synchronise the state of the shared state and the current state
# before calling mi_state_info_write
#

create table t1 (a bigint);
lock tables t1 write;
insert into t1 values(0);
analyze table t1;
unlock tables;
check table t1;

drop table t1;

create table t1 (a bigint);
insert into t1 values(0);
lock tables t1 write;
delete from t1;
analyze table t1;
unlock tables;
check table t1;

drop table t1;

create table t1 (a bigint);
insert into t1 values(0);
analyze table t1;
check table t1;

drop table t1;

# Bug #14902 ANALYZE TABLE fails to recognize up-to-date tables
# minimal test case to get an error.
# The problem is happening when analysing table with FT index that
# contains stopwords only. The first execution of analyze table should
# mark index statistics as up to date so that next execution of this
# statement will end up with Table is up to date status.
create table t1 (a mediumtext, fulltext key key1(a)) charset utf8 collate utf8_general_ci engine myisam;
insert into t1 values ('hello');

analyze table t1;
analyze table t1;

drop table t1;

#
# procedure in PS BUG#13673
#
CREATE TABLE t1 (a int);
prepare stmt1 from "SELECT * FROM t1 PROCEDURE ANALYSE()";
execute stmt1;
execute stmt1;
deallocate prepare stmt1;

# End of 4.1 tests