[MDEV-8633] information_schema.index_statistics doesn't delete item when drop table indexes or drop table; Created: 2015-08-17  Updated: 2016-06-20  Resolved: 2016-06-20

Status: Closed
Project: MariaDB Server
Component/s: Plugins
Affects Version/s: 5.5, 10.0
Fix Version/s: 10.0.26

Type: Bug Priority: Major
Reporter: QFY Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: upstream, userstat
Environment:

CentOS 6.2,
Distrib 10.0.14-MariaDB ,
x86_64


Sprint: 10.0.25, 10.0.26

 Description   

set global userstat=1;
create table just_a_test(id int,first_name varchar(10),last_name varchar(10),address varchar(100),phone bigint,email varchar(30)) engine =innodb;
insert into just_a_test values(1,'fa','la','china_a',11111111,'fa_la@163.com'),
(2,'fb','lb','china_b',22222222,'fb_lb@163.com'),
(3,'fc','lc','china_c',33333333,'fc_lc@163.com'),
(4,'fd','ld','china_d',44444444,'fd_ld@163.com'),
(5,'fe','le','china_e',55555555,'fe_le@163.com');
alter table just_a_test add primary key (id);
alter table just_a_test add key IND_just_a_test_first_name_last_name(first_name,last_name);

select * from information_schema.index_statistics;
# Empty set (0.00 sec)
 
select count(*) from just_a_test where first_name='fc' and last_name='lc';
# +----------+
# | count(*) |
# +----------+
# |        1 |
# +----------+
# 1 row in set (0.03 sec)
 
select * from information_schema.index_statistics;
# +--------------+-------------+--------------------------------------+-----------+
# | TABLE_SCHEMA | TABLE_NAME  | INDEX_NAME                           | ROWS_READ |
# +--------------+-------------+--------------------------------------+-----------+
# | test         | just_a_test | IND_just_a_test_first_name_last_name |         1 |
# +--------------+-------------+--------------------------------------+-----------+

Step X

alter table just_a_test drop key IND_just_a_test_first_name_last_name;
 
select * from information_schema.index_statistics where table_schema='test' and table_name='just_a_test';
# +--------------+-------------+--------------------------------------+-----------+
# | TABLE_SCHEMA | TABLE_NAME  | INDEX_NAME                           | ROWS_READ |
# +--------------+-------------+--------------------------------------+-----------+
# | test         | just_a_test | IND_just_a_test_first_name_last_name |         1 |
# +--------------+-------------+--------------------------------------+-----------+
# 1 row in set (0.00 sec)

Step Y

drop table test.just_a_test;
 
select * from information_schema.index_statistics where table_schema='test' and table_name='just_a_test';
# +--------------+-------------+--------------------------------------+-----------+
# | TABLE_SCHEMA | TABLE_NAME  | INDEX_NAME                           | ROWS_READ |
# +--------------+-------------+--------------------------------------+-----------+
# | test         | just_a_test | IND_just_a_test_first_name_last_name |         1 |
# +--------------+-------------+--------------------------------------+-----------+
# 1 row in set (0.00 sec)

Why could step X show informations about index that couldn't existed?
Why could step Y show informations about table that couldn't existed?



 Comments   
Comment by Elena Stepanova [ 2015-08-19 ]

Thanks for the report.
Same in Percona 5.5/5.6, see https://bugs.launchpad.net/percona-server/+bug/1449440.

Comment by Jan Lindström (Inactive) [ 2016-04-26 ]

http://lists.askmonty.org/pipermail/commits/2016-April/009316.html
http://lists.askmonty.org/pipermail/commits/2016-April/009318.html

I will combine these before push.

Comment by Jan Lindström (Inactive) [ 2016-06-20 ]

commit 70ad689b11bfbd8a30a777f4893a5384628c00e7
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Mon Jun 20 09:58:31 2016 +0300

MDEV-8633: information_schema.index_statistics doesn't delete
item when drop table indexes or drop table;

Problem was that table and index statistics is removed from
persistent tables but not from memory cache. Added functions
to remove table and index statistics from memory cache

Generated at Thu Feb 08 07:28:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.