2 # Bug #10901 Analyze Table on new table destroys table
3 # This is minimal test case to get error
4 # The problem was that analyze table wrote the shared state to the
5 # file and this didn't include the inserts while locked. A check was
6 # needed to ensure that state information was not updated when
7 # executing analyze table for a locked table. The analyze table had
8 # to be within locks and check table had to be after unlocking since
9 # then it brings the wrong state from disk rather than from the
10 # currently correct internal state. The insert is needed since it
11 # changes the file state, number of records. The fix is to
12 # synchronise the state of the shared state and the current state
13 # before calling mi_state_info_write
16 create table t1 (a bigint);
18 insert into t1 values(0);
25 create table t1 (a bigint);
26 insert into t1 values(0);
35 create table t1 (a bigint);
36 insert into t1 values(0);
42 # Bug #14902 ANALYZE TABLE fails to recognize up-to-date tables
43 # minimal test case to get an error.
44 # The problem is happening when analysing table with FT index that
45 # contains stopwords only. The first execution of analyze table should
46 # mark index statistics as up to date so that next execution of this
47 # statement will end up with Table is up to date status.
48 create table t1 (a mediumtext, fulltext key key1(a)) charset utf8 collate utf8_general_ci engine myisam;
49 insert into t1 values ('hello');
57 # procedure in PS BUG#13673
59 CREATE TABLE t1 (a int);
60 prepare stmt1 from "SELECT * FROM t1 PROCEDURE ANALYSE()";
63 deallocate prepare stmt1;
67 # bug#15225 (ANALYZE temporary has no effect)
69 create temporary table t1(a int, index(a));
70 insert into t1 values('1'),('2'),('3'),('4'),('5');
75 --echo End of 4.1 tests
78 # Bug #30495: optimize table t1,t2,t3 extended errors
80 create table t1(a int);
82 analyze table t1 extended;
84 optimize table t1 extended;
87 --echo End of 5.0 tests