running. If you only read  tables with other programs, external locking is not required, although myisamchk might report warnings if the server changes tables while myisamchk  is reading them. 

With external locking disabled, to use myisamchk , you must either stop the server while myisamchk executes or else lock and flush the tables before running myisamchk . To avoid this requirement, use the CHECK TABLE  and REPAIR TABLE  statements to check and repair MyISAM  tables. 

For mysqld , external locking is controlled by the value of the skip_external_locking  system variable. When this variable is enabled, external locking is disabled, and vice versa. External locking is disabled by default. 

Use of external locking can be controlled at server startup by using the --external-locking  or -- skip-external-locking  option. 

If you do use external locking option to enable updates to MyISAM  tables from many MySQL processes, do not start the server with the delay_key_write  system variable set to ALL  or use the DELAY_KEY_WRITE=1  table option for any shared tables. Otherwise, index corruption can occur. 

The easiest way to satisfy this condition is to always use --external-locking  together with --delay- key-write=OFF . (This is not done by default because in many setups it is useful to have a mixture of the preceding options.) 

## 8.12 Optimizing the MySQL Server 

This section discusses optimization techniques for the database server, primarily dealing with system configuration rather than tuning SQL statements. The information in this section is appropriate for DBAs who want to ensure performance and scalability across the servers they manage; for developers constructing installation scripts that include setting up the database; and people running MySQL themselves for development, testing, and so on who want to maximize their own productivity. 

## 8.12.1 Optimizing Disk I/O 

This section describes ways to configure storage devices when you can devote more and faster storage hardware to the database server. For information about optimizing an InnoDB  configuration to improve I/O performance, see Section 8.5.8, “Optimizing InnoDB Disk I/O” . 

•Disk seeks are a huge performance bottleneck. This problem becomes more apparent when the amount of data starts to grow so large that effective caching becomes impossible. For large databases where you access data more or less randomly, you can be sure that you need at least one disk seek to read and a couple of disk seeks to write things. To minimize this problem, use disks with low seek times. 

•Increase the number of available disk spindles (and thereby reduce the seek overhead) by either symlinking files to different disks or striping the disks: 

•Using symbolic links 

This means that, for MyISAM  tables, you symlink the index file and data files from their usual location in the data directory to another disk (that may also be striped). This makes both the seek and read times better, assuming that the disk is not used for other purposes as well. See Section 8.12.2, “Using Symbolic Links” . 

Symbolic links are not supported for use with InnoDB  tables. However, it is possible to place InnoDB data and log files on different physical disks. For more information, see Section 8.5.8, “Optimizing InnoDB Disk I/O” . 

• Striping 

