Go to the first, previous, next, last section, table of contents.

# A Problems and Common Errors

This chapter lists some common problems and error messages that users have run into. You will learn how to figure out what the problem is, and what to do to solve it. You will also find proper solutions to some common problems.

## A.1 How to Determine What Is Causing Problems

When you run into problems, the first thing you should do is to find out which program / piece of equipment is causing problems:

- If you have one of the following symptoms, then it is probably a hardware (like memory, motherboard, CPU, or hard disk) or kernel problem:
  - The keyboard doesn't work. This can normally be checked by pressing Caps Lock. If the Caps Lock light doesn't change you have to replace your keyboard. (Before doing this, you should try to reboot your computer and check all cables to the keyboard.)
  - The mouse pointer doesn't move.
  - The machine doesn't answer to a remote machine's pings.
  - Different, unrelated programs don't behave correctly.
  - If your system rebooted unexpectedly (a faulty user level program should NEVER be able to take down your system).
  In this case you should start by checking all your cables and run some diagnostic tool to check your hardware! You should also check if there are any patches, updates, or service packs for your operating system that could likely solve your problems. Check also that all your libraries (like glibc) are up to date. It's always good to use a machine with ECC memory to discover memory problems early!
- If your keyboard is locked up, you may be able to fix this by logging into your machine from another machine and execute `kbd_mode -a` on it.
- Please examine your system log file (/var/log/messages or similar) for reasons for your problems. If you think the problem is in MySQL then you should also examine MySQL's log files. 「4.9.3 更新ログ」節参照.
- If you don't think you have hardware problems, you should try to find out which program is causing problems. Try using `top`, `ps`, `taskmanager`, or some similar program, to check which program is taking all CPU or is locking the machine.
- Check with `top`, `df`, or a similar program if you are out of memory, disk space, open files, or some other critical resource.
- If the problem is some runaway process, you can always try to kill it. If it doesn't want to die, there is probably a bug in the operating system.

If after you have examined all other possibilities and you have concluded that it's the MySQL server or a MySQL client that is causing the problem, it's time to do a bug report for our mailing list or our support team. In the bug report, try to give a very detailed description of how the system is behaving and what you think is happening. You should also state why you think it's MySQL that is causing the problems. Take into consideration all the situations in this chapter. State any problems exactly how they appear when you examine your system. Use the 'cut and paste' method for any output and/or error messages from programs and/or log files!

Try to describe in detail which program is not working and all symptoms you see! We have in the past received many bug reports that just state "the system doesn't work". This doesn't provide us with any information about what could be the problem.

If a program fails, it's always useful to know:

- Has the program in question made a segmentation fault (core dumped)?
- Is the program taking the whole CPU? Check with `top`. Let the program run for a while, it may be evaluating something heavy.
- If it's the `mysqld` server that is causing problems, can you do `mysqladmin -u root ping` or `mysqladmin -u root processlist`?
- What does a client program say (try with `mysql`, for example) when you try to connect to the MySQL server? Does the client jam? Do you get any output from the program?

When sending a bug report, you should of follow the outlines described in this manual. 「1.2.22.2 質問またはバグ報告」節参照.

## A.2 MySQL 使用時のよくあるいくつかのエラー

This section lists some errors that users frequently get. You will find descriptions of the errors, and how to solve the problem here.

### A.2.1 `Access denied` Error

「4.2.5 特権システムはどのように動くか？」節参照, and especially. 「4.2.10 何故 `Access denied` エラーになるのか」節参照.

### A.2.2 `MySQL server has gone away` Error

このセクションは `Lost connection to server during query` エラーに関することもカバーします。

`MySQL server has gone away` エラーのもっとも一般的な理由は、サーバ がタイムアウトで接続をクローズしたことです。デフォルトでは、何も起きない 場合、サーバは 8 時間後に接続をクローズします。 この時間は `mysqld` 起動時の `wait_timeout` 変数に与えることにより、変 更できます。

Another common reason to receive the `MySQL server has gone away` error is because you have issued a ``close'' on your MySQL connection and then tried to run a query on the closed connection.

`mysqladmin version` を実行することで MySQL が死んでいるかどうか、 また uptime はどれぐらいか、チェックできます。

スクリプトの場合は、自動的に再接続するためにクライアントからクエリを再発 行する必要があります。

この場合、通常これらのエラーコードを得ます: (OS 依存です):

`CR_SERVER_GONE_ERROR` | クライアントがサーバーに問い合わせを送る ことができなかった server.
`CR_SERVER_LOST` | クライアントがサーバーに書き込みを行ったときに はエラーは無かったけれども、問い合わせに対して完全に回答が返ってこない

間違っているか大きすぎるクエリをサーバに送った場合にもこのエラーが発生し ます。`mysqld` が間違ったブロックを得た場合、クライアントの何かが間違った と見なし、接続をクローズします。大きなクエリが必要な場合、例えば大きな `BLOB` で働かせる場合は、`mysqld` をオプション `-O max_query_size=#` (デフォルト 1M) で起動することでクエリ制限を増加できます。拡張メモリ は要求によって割り当てられます。そのため、`mysqld` は大きなクエリを発行し た時や大きな結果行を返す必要のある時だけ、多くのメモリを使用します！

### A.2.3 `Can't connect to [local] MySQL server` error

UNIX 上の MySQL クライアントは `mysqld` サーバに2つの異なる方法で 接続できます: UNIX ソケット, これはファイルシステム上のファイル(デフォルト ``/tmp/mysql.sock'`)を通して接続します。または TCP/IP, これはポート番 号を通して接続します。Unix ソケットは TCP/IP よりも速いですが、サーバと 同じコンピュータから接続する時しか使えません。UNIX ソケットは、ホスト名 を指定しない場合か、特別なホスト名 `localhost` を指定した場合に使用され ます。

On Windows you can connect only with TCP/IP if the `mysqld` server is running on Win95/Win98. If it's running on NT, you can also connect with named pipes. The name of the named pipe is MySQL. If you don't give a hostname when connecting to `mysqld`, a MySQL client will first try to connect to the named pipe, and if this doesn't work it will connect to the TCP/IP port. You can force the use of named pipes on Windows by using `.` as the hostname.

(2002) `Can't connect to ...` エラーは、通常、MySQL サーバーが システム上に走っていないか、あなたが、間違ったソケットファイルや TCP/IP ポートを使用して `mysqld` に接続しようとする場合におきます。

サーバー上に `mysqld` というプロセスが走っているか ( `ps` を使用して。 Windows の場合はタスクマネージャでみて) 確認することから開始してください！ 「2.4.2 MySQL サーバー起動時の問題」節参照.

`mysqld` プロセスが走っているなら、違う接続を試すことでサーバーを 確認することができます（もちろん、ポート番号とソケットのパスはあなたが セットアップしたものとは違うでしょう）：

    shell> mysqladmin version
    shell> mysqladmin variables
    shell> mysqladmin -h `hostname` version variables
    shell> mysqladmin -h `hostname` --port=3306 version
    shell> mysqladmin -h 'ip for your host' version
    shell> mysqladmin --socket=/tmp/mysql.sock version

`hostname` コマンドはフォワードクオートでなくバッククオテーションで 囲んでいることに注意してください； これは `ホスト名` (カレントのホスト名) を `mysqladmin` コマンドに与えます。

`Can't connect to local MySQL server` エラーが起こりうる理由として：

- `mysqld` is not running.
- MIT-pthreads を使用するシステム上で実行している。 ネイティブスレッドを持たないシステム上で実行している場合 `mysqld` は MIT-pthreads パッケージを使用します。 「2.2.2 MySQL がサポートする OS」節参照. MIT-pthreads スレッドは UNIX ソケットをサポートしません。 そのため、サーバに接続する時は常にホスト名を与える必要があります。 サーバーへの接続をチェックするために、以下を試してください：

      shell> mysqladmin -h `hostname` version

- 誰かが `mysqld` が使用する UNIX ソケット を削除した (default ``/tmp/mys qld.sock'`). だれかが `cron` で MySQL ソケットを削除しているかもしれません。(例 えば ``/tmp'` ディレクトリから古いファイルを削除するようなクローンで)。 いつでも `mysqladmin version` を実行して `mysqladmin` が使用するソケットが本当に存在するかをチェックできます。 この場合の修正は、``mysqld.sock'` を消さないように `cron` を変更するか、 またはソケットをどこか他の場所に移すことです。 「A.4.5 MySQL ソケットファイル ``/tmp/mysql.sock'` を変更する方法、削除から守る方法」節参照.
- `--socket=/path/to/socket` オプションで `mysqld` サーバーを起動できます。 もしサーバーのソケットのパスを変えた場合、MySQL クライアントに、新しい パスを教えなければなりません。 「A.4.5 MySQL ソケットファイル ``/tmp/mysql.sock'` を変更する方法、削除から守る方法」節参照.
- Linux を使用していてスレッドが一つ死んだとき（コアダンプした）。 この場合、他の `mysqld` スレッドをキルしなければなりません。 たとえば、`mysql_zap` スクリプトを、新しく MySQL サーバーを 起動する前に実行します。 「A.4.1 What To Do If MySQL Keeps Crashing」節参照.
- You may not have read and write privilege to either the directory that holds the socket file or privilege to the socket file itself. In this case you have to either change the privilege for the directory / file or restart `mysqld` so that it uses a directory that you can access.

もし `Can't connect to MySQL server on some_hostname` エラーの場合, 何が問題なのかを見つけるために、以下の手順を踏みます：

- もし `telnet your-host-name tcp-ip-port-number` を実行すると サーバーがアップするなら、 `RETURN` を何回かたたいてください。 もしこのポートで MySQL サーバーが走っているなら、 走っている MySQL サーバーのバージョンナンバーを含んだ レスポンスが得られるはずです。 もし `telnet: Unable to connect to remote host: Connection refused` のような エラーになったならば、このポートを使用しているサーバーはありません。
- ローカルのマシンの `mysqld` デーモンに接続してみてください。 `mysqldmin variables` で、`mysqld` が使用するように指定された TCP/IP ポート(変数 `port`)をチェックしてください。
- `mysqld` サーバーが `--skip-networking` オプションで起動されていないか 確認してください。

### A.2.4 `Host '...' is blocked` Error

以下のエラーの場合：

    Host 'hostname' is blocked because of many connection errors.
    Unblock with 'mysqladmin flush-hosts'

これは `mysqld` が多くの `'hostname'` ホストからの接続エラー(`max _connect_errors`) を受けた場合に発生します。 この `max_connect_errors` 大量発生後、`mysqld` は何か(クラッカーによる サーバーへのアタックなど)が起こったと判断し、このホストからの接続をいっさい拒否 するようにします。 これを解除するには、`mysqladmin flush-hosts` コマンドを実行します。

デフォルトでは、10回の接続エラーが発生した場合に、`mysqld` はそのホストを拒 否します。 この値は以下のようにして簡単に変更できます：

    shell> safe_mysqld -O max_connect_errors=10000 &

もしこのエラーがあるホストに対して発生するならば、まず最初にそのホストからの TCP /IP 接続に不具合がないかチェックしてください。 もし TCP/IP 接続が動作していないようなら、 `max_connect_errors` 値を増やす ことはよくないことです！

### A.2.5 `Too many connections` Error

もし MySQL に接続しようとして `Too many connections` となった場合、 これは既に `max_connections` 分、クライアントから `mysqld` サーバーへの 接続が行われています。

もしデフォルトの100よりも多い接続を必要とするならば、 `max_connections` 変数に多くの値を与えて、`mysqld` を リスタートしなくてはなりません。

実際は、`mysqld` は (`max_connections`+1) 個のクライアントからの接続を 許しています。 最後の１個は、 `process` 権限をもつユーザーのために取ってあります。 By not giving this privilege to normal users (they shouldn't need this), an administrator with this privilege can log in and use `SHOW PROCESSLIST` to find out what could be wrong. 「4.5.5 `SHOW` 構文」節参照.

The maximum number of connects MySQL is depending on how good the thread library is on a given platform. Linux or Solaris should be able to support 500-1000 simultaneous connections, depending on how much RAM you have and what your clients are doing.

### A.2.6 `Some non-transactional changed tables couldn't be rolled back` Error

If you get the error/warning: `Warning: Some non-transactional changed tables couldn't be rolled back` when trying to do a `ROLLBACK`, this means that some of the tables you used in the transaction didn't support transactions. These non-transactional tables will not be affected by the `ROLLBACK` statement.

The most typical case when this happens is when you have tried to create a table of a type that is not supported by your `mysqld` binary. If `mysqld` doesn't support a table type (or if the table type is disabled by a startup option) , it will instead create the table type with the table type that is most resembles to the one you requested, probably `MyISAM`.

You can check the table type for a table by doing:

`SHOW TABLE STATUS LIKE 'table_name'`. 「4.5.5.2 `SHOW TABLE STATUS`」節参照.

You can check the extensions your `mysqld` binary supports by doing:

`show variables like 'have_%'`. 「4.5.5.4 `SHOW VARIABLES`」節参照.

### A.2.7 `Out of memory` Error

クエリを行って、次のエラーのようなものを得た場合:

    mysql: Out of memory at line 42, 'malloc.c'
    mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)
    ERROR 2008: MySQL client ran out of memory

エラーは MySQL クライアント `mysql` に関係することに注意してください。 エラーの理由は単純で、クライアントが結果全体を格納するのに十分なメモリを持っ ていないことです。

この問題を解決するにあたり、まず最初にクエリーが正しいか確認してください。 そのクエリーは大量の結果を返すものでしょうか？ もしそうなら、`mysql --quick` を使用してください。 これは結果を取り出すために `mysql_use_result()` を使用します。 これはクライアントのロード不足を補います(サーバーより多い領域は取れません)。

### A.2.8 `Packet too large` Error

MySQL クライアントが `max_allowed_packet` よりも大きなブロックを code{mysqld} サーバーから得た時、`Packet too large` エラーを発します。

`mysql` クライアントを使用する場合、`mysql --set-variable=max_allowed_ packet=8M` でクライアントを開始することで、バッファを大きく設定できます。

もし(`DBI` のように)最大パケットサイズを指定できないクライアントを使用して いる場合、 パケットサイズを指定してサーバーを立ち上げ直します。 これは `mysqld` のオプションの `max_allowed_packet` に大きな値を設定す ることで行います。 例えば、 `BLOB` 型の許容範囲いっぱいのデータをテーブルに入れる場合、 `--set-variable=max_allowed_packet=16M` オプションを指定してサーバーを起動 する必要があります。

### A.2.9 Communication Errors / Aborted Connection

Starting with `MySQL 3.23.40` you only get the `Aborted connection` error of you start `mysqld` with `--warnings`.

If you find errors like the following in your error log.

    010301 14:38:23  Aborted connection 854 to db: 'users' user: 'josh'

「4.9.1 The Error Log」節参照.

This means that something of the following has happened:

- The client program did not call `mysql_close()` before exit.
- The client had been sleeping more than `wait_timeout` or `interactive_timeout` without doing any requests. 「4.5.5.4 `SHOW VARIABLES`」節参照.
- The client program ended abruptly in the middle of the transfer.

When the above happens, the server variable `Aborted_clients` is incremented.

The server variable `Aborted_connects` is incremented when:

- When a connection packet doesn't contain the right information.
- When the user didn't have privileges to connect to a database.
- When a user uses a wrong password.
- When it takes more than `connect_timeout` seconds to get a connect package.

Note that the above could indicate that someone is trying to break into your database!

「4.5.5.4 `SHOW VARIABLES`」節参照.

Other reasons for problems with Aborted clients / Aborted connections.

- Usage of duplex Ethernet protocol, both half and full with Linux. Many Linux Ethernet drivers have this bug. You should test for this bug by transferring a huge file via ftp between these two machines. If a transfer goes in burst-pause-burst-pause ... mode then you are experiencing a Linux duplex syndrome. The only solution to this problem is switching of both half and full duplexing on hubs and switches.
- Some problem with the thread library that causes interrupts on reads.
- Badly configured TCP/IP.
- Faulty Ethernets or hubs or switches, cables ... This can be diagnosed properly only by replacing hardware.
- `max_allowed_packet` is too small or queries require more memory than you have alloacated for `mysqld`. 「A.2.8 `Packet too large` Error」節参照.

### A.2.10 `The table is full` Error

このエラーは、古い MySQL バージョンにおいて、 メモリ内一時テーブルが `tmp_table_size` よりも大きくなっ た時に発生します。この問題を回避するために、`mysqld` のオプション `-O tmp_table_size=#` で増加、または、SQL オプション `SQL_BIG_TABLES` を問題のクエリの前に使用できます。 「5.5.6 `SET` 構文」節参照.

You can also start `mysqld` with the `--big-tables` option. This is exactly the same as using `SQL_BIG_TABLES` for all queries.

In MySQL Version 3.23, in-memory temporary tables will automatically be converted to a disk-based `MyISAM` table after the table size gets bigger than `tmp_table_size`.

### A.2.11 `Can't create/write to file` Error

If you get an error for some queries of type:

    Can't create/write to file '\\sqla3fe_0.ism'.

this means that MySQL can't create a temporary file for the result set in the given temporary directory. (The above error is a typical error message on Windows, and the Unix error message is similar.) The fix is to start `mysqld` with `--tmpdir=path` or to add to your option file:

    [mysqld]
    tmpdir=C:/temp

assuming that the ``c:\\temp'` directory exists. 「4.1.2 my.cnf オプションファイル」節参照.

Check also the error code that you get with `perror`. One reason may also be a disk full error;

    shell> perror 28
    Error code  28:  No space left on device

### A.2.12 `Commands out of sync` Error in Client

`Commands out of sync; You can't run this command now` をクライアン トコード中で得た場合、クライアント関数を間違った順番で呼び出しました！

これは例えば、`mysql_use_result()` を使用していて、`mysql_free_result( )` を行う前に新しいクエリの実行を試みた場合に発生します。これはまた、データ を返す２つのクエリの実行を、間に `mysql_use_result()` や `mysql_store_result()` 無しで試みた場合にも発生します。

### A.2.13 `Ignoring user` Error

以下のエラーの場合：

`Found wrong password for user: 'some_user@some_host'; Ignoring user`

これは `mysqld` の開始または 'reload' 時に `user` テーブル内に正しいパ スワードを持たないエントリを見つけたことを意味します。 これは単にエントリが許可システムに拒否されているだけです。

起こり得ることとその解決:

- 新しいバージョンの `mysqld` を、古いバージョン用の `user` テーブルで走 らせているのかもしれません。 `mysqlshow mysql user` を行うことによってこれを検証できます。 パスワードフィールドが 16 文字よりも短いかどうかをチェックしてください。 もしそうなら、これを修正するために、`scripts/add_long_password` スクリプト を実行してください。
- ユーザーが古いパスワード(最大8文字) を使用していて、`mysqld` を `--old -protocol` オプションで起動していないのかもしれません。 新しいパスワードで `user` テーブル内のユーザを更新するか、`--old-protocol` 付きで `mysqld` を再起動してください。
- `user` テーブルのパスワードを、`PASSWORD()` 関数を使用しないで登録した のかもしれません。 この場合、`user` テーブルのパスワードを、`mysql` を使用して更新します。 `PASSWORD()` 関数は以下のようにして使用します：

      mysql> update user set password=PASSWORD('your password')
                 where user='XXX';

### A.2.14 `Table 'xxx' doesn't exist` Error

もし `Table 'xxx' doesn't exist` か `Can't find file: 'xxx' (errno: 2)` エラーが出た場合、使用しているデータベースに `xxx` という名前のテーブルが 見付からなかったことを示します

データベースとテーブルの保存に、MySQL はディレクトリとファイルを使用し、 データベースとテーブルの名前はケース依存です! (Windows ではデータベースとテーブル名はケース非依存です。 クエリ中のテーブルに対する問い合わせは全て、同じケースで書かなくてはなりません！)

`SHOW TABLES` を使用してデータベースのテーブルを確認できます. 「4.5.5 `SHOW` 構文」節参照.

### A.2.15 `Can't initialize character set xxx` error.

If you get an error like:

    MySQL Connection Failed: Can't initialize character set xxx

This means one of the following things:

- The character set is a multi-byte character set and you have not support for the character set in the client. In this case you need to recompile the client with `--with-charset=xxx` or with `--with-extra-charsets=xxx`. 「2.3.3 典型的な `configure` オプション」節参照. All standard MySQL binaries are compiled with `--with-extra-character-sets=complex` which will enable support for all multi-byte character sets. 「4.6.1 データとソートに使用されるキャラクターセット」節参照.
- The character set is a simple character set which is not compiled into `mysqld` and the character set definition files is not in the place where the client expect to find them. In this case you need to:
  - Recompile the client with support for the character set. 「2.3.3 典型的な `configure` オプション」節参照.
  - Specify to the client where the character set definition files are. For many client you can do this with the `--character-sets-dir=path-to-charset-dir` option.
  - Copy the character definition files to the path where the client expect them to be.

### A.2.16 File Not Found

`ERROR '...' not found (Errcode: 23)`, `Can't open file: ... (errno: 24)` や `errcode 23` `errno 24` のエラーを MySQL から得た場合、 これは MySQL に十分なファイル記述子が割り当てられなかったことを意味しま す。 `perror` ユーティリティはさらに読みやすい形式のエラーメッセージを与えます:

    shell> perror 23
    File table overflow
    shell> perror 24
    Too many open files
    shell> perror 11
    Resource temporarily unavailable

これは `mysqld` が多くのファイルを開こうとしたことに起因します。 `mysqld` に一度に開くファイル数を多く開かないようしたり、あるいは、 `mysqld` が扱えるファイル記述子の数を与えたりできます。

`mysqld` が一度に開くファイルの数を少なくするには、`-O table_cache=32` オプション(デフォルトは64)を `safe_mysqld` に与えることで可能です。 また、`max_connections` の値(デフォルトは90)を少なくするならば、開くファイ ル数も少なくできます。

To change the number of file descriptors available to `mysqld`, you can use the option `--open-files-limit=#` to `safe_mysqld` or `-O open-files-limit=#` to `mysqld`. 「4.5.5.4 `SHOW VARIABLES`」節参照. The easiest way to do that is to add the option to your option file. 「4.1.2 my.cnf オプションファイル」節参照. If you have an old `mysqld` version that doesn't support this, you can edit the `safe_mysqld` script. There is a commented-out line `ulimit -n 256` in the script. You can remove the `'#'` character to uncomment this line, and change the number 256 to affect the number of file descriptors available to `mysqld`.

`ulimit` と `open-files-limit` はオペレーティングシステムの 制限内でしかファイル記述子の数を指定できません。 There is also a 'hard' limit that can only be overrided if you start `safe_mysqld` or `mysqld` as root (Just remember that you need to also use the `--user=..` option in this case). もし OS の制限以上にファイル記述子のオープン数を増やしたい場合、 お使いのオペレーティングシステムのドキュメントを見て対処してください。

`tcsh` を使用している場合は `ulimit` は動かないことに注意してください！ `tcsh` は現在の制限をあなたが問い合わせても、違った値を報告するでしょう。 この場合、`safe_mysqld` は `sh` で起動すべきです！

## A.3 Installation Related Issues

### A.3.1 Problems When Linking with the MySQL Client Library

If you are linking your program and you get errors for unreferenced symbols that start with `mysql_`, like the following:

    /tmp/ccFKsdPa.o: In function `main':
    /tmp/ccFKsdPa.o(.text+0xb): undefined reference to `mysql_init'
    /tmp/ccFKsdPa.o(.text+0x31): undefined reference to `mysql_real_connect'
    /tmp/ccFKsdPa.o(.text+0x57): undefined reference to `mysql_real_connect'
    /tmp/ccFKsdPa.o(.text+0x69): undefined reference to `mysql_error'
    /tmp/ccFKsdPa.o(.text+0x9a): undefined reference to `mysql_close'

you should be able to solve this by adding `-Lpath-to-the-mysql-library -lmysqlclient` LAST on your link line.

If you get `undefined reference` errors for the `uncompress` or `compress` function, add `-lz` LAST on your link line and try again!

If you get `undefined reference` errors for functions that should exist on your system, like `connect`, check the man page for the function in question, for which libraries you should add to the link line!

If you get `undefined reference` errors for functions that don't exist on your system, like the following:

    mf_format.o(.text+0x201): undefined reference to `__lxstat'

it usually means that your library is compiled on a system that is not 100 % compatible with yours. In this case you should download the latest MySQL source distribution and compile this yourself. 「2.3 MySQL ソースディストリビューションのインストール」節参照.

If you are trying to run a program and you then get errors for unreferenced symbols that start with `mysql_` or that the `mysqlclient` library can't be found, this means that your system can't find the share `libmysqlclient.so` library.

The fix for this is to tell your system to search after shared libraries where the library is located by one of the following methods:

- Add the path to the directory where you have `libmysqlclient.so` the `LD_LIBRARY_PATH` environment variable.
- Add the path to the directory where you have `libmysqlclient.so` the `LD_LIBRARY` environment variable.
- Copy `libmysqlclient.so` to some place that is searched by your system, like ``/lib'`, and update the shared library information by executing `ldconfig`.

Another way to solve this problem is to link your program statically, with `-static`, or by removing the dynamic MySQL libraries before linking your code. In the second case you should be sure that no other programs are using the dynamic libraries!

### A.3.2 一般ユーザで MySQL を動かす方法

`mysqld` (MySQL サーバ) はいかなるユーザーでも開始し実行することが できます。`mysqld` をユーザ `user_name` で実行するように変更するためには、 次を行なう必要があります:

1. Stop the server if it's running (use `mysqladmin shutdown`).
2. `user_name` が読み書きできるように、データベースディレクトリとその中のファ イルのパーミッションを変更します。(これは UNIX `root` ユーザーで実行する必 要があるでしょう)：

       shell> chown -R user_name /path/to/mysql/datadir

   MySQL データベースディレクトリのディレクトリーやファイルがシンボリック リンクの場合、 これらリンクの先のディレクトリとファイルも変更します。`chown -R` はシンボリ ックリンク先を変更してくれません。
3. ユーザ `user_name` でサーバを起動します。または MySQL 3.22 以降を 使用する場合は、`mysqld` を UNIX `root` で起動し `--user=user_name` スイッチを使用します。 `mysqld` は、接続を許可する前に、与えられた UNIX user `user_name` で実 行するように切り替えます。
4. To start the server as the given user name automatically at system startup time, add a `user` line that specifies the user name to the `[mysqld]` group of the ``/etc/my.cnf'` option file or the ``my.cnf'` option file in the server's data directory. For example:

       [mysqld]
       user=user_name

この時点で、あなたの `mysqld` プロセスは UNIX user `user_name` で正常 に動作します。

一つのことは変わりません。それは権限許可テーブルです。デフォルト (パーミッションテーブルインストールスクリプト`mysql_install_db`実行後の権限) では、`mysql`データベースへのアクセスやデータベースの作成、破棄はユーザ MySQL user `root` だけです。 これを変更しないと、それはそのままです。 `root` 以外の UNIX userでログインしている時でも、あなたは MySQL `root` user としてアクセスは可能です - ただプログラムに `-u root` をクライアントプログラムにオプション指定するだけです。

MySQL に `root` としてアクセスするには、 コマンドラインで `-u root` を使用するだけでいいことに注意してください。 UNIX `root` user や MySQL を走らせている UNIX ユーザーである必要は ないことに注意してください。 MySQL のアクセスパーミッションとMySQL のユーザは、 UNIX ユーザとは完全に別のものです。UNIX ユーザに関係するのは、クライアン トに `-u` オプションを使用しない場合だけです。この場合、クライアントは MySQL へのログインを、あなたの UNIX ログイン名で試みます。

あなたの UNIX マシンそれ自身が安全でない場合は、少なくとも MySQL ア クセステーブルの MySQL `root` ユーザにはパスワードを設定すべきです。 どこかの誰かが `mysql -u root db_name` を行ない、彼が望むことの全てを実行で きてしまうからです。

### A.3.3 ファイルパーミッションの問題

ファイルパーミッションの問題がある場合、 例えば、テーブルの生成時に `mysql` が次を出力する場合:

    ERROR: Can't find file: 'path/with/filename.frm' (Errcode: 13)

これは `UMASK` 環境変数が `mysqld` 起動時に間違ってセットされていると 考えられます。 デフォルトの umask は `0660` です. これは以下のようにして `safe_mysqld` 立ち上げ時に変更できます:

    shell> UMASK=384  # = 600 in octal
    shell> export UMASK
    shell> /path/to/safe_mysqld &

By default MySQL will create database and `RAID` directories with permission type 0700. You can modify this behavior by setting the `UMASK_DIR` variable. If you set this, new directories are created with the combined `UMASK` and `UMASK_DIR`. For example, if you want to give group access to all new directories, you can do:

    shell> UMASK_DIR=504  # = 770 in octal
    shell> export UMASK_DIR
    shell> /path/to/safe_mysqld &

In MySQL Version 3.23.25 and above, MySQL assumes that the value for `UMASK` and `UMASK_DIR` is in octal if it starts with a zero.

「H Environment Variables」節参照.

## A.4 Administration Related Issues

### A.4.1 What To Do If MySQL Keeps Crashing

全ての MySQL バージョンはリリースの前に多くのプラットフォームで テストされます。 これは MySQL にいかなるバグもないということを 意味しますが、発見するのが困難で、わずかなバグがあるかもしれません。 もし問題があった場合、何がシステムをクラッシュしているかを見つけようとする事は、 問題を早く修正するためのより良い機会でもあります。

まず最初に, その問題で `mysqld` デーモンが死ななければならないかどうかか, また はその問題がクライアントで処理しなければならないかどうかを調べるべきです。 `mysqladmin version` を実行することにより、 `mysqld` サーバーが どれぐらい稼働していたかわかります。 もし `mysqld` が死んでいたなら、 を実行することによってあるのかをチェックすることができます. mysqldが死んだなら、 その原因を ``mysql-data-directory/`hostname`.err'` で見つけれるかもしれません。 「4.9.1 The Error Log」節参照.

Many crashes of MySQL are caused by corrupted index / data files. MySQL will update the data on disk, with the `write()` system call, after every SQL statement and before the client is notified about the result. (This is not true if you are running with `delayed_key_writes`, in which case only the data is written.) This means that the data is safe even if `mysqld` crashes, as the OS will ensure that the not flushed data is written to disk. You can force MySQL to sync everything to disk after every SQL command by starting `mysqld` with `--flush`.

The above means that normally you shouldn't get corrupted tables unless:

- Someone/something killed `mysqld` or the machine in the middle of an update.
- You have found a bug in `mysqld` that caused it to die in the middle of an update.
- Someone is manipulating the data/index files outside of mysqld without locking the table properly.
- If you are running many `mysqld` servers on the same data on a system that doesn't support good file system locks (normally handled by the `lockd` daemon ) or if you are running multiple servers with `--skip-locking`
- You have a crashed index/data file that contains very wrong data that got `mysqld` confused.
- You have found a bug in the data storage code. This isn't that likely, but it's at least possible. In this case you can try to change the file type to another database handler by using `ALTER TABLE` on a repaired copy of the table!

何かがクラッシュする理由を知るのは非常に難しいので、まず、他の人で動くも のがあなたでクラッシュするのかどうかをチェックしてください。次のことを行っ てください。

- `mysqld` デーモンを `mysqladmin shutdown` で停止し, 全てのテーブルで `myisamchk --silent --force */*.MYI` を実行し、そして `mysqld` デーモ ンを再起動します. これはきれいな状態から開始することになります。 「4 MySQL Database Administration」節参照.
- `mysqld --log` を使用し、ログの情報から特定のクエリがサーバーをキルしている かを見つけ出してください。 95% のバグは特定のクエリに関係があります！ 通常これは、 MySQL が再起動される前の、ログファイルの最後のクエリの一つ です。 「4.9.2 The General Query Log」節参照. If you can repeatadly kill MySQL with one of the queries, even when you have checked all tables just before doing the query, then you have been able to locate the bug and should do a bug report for this! 「1.2.22.3 バグや問題を報告する方法」節参照.
- Try to make a test case that we can use to reproduce the problem. 「G.1.6 Making a test case when you experience table corruption」節参照.
- Try running the included mysql-test test and the MySQL benchmarks. 「9.3.2 MySQL Test Suite」節参照. They should test MySQL rather well. You can also add code that to the benchmarks to simulates your application! The benchmarks can be found in the ``bench'` directory in the source distribution or, for a binary distribution, in the ``sql-bench'` directory under your MySQL installation directory.
- `fork_test.pl` と `fork2_test.pl` を試します。
- デバッグ用に MySQL をコンフィグすると、何かが悪くなる場合にエラー を見つけ出すのがより簡単になります。`configure` に `--with-debug` オプションか `--with-debug=full` オプションを つけて MySQL を再コンフィグし、 再コンパイルしてください。 「G.1 MySQL server のデバッグ」節参照.
- デバッグ用に MySQL をコンフィグすると、いくつかのエラーを検出で きる安全なメモリ割り当てを含めます。これは何が起きているかについての多く の出力も提供します。
- あなたの OS の最新のパッチを適用しましたか？
- `--skip-locking` オプションを `mysqld` に使用してください。い くつかのシステム上では、`lockd` ロックマネージャは正しく動きません; `--skip-locking` オプションは `mysqld` に外部ロッキングを使用 しないように伝えます。(これは同じデータ上で2つの `mysqld` サーバを 動すことができず、`myisamchk` の使用時に注意しなければいけないことを 意味します。しかし、テストとしてこのオプションを試すことは指示できます。)
- `mysqld` が動いているのに応答がないように見えた時 `mysqladmin -u root processlist` を試しましたか？ 時々 `mysqld` はそう思えても死んでいません。問題は全ての接続が使用中であ ることか、いくつかの内部ロック問題があることです。`mysqladmin processlist` は通常これらの場合でも接続を作ることができ、現在の接続数と それらの状態についての有用な情報を提供できます。
- 別のウィンドウで、統計出力のためにコマンド `mysqladmin -i 5 status` や `mysqladmin -i 5 -r status` をクエリ中に行ってください。
- 次を試してください:
  1. `gdb` (または他のデバッガ) から `mysqld` を開始してください。 「G.1.3 Debugging mysqld under gdb」節参照.
  2. あなたのテストスクリプトを実行してください。
  3. Print the backtrace and the local variables at the 3 lowest levels. In gdb you can do this with the following commands when `mysqld` has crashed inside gdb:

         backtrace
         info local
         up
         info local
         up
         info local

     With gdb you can also examine which threads exist with `info threads` and switch to a specific thread with `thread #`, where `#` is the thread id.
- MySQL にクラッシュまたは間違った振る舞いをさせるあなたのアプリ ケーションのシミュレートを Perl スクリプトで試みてください。
- または通常のバグレポートを送ってください。 「1.2.22.3 バグや問題を報告する方法」節参照。しかし通常 よりもさらに詳細にしてください。MySQL は多くの人のために働いて いるため、クラッシュはあなたのコンピュータだけに存在する何か(例えば、あ なたの特別なシステムライブラリに関連したエラー)から生じていると思われま す。
- もし可変長のレコードを扱うテーブルで問題があった場合、 もし、`BLOB/TEXT` フィールドは使用しておらず、`VARCHAR` フィールド だけ使用しているなら、全ての `VARCHAR` フィールドを `ALTER TABLE` で `CHAR` に変更してみてください。 これは MySQL に固定長レコードを使用させるようにします。 固定長レコードは少し余分な領域をとりますが、よりエラーに対して 強くなります。 現在の可変長のレコードのコードは MySQL AB で少なくとも３年以上問題なく 使用されています。 しかし可変長のレコードはよりエラーの傾向があり、 上記の事柄を試すことは良いアイデアです！

### A.4.2 忘れたパスワードをリセットする

もし MySQL の `root` ユーザーのパスワードを忘れた場合、 これを以下のようにして入れ直すことが可能です。

1. `mysqld` サーバーを `kill` で落とす。 (`kill -9` ではありません！) PID 番号は通常 MySQL データディレクトリに `.pid` ファイルとして 書かれています：

       kill `cat /mysql-data-directory/hostname.pid`

   これを、 UNIX `root` ユーザーか、MySQL サーバーを実行した ユーザーで行います。
2. `mysqld` を `--skip-grant-tables` オプションで起動。
3. `mysql -h hostname mysql` で`mysqld` サーバーに接続し、 `GRANT` コマンドでパスワードを変更します。 「4.3.1 `GRANT` と `REVOKE` 構文」節参照. `mysqladmin -h hostname -u user password 'new password'` でも変更可能です。
4. 許可テーブルを読み込みます： `mysqladmin -h hostname flush-privileges` か、SQL 文の `FLUSH PRIVILEGES` を実行します。

Note that after you started `mysqld` with `--skip-grant-tables`, any usage of `GRANT` commands will give you an `Unknown command` error until you have executed `FLUSH PRIVILEGES`.

### A.4.3 MySQL はフルディスクをどのように扱うか？

ディスクフルが起きた場合 MySQL は次のことを行います:

- 現在の行を書くのに十分な領域があるかどうかを1分毎に1回チェックします。十 分なディスクがある場合は、何も起きなかったように継続します。
- 6分毎にログファイルにディスクフルを警告するエントリを書き出します。

この問題の場合、以下のようにします：

- 継続するためには、全てのレコードを挿入するのに十分な領域を解放する必要が あります。
- スレッドをアボートするためには、`mysqladmin kill` をスレッドに送る 必要があります。スレッドは次に(1分)ディスクをチェックした時にアボートし ます。
- 他のスレッドが ``disk full'' が発生したテーブルで待たされることに注意して ください。多くの ``locked'' スレッドがある場合、disk full を待つ一つのスレッ ドを kill することで、他のスレッドの継続を許します。

Exceptions to the above behaveour is when you use `REPAIR` or `OPTIMIZE` or when the indexes are created in a batch after an `LOAD DATA INFILE` or after an `ALTER TABLE` statement.

All of the above commands may use big temporary files that left to themself would cause big problems for the rest of the system. If MySQL gets disk full while doing any of the above operations, it will remove the big temporary files and mark the table as crashed (except for `ALTER TABLE`, in which the old table will be left unchanged).

### A.4.4 MySQL が一時ファイルを格納する場所

MySQL は一時ファイルを格納する場所として `TMPDIR` 環境変数の値を 使用します。`TMPDIR` を設定していなければ、MySQL はシステムのデフォルトを 使用します。通常は ``/tmp'` または ``/usr/tmp'` です。`TMPDIR` が 小さすぎる場合、`safe_mysqld` を編集して、十分な領域がある他のディレクトリ を指すように `TMPDIR` を設定すべきです！ `--tmpdir` オプションを `mysqld` に与えることで、一時ファイルディレク トリを指定することも可能です。

MySQL は全ての一時ファイルを ``隠しファイル'' として生成します。 これは `mysqld` が終了した場合に、一時ファイルが削除されないことを確実にし ます。隠しファイルを使用する '悪い' 側面は、小さすぎる一時ディスクを一杯 にする大きな一時ファイルを見つけられないことです。

ソート時 (`ORDER BY` または `GROUP BY`)、MySQL は通常一つまた は二つの一時ファイルを使用します。必要な最大のディスク容量は:

    (length of what is sorted + sizeof(database pointer))
    * number of matched rows
    * 2

`sizeof(database_pointer)` は通常４ですが、将来本当に大きなテーブル のために大きくなることもあります。

いくつかの `SELECT` クエリは一時的な SQL テーブルも生成します。これらは隠 しファイルではなく、``SQL_*'` という名前です。

`ALTER TABLE` は一時テーブルをオリジナルテーブルと同じディレクトリ 内に生成します。

### A.4.5 MySQL ソケットファイル ``/tmp/mysql.sock'` を変更する方法、削除から守る方法

もし誰かに MySQL のソケットファイル ``/tmp/mysql.sock'` が消されるな ら、ほとんどの UNIX がそうであるように、 ``/tmp'` に `sticky` ビットをたてて 保護します。 `root` でログインして、以下のようにします：

    shell> chmod +t /tmp

これはファイルのオーナーとスーパーユーザー(`root`) のみが、 ``/tmp'` のファイルを消すことができます。

`sticky` ビットが立っているか確認するには、 `ls -ld /tmp` を行います。 パーミッションの最後のビットが `t` ならば、セットされています。

You can change the place where MySQL uses / puts the socket file the following ways:

- Specify the path in a global or local option file. For example, put in `/etc/my.cnf`:

      [client]
      socket=path-for-socket-file

      [mysqld]
      socket=path-for-socket-file

  「4.1.2 my.cnf オプションファイル」節参照.
- Specifying this on the command line to `safe_mysqld` and most clients with the `--socket=path-for-socket-file` option.
- この場合、 `MYSQL_UNIX_PORT` 環境変数に設定することにより可能です。
- Defining the path with the `configure` option `--with-unix-socket-path=path-for-socket-file`. 「2.3.3 典型的な `configure` オプション」節参照.

ソケットのテストをする場合、以下のようにします：

    shell> mysqladmin --socket=/path/to/socket version

### A.4.6 Time Zone Problems

もし `SELECT NOW()` があなたのローカル時間ではなく GMT を返すなら、 `TZ` 環境変数をローカルのTimezone に設定しなくてはなりません。 環境変数の設定は、サーバーを実行する前に行われなくてはなりません。 たとえば、`safe_mysqld` や `mysql.server` スクリプトで 行います。 「H Environment Variables」節参照.

## A.5 Query Related Issues

### A.5.1 検索時のケース依存

デフォルトでは MySQL フィールドはケース非依存です (しかし、ケース非依 存にならないいくつかの文字セットはありますsuch as `czech`)。 これは、`col_name LIKE 'a%'` で検索した場合、`A` または `a` で始まる全てのフィールドを得ることを 意味します。検索をケース依存にしたいのなら、始まりをチェックするには `INDEX(column, "A")=1` のようなことを、また、文字列全体が同じかどう かには `STRCMP(column, "A") = 0` を使用してください。

単純な比較操作 `>=, >, =, <, <=`、ソートそしてグループ化は、文字 ``sort val ue'' 上で行われます。同じソート値の文字 (like E, e and 'e)は同じ文字と して扱われます！

In older MySQL versions `LIKE` comparisons where done on the uppercase value of each character (E == e but E <> 'e. In newer MySQL versions `LIKE` works just like the other comparison operators.

あるフィールドをいつでもケース依存で扱いたい場合は、それを `BINARY` として宣言してください。 「6.5.3 `CREATE TABLE` 構文」節参照.

big5 エンコーディングと呼ばれる中国語データを使用している場合は、全ての 文字項目を `BINARY` にしてください。これは、big5 エンコーディング文 字のソート順が ascii コードが基になっているため、機能します。

### A.5.2 `DATE` フィールド使用時の問題

日付 `DATE` の形式は `'YYYY-MM-DD'` です。ANSI SQL に従って実際には他 のは許されま せん。更新または `SELECT` 文中の WHERE 節内ではこの形式を使用すべきです。す なわち:

    mysql> SELECT * FROM tbl_name WHERE date >= '1997-05-05';

利便のため MySQL は、日付が数値の文脈で使用されると、日付を自動的に数 値に変換します。これにより、更新と `TIMESTAMP`, `DATE` または `DATETIME` フィールドでの `WHERE` 時に、わりと自由に日付を指定すること ができます。 (この記述を許すため、句読記号を日付のセパレーターとして使用します。 例えば、`'1998-08-15'` と `'1998#08#15'` は同一です.) もしろんセパレーターのない記述(例：`'19980815'`)も日付として変換してくれま す。

特別な日付 `'0000-00-00'` は `'0000-00-00'` として格納され取り出されま す。 MyODBC を通して `'0000-00-00'` 日付を使用する時、MyODBC 2 .50.12 以上では自動的に `NULL` に変換されます。ODBC はこの日付の種類を扱え ないためです。

Because MySQL performs the conversions described above, the following statements work:

    mysql> INSERT INTO tbl_name (idate) VALUES (19970505);
    mysql> INSERT INTO tbl_name (idate) VALUES ('19970505');
    mysql> INSERT INTO tbl_name (idate) VALUES ('97-05-05');
    mysql> INSERT INTO tbl_name (idate) VALUES ('1997.05.05');
    mysql> INSERT INTO tbl_name (idate) VALUES ('1997 05 05');
    mysql> INSERT INTO tbl_name (idate) VALUES ('0000-00-00');

    mysql> SELECT idate FROM tbl_name WHERE idate >= '1997-05-05';
    mysql> SELECT idate FROM tbl_name WHERE idate >= 19970505;
    mysql> SELECT mod(idate,100) FROM tbl_name WHERE idate >= 19970505;
    mysql> SELECT idate FROM tbl_name WHERE idate >= '19970505';

次は動きません

    mysql> SELECT idate FROM tbl_name WHERE STRCMP(idate,'19970505')=0;

`STRCMP()` は文字列関数で、`idate` を文字に変換して、文字比較を行いま す。 `'19970505'` は日付には変換してくれず、日付の比較も行いません。

MySQL は日付が正しいかどうかをチェックしないことに注意してくだ さい。間違った日付(例えば `'1998-2-31'`)を格納すると、その間違った日付が格 納されます。日付が全体的に不可能な場合、`0` が `DATE` フィールドに 格納されます。 これは主に速度の問題で、日付のチェックはサーバではなくアプリケーションでと我々 は考えています。

### A.5.3 `NULL` 値での問題

SQL の初心者のありがちな混乱は、`NULL` 値が空文字列 `''` と同じ物だと 考えることです。これは正しくありません！ 例えば、次のステートメントは全く別の ものです:

    mysql> INSERT INTO my_table (phone) VALUES (NULL);
    mysql> INSERT INTO my_table (phone) VALUES ("");

両方の文とも `phone` フィールドに値を挿入していますが、 初めのは `NULL` 値を挿入し、二番目のは空文字列を挿入しています。 初めのは ``電話番号を知らない'' と見なされ、二番目のは ``彼女は電話を 持っていない'' と見なされます。

SQL では、 `NULL` は他の全ての値(たとえ `NULL` でも)と比較した時に、 常に偽になる値です。 `NULL` を含む式は、特に断りがなければ、常に `NULL` 値を生成します。次の項目は全て `NULL` を返します:

    mysql> SELECT NULL,1+NULL,CONCAT('Invisible',NULL);

`NULL` 値がセットされている項目を検索する場合、 `=NULL` テストを行わないでください。 これは `expr = NULL` が FALSE なので、なんの行も返しません。 例えば以下の例：

    mysql> SELECT * FROM my_table WHERE phone = NULL;

`NULL` 値を持つフィールドを検索したい場合は、`IS NULL` テストを使用し なくてはいけま せん。次は `NULL` 電話番号と空の電話番号を見つける方法を示しています:

    mysql> SELECT * FROM my_table WHERE phone IS NULL;
    mysql> SELECT * FROM my_table WHERE phone = "";

MySQL では、他の多くの SQL サーバのように、`NULL` 値を持つ インデックスフィールドを持てません。これらのフィールドは `NOT NULL` と宣言 しなくてはいけません。 インデックスフィールドには、`NULL` を設定することはできません。

`LOAD DATA INFILE` でデータを読み込むときは、空のフィールドは `''` で 更新されます。 項目を `NULL` 値にしたい場合は、テキストファイル中に `\N` を使用すべき です。 リテラルとしての `'NULL'` 語が、ある状況下で使用されています。 「6.4.8 `LOAD DATA INFILE` 構文」節参照.

`ORDER BY` 使用時, `NULL` 値は最初に提示されます. `DESC` を使用して降順にソートする時、`NULL` 値は最後になります。 `GROUP BY` 使用時, 全ての `NULL` 値は等しいと見なされます。

`NULL` 処理を手助けするため、次の関数を使用できます: `IS NULL`, `IS NOT NULL`, `IFNULL()`.

いくつかの項目型では、`NULL` 値はハンドルとして扱われます。 もしテーブル内の最初の `TIMESTAMP` 項に `NULL` を挿入するなら、 現在の日付と時刻が挿入されます。もし `AUTO_INCREMENT` 項に`NULL` 値を 挿入するなら、 次のシーケンス番号が挿入されます。

### A.5.4 `alias` の問題

`GROUP BY`, `ORDER BY`, `HAVING` 節において 項目を参照するに当たりエイリアスが使用できます。 エイリアスは項目としてより良い名称を与えるのに使用されます：

    SELECT SQRT(a*b) as rt FROM table_name GROUP BY rt HAVING rt > 0;
    SELECT id,COUNT(*) AS cnt FROM table_name GROUP BY id HAVING cnt > 0;
    SELECT id AS "Customer identity" FROM table_name;

ANSI SQL が `WHERE` 節内でエイリアスを参照することを 許可していないことに注意してください。これは `WHERE` が実行される時点で 項目の値がまだ決定されていないからです。例えば、以下のクエリは あやまり です：

    SELECT id,COUNT(*) AS cnt FROM table_name WHERE cnt > 0 GROUP BY id;

どの行が `GROUP BY` に含まれるかを決めるために `WHERE` 構文が 実行される一方で、 得られた結果のどの行を使うか確定するために `HAVING` が使用されます。

### A.5.5 Deleting Rows from Related Tables

MySQL は現在 sub-select は未サポートで、また `DELETE` 構文で複数のテーブルを扱う事もサポートしていません。 したがって、２つのテーブルに関連するレコードを消すには、以下のようにして行います：

1. いくつかの `WHERE` 条件を使用して、基本となるテーブルから行を `SELECT`
2. 同じ条件下で、基本となるテーブルに含まれる行を `DELETE`
3. `DELETE FROM related_table WHERE related_column IN (selected_rows)`.

`related_column` のクエリの合計文字数が、1,048,576 (デフォルトは `max_ allowed_packet` の値) をこえる場合、 それをいくつかに分割して、複数の `DELETE` 構文にしなくてはなりません。

`related_column` がインデックスで、100-1000 の`related_column`だけを消 す場合、よりはやく `DELETE` できます。 もし `related_column` がインデックスでない場合、その速度は `IN` 節の引 数の数に無関係になります。

### A.5.6 Solving Problems with No Matching Rows

複雑なクエリーを行って、もしなんの結果も返さなければ、 そのクエリーの何が悪いかを見つけるため、以下の手続きを行います：

1. `EXPLAIN` を使用してクエリーをテストし、明白な間違いを見つけます。 「5.2.1 `EXPLAIN` 構文 (`SELECT`についての情報を得る)」節参照.
2. `WHERE` 節で使用されているフィールドだけを Select してみます
3. 結果が返ってくるまで、一つ一つクエリーからテーブルを取り除いていきます。 テーブルが大きい場合、`LIMIT 10` をクエリーで使用することは良くありません。
4. 行にマッチすべきであろう項を `SELECT` してみます。 その場合、select するのは、上記で最後に取り除いたテーブルに対して行います。
5. もし `FLOAT` か `DOUBLE` 型のものを数字と比較するなら、 `=` は使用しないでください！これはほとんどのコンピュータ言語において、 浮動小数点の値はぴったりの値にならないからです。

       mysql> SELECT * FROM table_name WHERE float_column=3.5;
          ->
       mysql> SELECT * FROM table_name WHERE float_column between 3.45 and 3.55;

   In most cases, changing the `FLOAT` to a `DOUBLE` will fix this!
6. もしなにも悪いところを見つけることができなかった場合、 小さなテストをつくって `mysql test < query.sql` を行ってみてください。 `mysqldump --quick database tables > query.sql` でテストファイルを作成でき ます。 このファイルをエディターで編集し、いくつかのinsert行を(多すぎるなら)消します。 そしてファイルの最後にselect構文を付け足します。 テストを行うには：

       shell> mysqladmin create test2
       shell> mysql test2 < query.sql

   `mysqlbug` を使用して mysql@lists.mysql.com にテストを投稿してくだ さい。

## A.6 Table Definition Related Issues

### A.6.1 Problems with `ALTER TABLE`.

`ALTER TABLE` changes a table to the current character set. If you during `ALTER TABLE` get a duplicate key error, then the cause is either that the new character sets maps to keys to the same value or that the table is corrupted, in which case you should run `REPAIR TABLE` on the table.

もし `ALTER TABLE` が以下のようなエラーで死んだ場合：

    Error on rename of './database/name.frm' to './database/B-a.frm' (Errcode: 17)

これは以前の `ALTER TABLE` で MySQL がクラッシュしており、 ``A-something'` か ``B-something'` という名前の、誤った情報を流している 古いテーブルが存在しています。 この場合、MySQL データディレクトリに入り、`A-` や `B-` で始まる 名前を持つファイルを全て消します。 (消す代わりにどこかに移動しても構いません。)

`ALTER TABLE` は以下のように動作します:

- 変更要求のあった ``A-xxx'` という名前の新しいテーブルを作成。
- 元のテーブル内の全ての行を ``A-xxx'` にコピー。
- 元のテーブルを ``B-xxx'` に名称変更。
- ``A-xxx'` は元のテーブル名に名称変更される。
- ``B-xxx'` は消去される。

もし名称変更の際に問題があると、MySQL は変更を取り消すように動きます。 致命的な問題が起きた場合(ありえませんが)、MySQL は元の古いテーブルを ``B-xxx'` という名前のままにしておきます。単にシステムレベルで名称変更すれば データは戻ります。

### A.6.2 テーブル中でフィールドの順序を入れ替える方法

SQLの主な目的はデータフォーマットからアプリケーションを切り離してしまうことにあります。そのため、常に取り出したいデータの順序を常に指定する必要があります。例えば、次のような文:

    SELECT col_name1, col_name2, col_name3 FROM tbl_name;

これは、`col_name1`, `col_name2`, `col_name3`, の順序でデータを返します。ここで、

    SELECT col_name1, col_name3, col_name2 FROM tbl_name;

こうすると、`col_name1`, `col_name3`, `col_name2`, の順序でデータを返します。

`SELECT *`やそのテーブル内での位置に依存してしまうような取り出し方はけっしてするべきではありません。というのは取り出されるデータの順序が常に保障されるものではないからです。単にフィールドの情報が変更されただけでアプリケーションがエラーが発生する可能性を有しているのです。

にもかかわらずフィールドの順序を変えたい場合には次のような方法があります。

1. 新しいテーブルを望んでいるフィールドの順序で作成します。
2. `INSERT INTO new_table SELECT fields-in-new_table-order FROM old_table`. を実行します。
3. `old_table`をドロップするかリネームして下さい。
4. `ALTER TABLE new_table RENAME old_table`. を実行します。

### A.6.3 TEMPORARY TABLE 問題

`TEMPORARY TABLES`を用いる処理における制限を以下に示します。

- テンポラリーテーブルでは`HEAP`か`ISAM`、`MyISAM`のいづれかの型のみを持つことが可能です。
- テンポラリーテーブルは一度のクエリで一回しか使用できません。例えば、次のようなものは動きません。

      select * from temporary_table, temporary_table as t2;

  上記の仕様はバージョン4.0では修正する予定になっています。
- `ALTER TABLE org_name RENAME new_name` は動作します。しかし、 `TEMPORARY`テーブルに`RENAME`を使用することはできません。 上記の仕様はバージョン4.0では修正する予定になっています。

Go to the first, previous, next, last section, table of contents.