-->
Seguimi in Twitter Seguimi in Facebook Seguimi in Pinterest Seguimi in LinkedIn Seguimi in Google+ Seguimi  in Stumbleupon seguimi  in instagram Sottoscrivi il feed
Blender, graphic, software, open source, Linux LibreOffice, open source, openoffice Gimp, graphic, software, open source, Linux kernel, Linux, software, open source Linux, distributions, Ubuntu, Linux Mint, Fedora, Mandriva Jamin, gpl, library, open source matroska, multimedia, container, linux pcman, file manager, linux LuninuX, distribition, Linux, open source Linux, infographic, history
Home » » MySQL: Optimize and Repair Tables

MySQL: Optimize and Repair Tables

You can, in most cases, also use the command OPTIMIZE TABLES to optimise and repair
tables, but this is not as fast or reliable (in case of real fatal errors) as myisamchk. On the
other hand, OPTIMIZE TABLE is easier to use and you don’t have to worry about ushing
tables. See Section 4.5.1 [OPTIMIZE TABLE], page 226.

Even that the repair in myisamchk is quite secure, it’s always a good idea to make a backup
BEFORE doing a repair (or anything that could make a lot of changes to a table)
4.4.6.1 myisamchk Invocation Syntax
myisamchk is invoked like this:
shell> myisamchk [options] tbl_name
The options specify what you want myisamchk to do. They are described below. (You
can also get a list of options by invoking myisamchk --help.) With no options, myisamchk
simply checks your table. To get more information or to tell myisamchk to take corrective
action, specify options as described below and in the following sections.

Get Chitika | Premium

tbl_name is the database table you want to check/repair. If you run myisamchk some-
where other than in the database directory, you must specify the path to the file, because
myisamchk has no idea where your database is located. Actually, myisamchk doesn’t care
whether or not the files you are working on are located in a database directory; you can copy
the files that correspond to a database table into another location and perform recovery
operations on them there.

You can name several tables on the myisamchk command line if you wish. You can also
specify a name as an index file name (with the ‘.MYI’ su x), which allows you to specify
all tables in a directory by using the pattern ‘*.MYI’. For example, if you are in a database
directory, you can check all the tables in the directory like this:
shell> myisamchk *.MYI
If you are not in the database directory, you can check all the tables there by specifying the
path to the directory:
shell> myisamchk /path/to/database_dir/*.MYI
You can even check all tables in all databases by specifying a wild card with the path to
the MySQL data directory:
shell> myisamchk /path/to/datadir/*/*.MYI
The recommended way to quickly check all tables is:
myisamchk --silent --fast /path/to/datadir/*/*.MYI
isamchk --silent /path/to/datadir/*/*.ISM
If you want to check all tables and repair all tables that are corrupted, you can use the
following line:
myisamchk --silent --force --fast --update-state -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM
The above assumes that you have more than 64 M free.
Note that if you get an error like:
myisamchk: warning: 1 clients is using or hasn’t closed the table properly
This means that you are trying to check a table that has been updated by the another
program (like the mysqld server) that hasn’t yet closed the file or that has died without
closing the file properly.

If you mysqld is running, you must force a sync/close of all tables with FLUSH TABLES and
ensure that no one is using the tables while you are running myisamchk. In MySQL Version
3.23 the easiest way to avoid this problem is to use CHECK TABLE instead of myisamchk to
check tables.

General Options for myisamchk
myisamchk supports the following options.
-# or --debug=debug_options
Output debug log. The debug_options string often is ’d:t:o,filename’.
-? or --help
Display a help message and exit.
-O var=option, --set-variable var=option
Set the value of a variable. The possible variables and their default values for
myisamchk can be examined with myisamchk --help:
key bu er size 523264
read bu er size 262136
write bu er size 262136
sort bu er size 2097144
sort key blocks 16
decode bits 9
sort_buffer_size is used when the keys are repaired by sorting keys, which
is the normal case when you use --recover.
key_buffer_size is used when you are checking the table with --extended-
check or when the keys are repaired by inserting key row by row in to the table
(like when doing normal inserts). Repairing through the key bu er is used in
the following cases:
• If you use --safe-recover.
• If the temporary files needed to sort the keys would be more than twice as
big as when creating the key file directly. This is often the case when you
have big CHAR, VARCHAR or TEXT keys as the sort needs to store the whole
keys during sorting. If you have lots of temporary space and you can force
myisamchk to repair by sorting you can use the --sort-recover option.
Reparing through the key bu er takes much less disk space than using sorting,
but is also much slower.

If you want a faster repair, set the above variables to about 1/4 of your available
memory. You can set both variables to big values, as only one of the above
bu ers will be used at a time.
-s or --silent
Silent mode. Write output only when errors occur. You can use -s twice (-ss)
to make myisamchk very silent.
-v or --verbose
Verbose mode. Print more information. This can be used with -d and -e. Use
-v multiple times (-vv, -vvv) for more verbosity!

-V or --version
Print the myisamchk version and exit.
-w or, --wait
Instead of giving an error if the table is locked, wait until the table is unlocked
before continuing. Note that if you are running mysqld on the table with --
skip-locking, the table can only be locked by another myisamchk command.

Check Options for myisamchk
-c or --check
Check table for errors. This is the default operation if you are not giving
myisamchk any options that override this.
-e or --extend-check
Check the table very thoroughly (which is quite slow if you have many indexes).
This option should only be used in extreme cases. Normally, myisamchk or
myisamchk --medium-check should, in most cases, be able to find out if there
are any errors in the table.

If you are using --extended-check and have much memory, you should increase
the value of key_buffer_size a lot!
-F or --fast
Check only tables that haven’t been closed properly.
-C or --check-only-changed
Check only tables that have changed since the last check.
-f or --force
Restart myisamchk with -r (repair) on the table, if myisamchk finds any errors
in the table.
-i or --information
Print informational statistics about the table that is checked.
-m or --medium-check
Faster than extended-check, but only finds 99.99% of all errors. Should, how-
ever, be good enough for most cases.
-U or --update-state
Store in the ‘.MYI’ file when the table was checked and if the table crashed.
This should be used to get full benefit of the --check-only-changed option,
but you shouldn’t use this option if the mysqld server is using the table and
you are running mysqld with --skip-locking.
-T or --read-only
Don’t mark table as checked. This is useful if you use myisamchk to check a
table that is in use by some other application that doesn’t use locking (like
mysqld --skip-locking).

Repair Options for myisamchk
The following options are used if you start myisamchk with -r or -o:
-D # or --data-file-length=#
Max length of data file (when re-creating data file when it’s ’full’).
-e or --extend-check
Try to recover every possible row from the data file. Normally this will also find
a lot of garbage rows. Don’t use this option if you are not totally desperate.
-f or --force
Overwrite old temporary files (table_name.TMD) instead of aborting.
-k # or keys-used=#
If you are using ISAM, tells the ISAM table handler to update only the first #
indexes. If you are using MyISAM, tells which keys to use, where each binary bit
stands for one key (first key is bit 0). This can be used to get faster inserts!
Deactivated indexes can be reactivated by using myisamchk -r. keys.
-l or --no-symlinks
Do not follow symbolic links. Normally myisamchk repairs the table a symlink
points at. This option doesn’t exist in MySQL 4.0, as MySQL 4.0 will not
remove symlinks during repair.

-r or --recover

Can fix almost anything except unique keys that aren’t unique (which is an
extremely unlikely error with ISAM/MyISAM tables). If you want to recover
a table, this is the option to try first. Only if myisamchk reports that the table
can’t be recovered by -r, you should then try -o. (Note that in the unlikely
case that -r fails, the data file is still intact.) If you have lots of memory, you
should increase the size of sort_buffer_size!

-o or --safe-recover

Uses an old recovery method (reads through all rows in order and updates all
index trees based on the found rows); this is a magnitude slower than -r, but
can handle a couple of very unlikely cases that -r cannot handle. This recovery
method also uses much less disk space than -r. Normally one should always
first repair with -r, and only if this fails use -o.
If you have lots of memory, you should increase the size of key_buffer_size!
-n or --sort-recover
Force myisamchk to use sorting to resolve the keys even if the temporary files
should be very big. This will not have any e ect if you have fulltext keys in the
table.
--character-sets-dir=...
Directory where character sets are stored.
--set-character-set=name
Change the character set used by the index

.t or --tmpdir=path
Path for storing temporary files. If this is not set, myisamchk will use the
environment variable TMPDIR for this.
-q or --quick
Faster repair by not modifying the data file. One can give a second -q to force
myisamchk to modify the original datafile in case of duplicate keys
-u or --unpack
Unpack file packed with myisampack.
Other Options for myisamchk
Other actions that myisamchk can do, besides repair and check tables:
-a or --analyze
Analyse the distribution of keys. This improves join performance by enabling
the join optimiser to better choose in which order it should join the tables and
which keys it should use: myisamchk --describe --verbose table_name’ or
using SHOW KEYS in MySQL.
-d or --description
Prints some information about table.
-A or --set-auto-increment[=value]
Force auto increment to start at this or higher value. If no value is given, then
sets the next auto increment value to the highest used value for the auto key +
1.
-S or --sort-index
Sort the index tree blocks in high-low order. This will optimise seeks and will
make table scanning by key faster.

-R or --sort-records=#

Sorts records according to an index. This makes your data much more localised
and may speed up ranged SELECT and ORDER BY operations on this index. (It
may be very slow to do a sort the first time!) To find out a table’s index
numbers, use SHOW INDEX, which shows a table’s indexes in the same order that
myisamchk sees them. Indexes are numbered beginning with 1.

Myisamchk Memory Usage
Memory allocation is important when you run myisamchk. myisamchk uses no more memory
than you specify with the -O options. If you are going to use myisamchk on very large files,
you should first decide how much memory you want it to use. The default is to use only
about 3M to fix things. By using larger values, you can get myisamchk to operate faster.
For example, if you have more than 32M RAM, you could use options such as these (in
addition to any other options you might specify):

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...
Using -O sort=16M should probably be enough for most cases.
Be aware that myisamchk uses temporary files in TMPDIR. If TMPDIR points to a memory
file system, you may easily get out of memory errors. If this happens, set TMPDIR to point
at some directory with more space and restart myisamchk.
When repairing, myisamchk will also need a lot of disk space:
• Double the size of the record file (the original one and a copy). This space is not needed
if one does a repair with --quick, as in this case only the index file will be re-created.
This space is needed on the same disk as the original record file!
• Space for the new index file that replaces the old one. The old index file is truncated
at start, so one usually ignore this space. This space is needed on the same disk as the
original index file!
• When using --recover or --sort-recover (but not when using --safe-recover), you
will need space for a sort bu er for: (largest_key + row_pointer_length)*number_
of_rows * 2. You can check the length of the keys and the row pointer length with
myisamchk -dv table. This space is allocated on the temporary disk (specified by
TMPDIR or --tmpdir=#).
If you have a problem with disk space during repair, you can try to use --safe-recover
instead of --recover.

Using myisamchk for Crash Recovery
If you run mysqld with --skip-locking (which is the default on some systems, like Linux),
you can’t reliably use myisamchk to check a table when mysqld is using the same table. If
you can be sure that no one is accessing the tables through mysqld while you run myisamchk,
you only have to do mysqladmin flush-tables before you start checking the tables. If you
can’t guarantee the above, then you must take down mysqld while you check the tables.
If you run myisamchk while mysqld is updating the tables, you may get a warning that a
table is corrupt even if it isn’t.

If you are not using --skip-locking, you can use myisamchk to check tables at any time.
While you do this, all clients that try to update the table will wait until myisamchk is ready
before continuing.

If you use myisamchk to repair or optimise tables, you must always ensure that the mysqld
server is not using the table (this also applies if you are using --skip-locking). If you
don’t take down mysqld you should at least do a mysqladmin flush-tables before you run
myisamchk. Your tables may be corrupted if the server and myisamchk access the tables
simultaneously.

This chapter describes how to check for and deal with data corruption in MySQL databases.
If your tables get corrupted frequently you should try to find the reason for this! See
Section A.4.1 [Crashing], page 579.
The MyISAM table section contains reason for why a table could be corrupted.

When performing crash recovery, it is important to understand that each table tbl_name
in a database corresponds to three files in the database directory:
File Purpose
‘tbl_name.frm’ Table definition (form) file
‘tbl_name.MYD’ Data file
‘tbl_name.MYI’ Index file

Each of these three file types is subject to corruption in various ways, but problems occur
most often in data files and index files.

myisamchk works by creating a copy of the ‘.MYD’ (data) file row by row. It ends the repair
stage by removing the old ‘.MYD’ file and renaming the new file to the original file name. If
you use --quick, myisamchk does not create a temporary ‘.MYD’ file, but instead assumes
that the ‘.MYD’ file is correct and only generates a new index file without touching the ‘.MYD’
file. This is safe, because myisamchk automatically detects if the ‘.MYD’ file is corrupt and
aborts the repair in this case. You can also give two --quick options to myisamchk. In
this case, myisamchk does not abort on some errors (like duplicate key) but instead tries
to resolve them by modifying the ‘.MYD’ file. Normally the use of two --quick options is
useful only if you have too little free disk space to perform a normal repair. In this case
you should at least make a backup before running myisamchk.

How to Check Tables for Errors
To check a MyISAM table, use the following commands:
myisamchk tbl_name
This finds 99.99% of all errors. What it can’t find is corruption that involves
only the data file (which is very unusual). If you want to check a table, you
should normally run myisamchk without options or with either the -s or --
silent option.
myisamchk -m tbl_name
This finds 99.999% of all errors. It checks first all index entries for errors and
then it reads through all rows. It calculates a checksum for all keys in the rows
and verifies that they checksum matches the checksum for the keys in the index
tree.

myisamchk -e tbl_name

This does a complete and thorough check of all data (-e means “extended
check”). It does a check-read of every key for each row to verify that they
indeed point to the correct row. This may take a long time on a big table
with many keys. myisamchk will normally stop after the first error it finds. If
you want to obtain more information, you can add the --verbose (-v) option.
This causes myisamchk to keep going, up through a maximum of 20 errors. In
normal usage, a simple myisamchk (with no arguments other than the table
name) is su cient.
myisamchk -e -i tbl_name
Like the previous command, but the -i option tells myisamchk to print some
informational statistics, too.

How to Repair Tables
In the following section we only talk about using myisamchk on MyISAM tables (extensions
.MYI and .MYD). If you are using ISAM tables (extensions .ISM and .ISD), you should use
isamchk instead.
Starting with MySQL Version 3.23.14, you can repair MyISAM tables with the REPAIR
TABLE command. See Section 4.4.5 [REPAIR TABLE], page 210.
The symptoms of a corrupted table include queries that abort unexpectedly and observable
errors such as these:
• ‘tbl_name.frm’ is locked against change
• Can’t find file ‘tbl_name.MYI’ (Errcode: ###)
• Unexpected end of file
• Record file is crashed
• Got error ### from table handler
To get more information about the error you can run perror ###. Here is the most
common errors that indicates a problem with the table:
shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired
Note that error 135, no more room in record file, is not an error that can be fixed by
a simple repair. In this case you have to do:
ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
In the other cases, you must repair your tables. myisamchk can usually detect and fix most
things that go wrong.

The repair process involves up to four stages, described below. Before you begin, you should
cd to the database directory and check the permissions of the table files. Make sure they are
readable by the Unix user that mysqld runs as (and to you, because you need to access the
files you are checking). If it turns out you need to modify files, they must also be writable
by you.

If you are using MySQL Version 3.23.16 and above, you can (and should) use the CHECK and
REPAIR commands to check and repair MyISAM tables. See Section 4.4.4 [CHECK TABLE],
page 208. See Section 4.4.5 [REPAIR TABLE], page 210.
The manual section about table maintenance includes the options to isamchk/myisamchk.
See Section 4.4.6 [Table maintenance], page 210.
The following section is for the cases where the above command fails or if you want to use
the extended features that isamchk/myisamchk provides.

If you are going to repair a table from the command line, you must first take down the
mysqld server. Note that when you do mysqladmin shutdown on a remote server, the
mysqld server will still be alive for a while after mysqladmin returns, until all queries are
stopped and all keys have been ushed to disk.

Stage 1: Checking your tables
Run myisamchk *.MYI or myisamchk -e *.MYI if you have more time. Use the -s (silent)
option to suppress unnecessary information.

If the mysqld server is done you should use the –update option to tell myisamchk to mark
the table as ’checked’.

You have to repair only those tables for which myisamchk announces an error. For such
tables, proceed to Stage 2.

If you get weird errors when checking (such as out of memory errors), or if myisamchk
crashes, go to Stage 3.

Stage 2: Easy safe repair
Note: If you want repairing to go much faster, you should add: -O sort_buffer=# -O
key_buffer=# (where # is about 1/4 of the available memory) to all isamchk/myisamchk
commands.
First, try myisamchk -r -q tbl_name (-r -q means “quick recovery mode”). This will
attempt to repair the index file without touching the data file. If the data file contains
everything that it should and the delete links point at the correct locations within the data
file, this should work, and the table is fixed. Start repairing the next table.

Otherwise, use the following procedure:
1. Make a backup of the data file before continuing.
2. Use myisamchk -r tbl_name (-r means “recovery mode”). This will remove incorrect
records and deleted records from the data file and reconstruct the index file.
3. If the preceding step fails, use myisamchk --safe-recover tbl_name. Safe recovery
mode uses an old recovery method that handles a few cases that regular recovery mode
doesn’t (but is slower).
If you get weird errors when repairing (such as out of memory errors), or if myisamchk
crashes, go to Stage 3.
Stage 3: Di cult repair

You should only reach this stage if the first 16K block in the index file is destroyed or
contains incorrect information, or if the index file is missing. In this case, it’s necessary to
create a new index file. Do so as follows:
1. Move the data file to some safe place.
2. Use the table description file to create new (empty) data and index files:
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE table_name;
mysql> quit
If your SQL version doesn’t have TRUNCATE TABLE, use DELETE FROM table_name in-
stead.
3. Copy the old data file back onto the newly created data file. (Don’t just move the old
file back onto the new file; you want to retain a copy in case something goes wrong.)
Go back to Stage 2. myisamchk -r -q should work now. (This shouldn’t be an endless
loop.)
Stage 4: Very di cult repair
You should reach this stage only if the description file has also crashed. That should never
happen, because the description file isn’t changed after the table is created:
1. Restore the description file from a backup and go back to Stage 3. You can also
restore the index file and go back to Stage 2. In the latter case, you should start with
myisamchk -r.
2. If you don’t have a backup but know exactly how the table was created, create a copy
of the table in another database. Remove the new data file, then move the description
and index files from the other database to your crashed database. This gives you new
description and index files, but leaves the data file alone. Go back to Stage 2 and
attempt to reconstruct the index file.

Table Optimisation
To coalesce fragmented records and eliminate wasted space resulting from deleting or up-
dating records, run myisamchk in recovery mode:
shell> myisamchk -r tbl_name
You can optimise a table in the same way using the SQL OPTIMIZE TABLE statement.
OPTIMIZE TABLE does a repair of the table, a key analyses and also sorts the index tree
to give faster key lookups. There is also no possibility of unwanted interaction between a
utility and the server, because the server does all the work when you use OPTIMIZE TABLE.
See Section 4.5.1 [OPTIMIZE TABLE], page 226.
myisamchk also has a number of other options you can use to improve the performance of
a table:
-S, –sort-index
-R index num, –sort-records=index num
-a, –analyze
For a full description of the option. See Section 4.4.6.1 [myisamchk syntax], page 211.
4.4.7 Setting Up a Table Maintenance Regimen
Starting with MySQL Version 3.23.13, you can check MyISAM tables with the CHECK TABLE
command. See Section 4.4.4 [CHECK TABLE], page 208. You can repair tables with the
REPAIR TABLE command. See Section 4.4.5 [REPAIR TABLE], page 210.
It is a good idea to perform table checks on a regular basis rather than waiting for problems
to occur. For maintenance purposes, you can use myisamchk -s to check tables. The -s
option (short for --silent) causes myisamchk to run in silent mode, printing messages only
when errors occur.

It’s also a good idea to check tables when the server starts up. For example, whenever the
machine has done a reboot in the middle of an update, you usually need to check all the
tables that could have been a ected. (This is an “expected crashed table”.) You could add
a test to safe_mysqld that runs myisamchk to check all tables that have been modified
during the last 24 hours if there is an old ‘.pid’ (process ID) file left after a reboot. (The
‘.pid’ file is created by mysqld when it starts up and removed when it terminates normally.
The presence of a ‘.pid’ file at system startup time indicates that mysqld terminated
abnormally.)
An even better test would be to check any table whose last-modified time is more recent
than that of the ‘.pid’ file.
You should also check your tables regularly during normal system operation. At MySQL
AB, we run a cron job to check all our important tables once a week, using a line like this
in a ‘crontab’ file:
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
This prints out information about crashed tables so we can examine and repair them when
needed.
As we haven’t had any unexpectedly crashed tables (tables that become corrupted for
reasons other than hardware trouble) for a couple of years now (this is really true), once a
week is more than enough for us.
We recommend that to start with, you execute myisamchk -s each night on all tables that
have been updated during the last 24 hours, until you come to trust MySQL as much as we
do.
Normally you don’t need to maintain MySQL tables that much. If you are changing tables
with dynamic size rows (tables with VARCHAR, BLOB or TEXT columns) or have tables with
many deleted rows you may want to from time to time (once a month?) defragment/reclaim
space from the tables.
You can do this by using OPTIMIZE TABLE on the tables in question or if you can take the
mysqld server down for a while do:
isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index -O sort_buffer_size=16M */*.MYI

Getting Information About a Table
To get a description of a table or statistics about it, use the commands shown below. We
explain some of the information in more detail later:
• myisamchk -d tbl name Runs myisamchk in “describe mode” to produce a descrip-
tion of your table. If you start the MySQL server using the --skip-locking option,
myisamchk may report an error for a table that is updated while it runs. However,
because myisamchk doesn’t change the table in describe mode, there isn’t any risk of
destroying data.
• myisamchk -d -v tbl name To produce more information about what myisamchk is
doing, add -v to tell it to run in verbose mode.
• myisamchk -eis tbl name Shows only the most important information from a table. It
is slow because it must read the whole table.
• myisamchk -eiv tbl name This is like -eis, but tells you what is being done.
Example of myisamchk -d output:
MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
table description:
Key Start Len Index Type
1 2 8 unique double
2 15 10 multip. text packed stripped
3 219 8 multip. double
4 63 10 multip. text packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text
8 138 4 multip. unsigned long
9 177 4 multip. unsigned long
193 1 text
Example of myisamchk -d -v output:
MyISAM file: company
Record format: Fixed length
File-version: 1
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked
Data records: 1403698 Deleted blocks: 0
Datafile parts: 1403698 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type
Rec/key Root Blocksize
1 2 8 unique double
1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double
73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text
4995 75090944 1024
8 138 4 multip. unsigned long 87 85036032 1024
9 177 4 multip. unsigned long 178 96481280 1024
193 1 text
Example of myisamchk -eis output:
Checking MyISAM file: company
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966
Example of myisamchk -eiv output:
Checking MyISAM file: company
Data records: 1403698 Deleted blocks: 0
- check file-size
- check delete-chain
block_size 1024:
index 1:
index 2:
index 3:
index 4:
index 5:
index 6:
index 7:
index 8:
index 9:
No recordlinks
- check index reference
- check data record references index: 1
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 2
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
- check data record references index: 3
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
- check data record references index: 5
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 6
Vacation Home Rentals
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 7
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 8
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 9
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 9% Packed: 17%
- check records and index references
[LOTS OF ROW NUMBERS DELETED]
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798
Here are the sizes of the data and index files for the table used in the preceding examples:
-rw-rw-r-- 1 monty tcx 317235748 Jan 12 17:30 company.MYD
-rw-rw-r-- 1 davida tcx 96482304 Jan 12 18:35 company.MYM
Explanations for the types of information myisamchk produces are given below. The “key-
file” is the index file. “Record” and “row” are synonymous:
• ISAM file Name of the ISAM (index) file.
• Isam-version Version of ISAM format. Currently always 2.
• Creation time When the data file was created.
• Recover time When the index/data file was last reconstructed.
• Data records How many records are in the table.
• Deleted blocks How many deleted blocks still have reserved space. You can optimise
your table to minimise this space. See Section 4.4.6.10 [Optimisation], page 220.
• Datafile: Parts For dynamic record format, this indicates how many data blocks there
are. For an optimised table without fragmented records, this is the same as Data
records.
• Deleted data How many bytes of non-reclaimed deleted data there are. You can opti-
mise your table to minimise this space. See Section 4.4.6.10 [Optimisation], page 220.
• Datafile pointer The size of the data file pointer, in bytes. It is usually 2, 3, 4, or 5
bytes. Most tables manage with 2 bytes, but this cannot be controlled from MySQL
yet. For fixed tables, this is a record address. For dynamic tables, this is a byte address.
• Keyfile pointer The size of the index file pointer, in bytes. It is usually 1, 2, or 3 bytes.
Most tables manage with 2 bytes, but this is calculated automatically by MySQL. It
is always a block address.

• Max datafile length How long the table’s data file (.MYD file) can become, in bytes.
• Max keyfile length How long the table’s key file (.MYI file) can become, in bytes.
• Recordlength How much space each record takes, in bytes.
• Record format The format used to store table rows. The examples shown above use
Fixed length. Other possible values are Compressed and Packed.
• table description A list of all keys in the table. For each key, some low-level information
is presented:
- Key This key’s number.
- Start Where in the record this index part starts.
- Len How long this index part is. For packed numbers, this should always be the
full length of the column. For strings, it may be shorter than the full length of the
indexed column, because you can index a prefix of a string column.
- Index unique or multip. (multiple). Indicates whether or not one value can exist
multiple times in this index.
- Type What data-type this index part has. This is an ISAM data-type with the
options packed, stripped or empty.
- Root Address of the root index block.
- Blocksize The size of each index block. By default this is 1024, but the value may
be changed at compile time.
- Rec/key This is a statistical value used by the optimiser. It tells how many records
there are per value for this key. A unique key always has a value of 1. This may
be updated after a table is loaded (or greatly changed) with myisamchk -a. If this
is not updated at all, a default value of 30 is given.
• In the first example above, the 9th key is a multi-part key with two parts.
• Keyblocks used What percentage of the keyblocks are used. Because the table used in
the examples had just been reorganised with myisamchk, the values are very high (very
near the theoretical maximum).
• Packed MySQL tries to pack keys with a common su x. This can only be used for
CHAR/VARCHAR/DECIMAL keys. For long strings like names, this can significantly reduce
the space used. In the third example above, the 4th key is 10 characters long and a
60% reduction in space is achieved.
• Max levels How deep the B-tree for this key is. Large tables with long keys get high
values.
• Records How many rows are in the table.
• M.recordlength The average record length. For tables with fixed-length records, this is
the exact record length.
• Packed MySQL strips spaces from the end of strings. The Packed value indicates the
percentage of savings achieved by doing this.
• Recordspace used What percentage of the data file is used.
• Empty space What percentage of the data file is unused.
• Blocks/Record Average number of blocks per record (that is, how many links a frag-
mented record is composed of). This is always 1 for fixed-format tables. This value
should stay as close to 1.0 as possible. If it gets too big, you can reorganise the table
with myisamchk. See Section 4.4.6.10 [Optimisation], page 220.
• Recordblocks How many blocks (links) are used. For fixed format, this is the same as
the number of records.
• Deleteblocks How many blocks (links) are deleted.
• Recorddata How many bytes in the data file are used.
• Deleted data How many bytes in the data file are deleted (unused).
• Lost space If a record is updated to a shorter length, some space is lost. This is the
sum of all such losses, in bytes.
• Linkdata When the dynamic table format is used, record fragments are linked with
pointers (4 to 7 bytes each). Linkdata is the sum of the amount of storage used by all
such pointers.
If a table has been compressed with myisampack, myisamchk -d prints additional informa-
tion about each table column. See Section 4.7.4 [myisampack], page 254, for an example of
this information and a description of what it means.


Related Post

0 commenti:

Post a Comment

Random Posts

My Blog List

Recent Posts

Recent Posts Widget

Popular Posts

Labels

Archive

Followers

Images Photo Gallery

page counter Mi Ping en TotalPing.com
 
Copyright © 2014 Linuxlandit & The Conqueror Penguin