Offshore Software Outsourcing Company, offshore IT outsourcing services, offshore software development Russia

About ALTOROS: ALTOROS Systems is headquartered in Tampa, Florida and maintains an office near Boston, Massachusetts and technology development center in Belarus and Russia. ALTOROS specializes on providing value-added e-commerce and web-based software development and offshore software outsourcing services to emerging enterprises helping them successfully plan and implement business initiatives.

MyISAM is the default table type in MySQL Version 3.23. It's based on the ISAM code and has a lot of useful extensions.

The index is stored in a file with the .MYI (MYIndex) extension, and the data is stored in a file with the .MYD (MYData) extension. You can check/repair MyISAM tables with the myisamchk utility. See Crash recovery. You can compress MyISAM tables with myisampack to take up much less space. See myisampack.

The following is new in MyISAM:

· There is a flag in the MyISAM file that indicates whether the table was closed correctly. If mysqld is started with --myisam-recover, MyISAM tables will automatically be checked and/or repaired on open if the table wasn't closed properly.

· You can INSERT new rows in a table that doesn't have free blocks in the middle of the datafile, at the same time other threads are reading from the table (concurrent insert). An free block can come from an update of a dynamic length row with much data to a row with less data or when deleting rows. When all free blocks are used up, all future inserts will be concurrent again.

· Support for big files (63-bit) on filesystems/operating systems that support big files.

· All data is stored with the low byte first. This makes the data machine and OS independent. The only requirement is that the machine uses two's-complement signed integers (as every machine for the last 20 years has) and IEEE floating-point format (also totally dominant among mainstream machines). The only area of machines that may not support binary compatibility are embedded systems (because they sometimes have peculiar processors).

There is no big speed penalty in storing data low byte first; the bytes in a table row is normally unaligned and it doesn't take that much more power to read an unaligned byte in order than in reverse order. The actual fetch-column-value code is also not time critical compared to other code.

· All number keys are stored with high byte first to give better index compression.

· Internal handling of one AUTO_INCREMENT column. MyISAM will automatically update this on INSERT/UPDATE. The AUTO_INCREMENT value can be reset with myisamchk. This will make AUTO_INCREMENT columns faster (at least 10%) and old numbers will not be reused as with the old ISAM. Note that when an AUTO_INCREMENT is defined on the end of a multi-part-key the old behaviour is still present.

· When inserted in sorted order (as when you are using an AUTO_INCREMENT column) the key tree will be split so that the high node only contains one key. This will improve the space utilisation in the key tree.

· BLOB and TEXT columns can be indexed.

· NULL values are allowed in indexed columns. This takes 0-1 bytes/key.

· Maximum key length is 500 bytes by default (can be changed by recompiling). In cases of keys longer than 250 bytes, a bigger key block size than the default of 1024 bytes is used for this key.

· Maximum number of keys/table is 32 as default. This can be enlarged to 64 without having to recompile myisamchk.

· myisamchk will mark tables as checked if one runs it with --update-state. myisamchk --fast will only check those tables that don't have this mark.

· myisamchk -a stores statistics for key parts (and not only for whole keys as in ISAM).

· Dynamic size rows will now be much less fragmented when mixing deletes with updates and inserts. This is done by automatically combining adjacent deleted blocks and by extending blocks if the next block is deleted.

· myisampack can pack BLOB and VARCHAR columns.

· You can use put the datafile and index file on different directories to get more speed (with the DATA/INDEX DIRECTORY="path" option to CREATE TABLE). See CREATE TABLE.

MyISAM also supports the following things, which MySQL will be able to use in the near future:

· Support for a true VARCHAR type; a VARCHAR column starts with a length stored in 2 bytes.

· Tables with VARCHAR may have fixed or dynamic record length.

· VARCHAR and CHAR may be up to 64K. All key segments have their own language definition. This will enable MySQL to have different language definitions per column.

· A hashed computed index can be used for UNIQUE. This will allow you to have UNIQUE on any combination of columns in a table. (You can't search on a UNIQUE computed index, however.)

Note that index files are usually much smaller with MyISAM than with ISAM. This means that MyISAM will normally use less system resources than ISAM, but will need more CPU time when inserting data into a compressed index.

The following options to mysqld can be used to change the behaviour of MyISAM tables. See SHOW VARIABLES.

Option	Description
--myisam-recover=#	Automatic recovery of crashed tables.
-O myisam_sort_buffer_size=#	Buffer used when recovering tables.
--delay-key-write-for-all-tables	Don't flush key buffers between writes for any MyISAM table
-O myisam_max_extra_sort_file_size=#	Used to help MySQL to decide when to use the slow but safe key cache index create method. Note that this parameter is given in megabytes!
-O myisam_max_sort_file_size=#	Don't use the fast sort index method to created index if the temporary file would get bigger than this. Note that this paramter is given in megabytes!
-O bulk_insert_buffer_size=#	Size of tree cache used in bulk insert optimisation. Note that this is a limit per thread!

The automatic recovery is activated if you start mysqld with --myisam-recover=#. See Command-line options. On open, the table is checked if it's marked as crashed or if the open count variable for the table is not 0 and you are running with --skip-external-locking. If either of the above is true the following happens.

· The table is checked for errors.

· If we found an error, try to do a fast repair (with sorting and without re-creating the datafile) of the table.

· If the repair fails because of an error in the datafile (for example a duplicate key error), we try again, but this time we re-create the datafile.

· If the repair fails, retry once more with the old repair option method (write row by row without sorting) which should be able to repair any type of error with little disk requirements..

If the recover wouldn't be able to recover all rows from a previous completed statement and you didn't specify FORCE as an option to myisam-recover, then the automatic repair will abort with an error message in the error file:

Error: Couldn't repair table: test.g00pages

If you in this case had used the FORCE option you would instead have got a warning in the error file:

Warning: Found 344 of 354 rows when repairing ./test/g00pages

Note that if you run automatic recover with the BACKUP option, you should have a cron script that automatically moves file with names like tablename-datetime.BAK from the database directories to a backup media.

See Command-line options.

Key space Space needed for keys

MyISAM table formats MyISAM Table Formats

MyISAM table problems MyISAM Table Problems