I have a table with millions of rows. I am not sure exactly how many rows
it has, I get a different answer every time I ask! What's going on here?
This DB is used only by me, and only by explicit commands --- I have no
background or on-line tasks using the DB. This is the DB that took 2 days
to load and another two days to add a column and index. I decided to let
that column+index addition to complete, and it has now completed. I am
using the GUI administrator tool; in the Catalogs section I select the
relevant schema; in the right hand side I select the Tables tab. The
listing for my table (I have only the one) says Type=InnoDB, Row Format =
Compact, Data Length = 4.56 G, Index Length = 8.55 G, and Update Time is
blank. It is the Rows datum that is surprising --- every time I hit
"Refresh" I get a different number under Rows. It varies between 23
million and 28 million. It is not monotonically increasing, nor
monotonically decreasing. Sometimes the number of rows goes up, sometimes
it goes down. BTW, before the late addition of a column+index, the Rows
datum was 27,413,306. I did not notice this Rows variability before
adding a column+index --- but probably would not have, I had no reason to
Refresh the display repeatedly. I first noticed this Rows variability
during the column+index addition.
I am running MySQL 5.0.51a-community on RHEL 4 on a 4-processor (as far as
Linux is concerned) Intel 32-bit machine, with storage on the only local
HDD. I am using MySQL Administrator version 1.2.12, and it also says I am
using MySQL Client Version 5.0.30. I am running the admin tool on the
same machine as the MySQL server. That machine is otherwise idle. I
monitor CPU, network, and disk with Procmeter3, updated every 5 seconds.
It usually reports 0% CPU and 0 disk I/Os per period, and suitably low
network traffic. Sometimes I get a spike up to 5 disk I/Os in some 5
second period, presumably to some background thing(s) Linux and/or MySQL
is doing. When I hit Refresh, I get 22 or 23 disk I/Os and 2% CPU for
about 5 seconds.
Thanks,
Mike
