MySQL (TM) ソフトウェアはとても高速で、マルチスレッド、マルチユーザの、頑丈な SQL
(Structured Query Language)データベースサーバです。
MySQL Server は、mass-deployed ソフトウェアへの組み込みのように、ミッションクリティ
カルで高負荷生産システム用に意図されています。
MySQL は MySQL AB の商標です。
MySQL ソフトウェア は Dual Licensed です。
あなたは、MySQL を GNU GENERAL PUBLIC LICENSE
(http://www.gnu.org/licenses/) に従って、
Open Source/Free Software として利用できます。
あるいは、GPL の条件が合わない場合には、
コマーシャルライセンスを MySQL AB から購入することも可能です。
「1.4 MySQL ライセンスとサポート」節参照.
MySQL ウェブサイト (http://www.mysql.com/) は MySQL ソフトウェア
についての最新情報を提供しています。
次のリストはマニュアルのいくつかの有用なセクションを説明しています:
MySQL Database Server の背景にある会社についての情報は、 「1.3 MySQL AB とは何か」節 を
参照してください。
MySQL Database Server の能力の説明については、 「1.2.2 MySQL の主な機能」節 を参照してください。
MySQL Database Software を新しいアーキテクチャや OS に移行するためのヒントについては
「E 他のシステムへの移植について」節 を参照してください。
MySQL Database Server 導入のチュートリアルについては、 「3 Tutorial Introduction」節 を参照してください。
SQL の例とベンチマーク情報についてはベンチマーキングのディレクトリを参照
してください。(`sql-bench' ディレクトリです)
Important:
エラー(バグ)レポート、質問、コメントは
メーリングリスト mysql@lists.mysql.com に送ってください。 「1.6.1.3 バグや問題を報告する方法」節参照。
バグレポートを生成するためには mysqlbug スクリプトを使用すべきです。
ソースディストリビューションでは、mysqlbug スクリプトは `scripts' ディレクトリ
に見つけることができます。バイナリディストリビューションでは、mysqlbug は
`bin' ディレクトリ(MySQL-server RPM パッケージでは `/usr/bin') に見つけることができます。
MySQL Server のセキュリティバグを発見した場合は、
security@mysql.com に email を送ってください。
これは MySQL のリファレンスマニュアルです; これは
MySQL バージョン 4.0.11-gamma について記述しています。
Functional changes are always
indicated with reference to the version, so this manual is also suitable
if you are using an older version of the MySQL software.
一般的な SQL やリレーショナルデータベース概念の説明書ではありません。
MySQL Database Software は発展中なので、マニュアルは頻繁に更新されます。そのため、
オンラインで参照しない限り、このバージョンが期限切れである可能性があります。
このマニュアルの最新バージョンは http://www.mysql.com/documentation/ に多
様な形式で置いてあります。
このマニュアルは現在 HTML, PDF, Windows HLP バージョンがあります。
プライマリドキュメントは Texinfo ファイルです。HTML バージョンは
texi2html の変更されたバージョンで自動的に提供されます。プレーン
テキストと Info バージョンは makeinfo で提供されます。PostScript
バージョンは texi2dvi と divps を使用して提供されます。PDF
バージョンは pdftex で提供されます。
マニュアル内の情報を見つけるのがつらいなら、 検索可能 バージョン http://www.mysql.com/doc/ を 試すことが可能です。
このマニュアルへの追加または修正に関連する提案がある場合は、それらを マニュアルチーム docs@mysql.com に 送ってください。
このマニュアルは当初、David Axmark, Michael (Monty) Widenius によって書かれました。 現在は Michael (Monty) Widenius, Arjen Lentz, Paul DuBois によって維持されています。他の貢献者については 「C Credits」節 を参照してください。
日本語訳は、以下の方々により行なわれました。 (ハンドル名だけ書きます。敬称略。翻訳サーバーに登録した順 :) )：
The copyright (2003) to this manual is owned by the Swedish company
MySQL AB. 「1.4.2 Copyrights and Licenses Used by MySQL」節参照.
このマニュアルは特定の印刷上の表記を使用しています:
constant
mysqladmin がどのように動作するかを見るためには、
--help オプションをつけて起動してください。''
コマンドが特定のプログラムによって実行されることを意味することを表す時、
コマンドと共に表示されるプロンプトによって、そのプログラムを表します。例えば、
shell> は、あなたのログインシェルから実行するコマンドを表し、
mysql> は mysql クライアントプログラムから実行するコマンドを表します:
シェルコマンドは Bourne シェル構文で示されます。csh 形式のシェ
ルを使用している場合は、わずかに変更してコマンドを発行する必要があるでしょ
う。例えば、環境変数を設定してコマンドを実行するシーケンスは、Bourne シェ
ル構文では次のようになります:
shell> VARNAME=value some_command
csh では、次のようなシーケンスを実行してください:
shell> setenv VARNAME value shell> some_command
データベース名, テーブル名, フィールド名はコマンドの中で置換しなければいけない
ことがよくあります。このような置換が必要なことを示すために、このマニュア
ルは db_name, tbl_name, col_name を使用します。
例えば、次のようなステートメントを見た場合:
mysql> SELECT col_name FROM db_name.tbl_name;
これは、同様のステートメントを入力するためには、おそらく次のように、あな た自身のデータベース名, テーブル名, フィールド名を供給することを意味します:
mysql> SELECT author_name FROM biblio_db.author_list;
SQL ステートメントは大文字でも小文字でも記述できます。このマニュアルで は大文字で記述します。
構文の説明中では、角括弧(`[' と `]')はオプションの単語や節であ
ることを示すために使用されます。in the following
statement, IF EXISTS is optional:
DROP TABLE [IF EXISTS] tbl_name
構文要素がいくつかのものからなる場合、垂直バー(`|')で区切られます。 選択セットから一つのメンバを選ぶことができるときは、角括弧中にリストされ ます。(`[' and `]'):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
選択セットから一つのメンバを選ぶ必要があるときは、波括弧(`{' と `}')中にリストされます:
{DESCRIBE | DESC} tbl_name {col_name | wild}
MySQLは、もっとも有名な オープンソース SQLデータベースで、
MySQL AB によって開発、供給されています。MySQL AB は
MySQL データベースに関わるサービスを提供するビジネスを構築する
営利会社です。 「1.3 MySQL AB とは何か」節参照.
MySQL ウェブサイト(http://www.mysql.com/)は、MySQL と MySQL AB に
ついての最新情報を提供しています。
MySQL はデータベース管理システムです。
MySQL サーバーのようなデータベース管理システムが必要です。コンピュー
タは大量のデータの処理にとても向いているので、データベース管理システムは
スタンドアロンユーティリティや他のアプリケーションの一部として、コンピュー
タの中で中心的な役割を演じています。
MySQL の SQL 部分は "構造化ク
エリ言語 (Structured Query Language)" を表しています。これは、データベー
スのアクセスに使用される最も有名な標準言語です。
オープンソース です。
オープンソースの意味は誰でも使用し変更することができるということです。誰
でも MySQL ソフトウェアをインターネットからダウンロードし、無償で使
用することができます。その気があれば誰でも必要に応じてソースコードを調べ、
変更することができます。MySQL ソフトウェア は GPL (GNU General Public License)
http://www.gnu.org/licenses/ に従います。これは、様々な状況でそ
のソフトウェアで行なえることと行なえないことを定義しています。もし GPL
を嫌だと感じていたり、MySQL を商用アプリケーションに組み込む必
要があるなら、商用ライセンス版を我々から購入することができます。
「1.4.3 MySQL Licenses」節参照.
MySQL Database Server はとても速く、信頼でき、簡単に使用できます。それがあなた
が探しているものなら、試してみるべきです。MySQL Server は、我々のユー
ザと協力して開発されたとても実用的な機能のセットを持っています。我々のベ
ンチマークページ上で、MySQL Server と他のいくつかのデータベース管理シ
ステムの性能比較を見つけることができます。 「5.1.4 The MySQL Benchmark Suite」節参照.
MySQL Server は、既存のソリューションよりも速くとても大きなデータベー
スを処理するために、そして、高い需要がある製品環境で何年間かの使用に耐え
るために、独創的に開発されました。一定の開発下で、MySQL Server は今日、
豊富でとても有用な機能セットを提供します。MySQL は、結合性、速
度、セキュリティでインターネット上でのデータベースアクセスに高く適合しま
す。
MySQL Database Software は、様々なバッ
クエンドをサポートするマルチスレッド SQL サーバ、いくつかのクライアント
プログラム、ライブラリ、管理ツール、プログラミングインタフェース(APIs)から成る
クライアント／サーバシステムです。
We also provide MySQL Server as a multi-threaded library which you
can link into your application to get a smaller, faster, easier-to-manage
product.
MySQL Database Server をサポートする、あなたの好きなアプリケー
ション／言語を見つけることができるでしょう。
MySQL の公式な発音は ``My Ess Que Ell'' です(MY-SEQUEL ではあり
ません)。
しかし MY-SEQUEL と発音する人を正すことは避けています。
最初は、我々固有の速くて低レベルな (ISAM) ルーチンを使用したテーブルへ
接続するために、 mSQL を使用するつもりでした。
しかし、いくつかのテストの後、我々は
mSQL は我々が必要とするほど高速ではなく、柔軟度を持っていないとの
結論に至りました。この結果、mSQL とほとんど同じ API インタフェー
スを持つ、我々のデータベースへの新しい SQL インタフェースに帰結しました。
この API はサードパーティコードの移植を簡単にするために選択されました。
MySQL の名前の由来は完全には明らかではありません。我々のベース
ディレクトリと多くのライブラリとツールは接頭辞 ``my'' を 10 年以上も使っ
ています。しかし、Monty の娘(何年か若い)も My という名前です。そのため、
この2つのどちらが MySQL に名前を与えたかは、我々にとっても未だ
謎です。
MySQL Database Software の重要な特徴のいくつかを以下の項目に挙げます。
「1.5 MySQL 4.x In A Nutshell」節参照.
MySQL は市販のメモリリーク検出製品 Purify と
Valgrind, a GPL tool (http://developer.kde.org/~sewardj/) で
テストされています。
FLOAT, DOUBLE, CHAR, VARCHAR,
TEXT, BLOB, DATE, TIME, DATETIME,
TIMESTAMP, YEAR, SET, ENUM 型.
「6.2 フィールド型」節参照.
INSERT を使用でき、明示的に値が与えられていないフィールドはそのデ
フォルト値が設定されます。
SELECT と WHERE 部内での全ての演算子と関数のサポー
ト。例:
mysql> SELECT CONCAT(first_name, " ", last_name)
-> FROM tbl_name
-> WHERE income/dependents > 10000 AND age > 30;
GROUP BY と ORDER BY 節の完全なサポート。グループ関数
(COUNT(), COUNT(DISTINCT ...),
COUNT(DISTINCT ...),
AVG(), STD(),
SUM(), MAX() and MIN() ) のサポート。
LEFT OUTER JOIN , RIGHT OUTER JOIN のサポート。
DELETE, INSERT, REPLACE, UPDATE は
変更された(影響を受けた)行の数を返します。
サーバ接続時にフラグを設定することにより、代わりに適合したレコード数を返す
ことも可能です。
MySQL 固有の SHOW コマンドはデータベース、テーブル、イン
デックスについての情報を取出すために使用できます。EXPLAIN コマン
ドはオプティマイザがどのようにクエリを解析するかを決定するために使用
できます。
ABS は正しいフィールド
名です。制限は、関数呼び出しに、関数名とそれに続く `(' の間に空白が
許されないことだけです。 「6.1.7 Is MySQL Picky About Reserved Words?」節参照.
MySQL Server を使用しているユーザを知っています。
MySQL Server のコンパイル時に変更できます)。インデックスは
CHAR または VARCHAR フィールドの先頭部分を使用できます。
MySQL サーバと接続します。
ODBC (Open-DataBase-Connectivity) (ソースつき)。全ての ODBC
2.5 関数と他の多く。あなたの MySQL サーバに接続するために、例え
ば Access を使用できます。 「8.3 MySQL ODBC サポート」節参照.
MySQL サーバー起動時に、選択されたキャラクターセットに
に従って行なわれます。(デフォルトは、スウェーデン語の方法)。
ソース内に新しいソート順序配列を追加することで、こ
れは変更可能です。とても先進的なソートの例を見るには、Czech ソートコード
を見てください。 MySQL Server は多くの種類のキャラクタセットをサポート
し、コンパイル時や実行時に指定できます。
myisamchk を含んでいます。これは、テーブル検査、最適化、修復のため
のとても速いユーティリティです。
All of the functionality of myisamchk
is also available through the SQL interface as well.
「4 Database Administration」節参照.
MySQL プログラムはオンラインヘルプを得るために、
--help と -? オプションで呼び出すことができます。
この節では、``MySQL Server はどれくらい安定か？'' と ``私はこのプロジェ クトの MySQL Server に依存できるか？'' という質問について回答します。
我々はここで、いくつかの問題を明らかにし、多くの人に関係すると思われるさ らに重要な質問のいくつかを回答することを試みます。この節は、メーリングリ スト(そこではとても活発にバグが報告されています)から取り込まれた情報が一 緒に置かれています。
Original code stems back from the early '80s, providing a stable code
base, and the ISAM table format remains backward-compatible.
TcX (MySQL AB の前身)では、MySQL は 1996 中頃から我々のプロジェクトで何の問題も
なく動いていました。MySQL Database Software が広く公にリリースされた時、我々は、MySQL 内
に ``テストされていないコード'' の部分があることに注意しました。これは、
我々とは異なる方法でクエリを作成する新しいユーザによってすぐに見つけられました。
新しい各リリースは、(多くの新しい機能を持っているのに)前のものよりも問題
は少なくなります。そして次のリリースの一つを ``安定'' と呼ぶことができるよ
うに我々は望んでいます。
MySQL Server の各リリースは実用的で、ユーザが ``グレイゾーン'' からの
コードの使用を開始する時にだけ問題があります。当然、外部のユーザは、何が
グレイゾーンかを知ることができません; この節で現在知られているこれらを示
してみます。
説明は MySQL Server の 3.23.x バージョンで扱われます。知られていて報告
されているバグは全て最新のバージョンで修正されています。bugs 節に
書かれているバグは除きます。それらは ``設計'' 関連のものです。 「1.7.5 Known Errors and Design Deficiencies in MySQL」節参照.
MySQL Server は複数の階層と様々な独立モジュールで書かれています。これ
らのモジュールは、それぞれがどのようにテストされているかとともに次にリス
トされています:
MySQL 4.x でも引き続き行われます。
InnoDB tables -- Stable (in 3.23 from 3.23.49)
InnoDB storage engines は MySQL 3.23 ツリーでは version 3.23.49 から安定です。
InnoDB は大規模で負荷の大きい製品システムで使用されています。
BDB tables -- Gamma
Berkeley DBはとても安定したコードですが未だに BDB トランザクション
storage engines インターフェースが MySQL Server では改良を加えている途中であり、
他のテーブルタイプと同等に扱われるまでにはもう少し時間がかかりそうです。
FULLTEXT -- Beta
MySQL 4.0.
MyODBC 2.50 (uses ODBC SDK 2.5) -- Gamma
MyISAM tables -- Gamma
MyISAM storage
engine that checks if the table was closed properly on open and
executes an automatic check/repair of the table if it wasn't.
MyISAM tables in MySQL 4.0 for faster
insert of many rows.
fcntl()) を使用するため大きな問題があります。これらの場合では、
MySQL デーモンを --skip-external-locking フラグつきで動かすべ
きです。知られている問題は、いくつかの Linux システムと NFS マウントされ
たファイルシステム使用時の SunOS です。
MySQL AB は代金を支払った顧客のために 高サポートを提供しています。しかし
MySQL メーリングリストは通常、全ての一般的な質問に回答を提供し
ています。バグは通常すぐにパッチで修正され、深刻なバグには、ほとんどいつ
も新しいリリースがあります。
MySQL Version 3.22では、最大テーブルサイズに 4Gbyte という制限がありました。
MySQL Version 3.23から採用された新しい MyISAM では、
最大テーブルサイズは800万テラバイト( 2 ^ 63 bytes )に拡張されました。
ただし、OSの側にも、ファイルサイズの制限が存在していることには注意して下さい。 いくつか例を示します：
| Operating System | File Size Limit |
| Linux-Intel 32 bit | 2G, 4G あるいはそれ以上, Linux のバージョンによる。 |
| Linux-Alpha | 8T (?) |
| Solaris 2.5.1 | 2G (パッチにより 4G に対応) |
| Solaris 2.6 | 4G (can be changed with flag) |
| Solaris 2.7 Intel | 4G |
| Solaris 2.7 UltraSPARC | 512G |
Linux 2.2 では、ext2ファイルシステム用のLFSパッチを適用することで、 2G 以上のテーブルを使用することができます。 Linux 2.4ではReiserFS用の同様のパッチが存在し、大きなファイルを扱うことができるようになります。 (訳注： Linux 2.4.1 以上では、最初から ReiserFS がカーネルのソースに組み込まれていますし、 2.4.16 以上では、ext3 もカーネルのソースに組み込まれました)
以上からわかるように、MySQL の最大テーブルサイズはOSの制限によって決まることがほとんどです。
デフォルトでは、MySQL の最大テーブルサイズは4Gに設定されています。
あるテーブルの最大テーブルサイズは、SHOW TABLE STATUS コマンドか、
myisamchk -dv table_name によって確認することができます。
「4.5.6 SHOW 構文」節参照.
もしも4G 以上のテーブルが必要な場合には（加えて、OSがそれをサポートしている場合には）、
テーブルを作る際に、AVG_ROW_LENGTH と MAX_ROWS パラメータを設定することができます。
「6.5.3 CREATE TABLE 構文」節参照.
テーブル作成後に、ALTER TABLE で変更することもできます。 「6.5.4 ALTER TABLE 構文」節参照
読み込み専用の大きなテーブルが必要な時は、
myisampackを使って複数のテーブルを一つにまとめた上で圧縮することができます。
myisampackは、テーブルの大きさをだいたい50%程度まで圧縮できます。
結果として、より大きなテーブルを作ることが可能となるでしょう。 「4.7.4 myisampack, MySQL の圧縮された読み込み専用テーブルジェネレータ」節参照.
MyISAMデータファイルに対する、OSのファイル制限を回避するのに、
RAID オプションを使うこともできます。 「6.5.3 CREATE TABLE 構文」節参照.
MERGE ライブラリ -- 同じ構造のテーブルをひとまとめに扱う機能を提供します -- を
使用するという解決法も考えられるでしょう。 「7.2 MERGE Tables (3.23.25以上)」節参照.
MySQL Server 自身は 2000 年問題(Y2K)に対して何の問題も持っていません:
MySQL Server は UNIX 時間関数を使用し、2069 年まで日付には何の
問題もありません; 全ての2桁の年は 1970 から 2069 の範囲に
あると見なされます。これは、year フィールド内に 01 を格納する場
合、MySQL Server はそれを 2001 として扱うということを意味します。
MySQL 日付関数は一つのファイル `sql/time.cc' に格納
され、2000年安全にとても注意深くコード化されています。
MySQL 3.22 以降のバージョンでは、新しい YEAR フィールド型は
0 と 1901 から 2155 までの年を1バイトで格納でき、2
桁または4桁で表示できます。
2000年安全でない方法で MySQL Server を使用するアプリケーションでは問題
になります。例えば、多くの古いアプリケーションは4桁値ではなく2桁値(これ
は曖昧です)を使用して年を格納し操作します。この問題は、00 または
99 のような値を ``欠けている'' 値の表われとして使用するアプリケー
ションによって作られます。
あいにく、これらの問題を修正するのは困難です。様々なアプリケーションが様々 なプログラムによって書かれていて、その各々が慣習と日付操作関数の様々な組 み合わせを使用するからです。
これは、MySQL Server が 2030 年までの日付に何の問題もないことを示す簡単なテスト
です:
mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date DATE,
-> date_time DATETIME,
-> time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
-> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
-> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
-> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
-> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
-> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
-> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
-> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
-> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
-> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
-> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
-> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
-> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
-> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)
これは、DATE と DATETIME 型は未来のいかなる日付において
問題のないことををしめします (これら日付は 9999 年まで扱えます)
TIMESTAMP 型は、時刻を保存しますが、2030-01-01 までです。
TIMESTAMP は 32-bit マシンで(signed value)は 1970 から 2030 の範囲です。
64-bit マシンでは、 2106 年(unsigned value)まで扱えれます。
MySQL Server は 2000年対応ですが、曖昧でない入力を提供するのはあなたの
責任です。曖昧な日付の入力データ（2桁の年の値）の扱いについての
MySQL Server の規則については 「6.2.2.1 西暦２０００年問題とデータ型」節 を参照してください。
MySQL AB は、MySQL の創始者と主な開発者の会社です。
MySQL AB was originally established in Sweden by David
Axmark, Allan Larsson and Michael Monty Widenius.
All the developers of the MySQL server are employed by the company.
We are a virtual organisation with people in a dozen countries around
the world. We communicate extensively over the Net every day with each
other and with our users, supporters and partners.
我々は、MySQL の開発と我々
のデータベースを新しいユーザに広げることに専念しています。MySQL AB は
MySQLサーバソースコードの著作権, MySQL logo の著作権, MySQL 商標権,
このMySQL マニュアルの著作権を所有します。
「1.2 MySQL とは何か」節参照.
The MySQL core values show our dedication to MySQL and
Open Source.
我々は MySQL Database Software を次のようにしたいです。
MySQL AB と MySQL AB の人々は次を行ないます。
オープンソース 哲学を進展させ、オープンソース コミュニティをサポートする
MySQL ウェブサイト(http://www.mysql.com/)は、MySQL と MySQL AB に ついての最新情報を提供しています。
One of the most common questions we encounter is: ``How can you make a living from something you give away for free?'' This is how.
MySQL AB makes money on support, services, commercial licenses,
and royalties, and we use these revenues to fund product development
and to expand the MySQL business.
The company has been profitable since its inception. In October 2001, we accepted venture financing from leading Scandinavian investors and a handful of business angels. This investment is used to solidify our business model and build a basis for sustainable growth.
MySQL AB is run and owned by the founders and main developers of
the MySQL database. The developers are committed to giving support
to customers and other users in order to stay in touch with their needs
and problems. All our support is given by qualified developers. Really
tricky questions are answered by Michael Monty Widenius, principal
author of the MySQL Server.
「1.4.1 Support Offered by MySQL AB」節参照.
For more information and ordering support at various levels, see http://www.mysql.com/support/ or contact our sales staff at sales@mysql.com.
MySQL AB delivers MySQL and related training worldwide.
We offer both open courses and in-house courses tailored to the
specific needs of your company. MySQL Training is also available
through our partners, the Authorised MySQL Training Centers.
Our training material uses the same example databases as our
documentation and our sample applications, and it is always updated
to reflect the latest MySQL version. Our trainers are backed by
the development team to guarantee the quality of the training and the
continuous development of the course material. This also ensures
that no questions raised during the courses remain unanswered.
Attending our training courses will enable you to achieve your goals
related to your MySQL applications. You will also:
MySQL Certification.
If you are interested in our training as a potential participant or as a training partner, please visit the training section at http://www.mysql.com/training/ or contact us at: training@mysql.com.
For details about the MySQL Certification Program, please see
http://www.mysql.com/certification/.
MySQL AB and its Authorised Partners offer consulting
services to users of MySQL Server and to those who embed
MySQL Server in their own software, all over the world.
Our consultants can help you design and tune your databases, construct
efficient queries, tune your platform for optimal performance, resolve
migration issues, set up replication, build robust transactional
applications, and more.
We also help customers embed MySQL Server in their products and
applications for large-scale deployment.
Our consultants work in close collaboration with our development team,
which ensures the technical quality of our professional services.
Consulting assignments range from 2-day power-start sessions to
projects that span weeks and months. Our expertise not only covers
MySQL Server, but also extends into programming and scripting
languages such as PHP, Perl, and more.
If you are interested in our consulting services or want to become a consulting partner, please visit the consulting section of our web site at http://www.mysql.com/consulting/ or contact our consulting staff at consulting@mysql.com.
The MySQL database is released under the
GNU General Public License (GPL).
This means that the MySQL software can be used free of charge
under the GPL. If you do not want to be bound by the GPL
terms (like the requirement that your own application becomes GPL
as well), you may purchase a commercial license for the same product
from MySQL AB.
See http://www.mysql.com/products/pricing.html.
Since MySQL AB owns the copyright to the MySQL source code,
we are able to employ Dual Licensing which means that the same
product is available under GPL and under a commercial
license. This does not in any way affect the Open Source
commitment of MySQL AB. For details about when a commercial
license is required, please see 「1.4.3 MySQL Licenses」節.
We also sell commercial licenses of third-party Open Source GPL
software that adds value to MySQL Server. A good example is the
InnoDB transactional storage engine that offers ACID
support, row-level locking, crash recovery, multi-versioning, foreign
key support, and more. 「7.5 InnoDB テーブル (3.23.6以上)」節参照.
MySQL AB has a worldwide partner programme that covers training
courses, consulting & support, publications plus reselling and
distributing MySQL and related products. MySQL AB Partners
get visibility on the http://www.mysql.com/ web site and the right
to use special versions of the MySQL trademarks to identify their
products and promote their business.
If you are interested in becoming a MySQL AB Partner, please e-mail
partner@mysql.com.
The word MySQL and the MySQL dolphin logo are trademarks of
MySQL AB. 「1.4.4 MySQL AB Logos and Trademarks」節参照.
These trademarks represent a significant value that the MySQL
founders have built over the years.
The MySQL web site (http://www.mysql.com/) is popular among
developers and users. In October 2001, we served 10 million page views.
Our visitors represent a group that makes purchase decisions and
recommendations for both software and hardware. Twelve percent of our
visitors authorise purchase decisions, and only nine percent are not
involved in purchase decisions at all. More than 65% have made one or
more online business purchase within the last half-year, and 70% plan
to make one in the next months.
The MySQL web site (http://www.mysql.com/)
provides the latest information about MySQL and MySQL AB.
For press service and inquiries not covered in our News releases (http://www.mysql.com/news/), please send e-mail to press@mysql.com.
If you have a valid support contract with MySQL AB, you will
get timely, precise answers to your technical questions about the
MySQL software. For more information, see 「1.4.1 Support Offered by MySQL AB」節.
On our website, see http://www.mysql.com/support/, or send
an e-mail message to sales@mysql.com.
For information about MySQL training, please visit the training
section at http://www.mysql.com/training/. If you have
restricted access to the Internet, please contact the MySQL AB
training staff at training@mysql.com.
「1.3.1.2 Training and Certification」節参照.
For information on the MySQL Certification Program, please see
http://www.mysql.com/certification/.
「1.3.1.2 Training and Certification」節参照.
If you're interested in consulting, please visit the consulting
section at http://www.mysql.com/consulting/. If you have
restricted access to the Internet, please contact the MySQL AB
consulting staff at consulting@mysql.com.
「1.3.1.3 Consulting」節参照.
Commercial licenses may be purchased online at
https://order.mysql.com/. There you will also find information
on how to fax your purchase order to MySQL AB. More information
about licensing can be found at
http://www.mysql.com/products/pricing.html.
If you have
questions regarding licensing or you want a quote for a high-volume
license deal, please fill in the contact form on our web site
(http://www.mysql.com/) or send an e-mail message
to licensing@mysql.com (for licensing questions) or to
sales@mysql.com (for sales inquiries).
「1.4.3 MySQL Licenses」節参照.
If you represent a business that is interested in partnering with
MySQL AB, please send e-mail to partner@mysql.com.
「1.3.1.5 Partnering」節参照.
For more information on the MySQL trademark policy, refer to
http://www.mysql.com/company/trademark.html or send e-mail to
trademark@mysql.com.
「1.4.4 MySQL AB Logos and Trademarks」節参照.
If you are interested in any of the MySQL AB jobs listed in our
jobs section (http://www.mysql.com/company/jobs/),
please send an e-mail message to jobs@mysql.com.
Please do not send your CV as an attachment, but rather as plain text
at the end of your e-mail message.
For general discussion among our many users, please direct your attention to the appropriate mailing list. 「1.6.1 MySQL Mailing Lists」節参照.
Reports of errors (often called bugs), as well as questions and
comments, should be sent to the mailing list at
mysql@lists.mysql.com. If you have found a sensitive
security bug in the MySQL Server, please send an e-mail
to security@mysql.com.
「1.6.1.3 バグや問題を報告する方法」節参照.
If you have benchmark results that we can publish, please contact us at benchmarks@mysql.com.
If you have any suggestions concerning additions or corrections to this manual, please send them to the manual team at docs@mysql.com.
For questions or comments about the workings or content of the
MySQL web site (http://www.mysql.com/),
please send e-mail to webmaster@mysql.com.
MySQL AB has a privacy policy, which can be read at
http://www.mysql.com/company/privacy.html.
For any queries regarding this policy, please e-mail
privacy@mysql.com.
For all other inquires, please send e-mail to info@mysql.com.
(訳注： ライセンスの章については、正確さをきすため原文を併記しています。 訳文だけでなく原文に目を通してください。 もし意味の取違いを見つけたなら、takeshi@SoftAgency.co.jp に連絡してください。)
このセクションでは、MySQLのサポートとライセンス規定について説明します。
Technical support from MySQL AB means individualised answers
to your unique problems direct from the software engineers who code
the MySQL database engine.
We try to take a broad and inclusive view of technical support. Almost
any problem involving MySQL software is important to us if it's
important to you.
Typically customers seek help on how to get different commands and
utilities to work, remove performance bottlenecks, restore crashed
systems, understand operating system or networking impacts on MySQL,
set up best practices for backup and recovery, utilise APIs, etc.
Our support covers only the MySQL server and our own utilities,
not third-party products that access the MySQL server, though we
try to help with these where we can.
Detailed information about our various support options is given at http://www.mysql.com/support/, where support contracts can also be ordered online. If you have restricted access to the Internet, contact our sales staff at sales@mysql.com.
Technical support is like life insurance. You can live happily
without it for years, but when your hour arrives it becomes
critically important, yet it's too late to buy it!
If you use MySQL Server for important applications and encounter
sudden troubles, it might take too long to figure out all the answers
yourself. You may need immediate access to the most experienced
MySQL troubleshooters available, those employed by MySQL AB.
MySQL AB owns the copyright to the MySQL source code,
the MySQL logos and trademarks and this manual.
「1.3 MySQL AB とは何か」節参照.
Several different licenses are relevant to the MySQL
distribution:
MySQL-specific source in the server, the mysqlclient
library and the client, as well as the GNU readline library
is covered by the GNU General Public License.
「H GNU General Public License」節参照.
The text of this license can also be found as the file `COPYING'
in the distributions.
GNU getopt library is covered by the
GNU Lesser General Public License.
「I GNU Lesser General Public License」節参照.
regexp library) are covered
by a Berkeley-style copyright.
MySQL (3.22 and earlier) are subject to a
more strict license
(http://www.mysql.com/products/mypl.html).
See the documentation of the specific version for information.
GPL-style license.
Use of the manual is subject to the following terms:
MySQL AB is required.
For information about how the MySQL licenses work in practice,
please refer to 「1.4.3 MySQL Licenses」節.
Also see 「1.4.4 MySQL AB Logos and Trademarks」節.
The MySQL software is released under the
GNU General Public License (GPL),
which probably is the best known Open Source license.
The formal terms of the GPL license can be found at
http://www.gnu.org/licenses/.
See also http://www.gnu.org/licenses/gpl-faq.html and
http://www.gnu.org/philosophy/enforcing-gpl.html.
Since the MySQL software is released under the GPL,
it may often be used for free, but for certain uses you may want
or need to buy commercial licenses from MySQL AB at
https://order.mysql.com/.
See http://www.mysql.com/products/licensing.html for
more information.
Older versions of MySQL (3.22 and earlier) are subject to a
more strict license
(http://www.mysql.com/products/mypl.html).
See the documentation of the specific version for information.
古いバージョンの MySQL (3.22 とそれ以前) は
より制限されたライセンスを有していることに気をつけて下さい
(http://www.mysql.com/support/arrangements/mypl.html)。
より詳しくは、それぞれのバージョンに添付のドキュメントを御覧下さい。
Please note that the use of the MySQL software under commercial
license, GPL, or the old MySQL license does not
automatically give you the right to use MySQL AB trademarks.
「1.4.4 MySQL AB Logos and Trademarks」節参照.
The GPL license is contagious in the sense that when a program
is linked to a GPL program all the source code for all the parts
of the resulting product must also be released under the GPL.
Otherwise you break the license terms and forfeit your right to use the
GPL program altogether and also risk damages.
You need a commercial license:
GPL code from the MySQL
software and don't want the resulting product to be GPL, maybe
because you want to build a commercial product or keep the added
non-GPL code closed source for other reasons. When purchasing
commercial licenses, you are not using the MySQL software under
GPL even though it's the same code.
GPL application that only works with the
MySQL software and ship it with the MySQL software. This type
of solution is actually considered to be linking even if it's done over
a network.
MySQL software without providing
the source code as required under the GPL license.
MySQL
database even if you don't formally need a commercial license.
Purchasing support directly from MySQL AB is another good way
of contributing to the development of the MySQL software, with
immediate advantages for you.
「1.4.1 Support Offered by MySQL AB」節参照.
If you require a license, you will need one for each installation of the
MySQL software. This covers any number of CPUs on a machine, and there
is no artificial limit on the number of clients that connect to the server
in any way.
For commercial licenses, please visit our website at http://www.mysql.com/products/licensing.html. For support contracts, see http://www.mysql.com/support/. If you have special needs or you have restricted access to the Internet, please contact our sales staff at sales@mysql.com.
You can use the MySQL software for free under the GPL if
you adhere to the conditions of the GPL.
For more complete coverage of the common questions about the GPL
see the generic FAQ from the Free Software Foundation at
http://www.gnu.org/licenses/gpl-faq.html.
Some common cases:
MySQL
source code under the GPL with your product.
MySQL source code bundled with other
programs that are not linked to or dependent on the MySQL system
for their functionality even if you sell the distribution commercially.
This is called mere aggregation in the GPL license.
MySQL
system, you can use it for free.
MySQL servers for your customers.
However, we do encourage people to use ISPs that have MySQL support,
as this will give them the confidence that if they have some problem
with the MySQL installation, their ISP will in fact have the
resources to solve the problem for them.
Note that even if an ISP does not have a commercial license for
MySQL Server, they should at least give their customers read
access to the source of the MySQL installation so that the
customers can verify that it is patched correctly.
MySQL Database Software in conjunction with a
web server, you do not need a commercial license (so long as it is not
a product you distribute). This is true even if you run a commercial
web server that uses MySQL Server, because you are not
distributing any part of the MySQL system. However, in this
case we would like you to purchase MySQL support because the
MySQL software is helping your enterprise.
If your use of MySQL database software does not require a commercial
license, we encourage you to purchase support from MySQL AB anyway.
This way you contribute toward MySQL development and also gain
immediate advantages for yourself. 「1.4.1 Support Offered by MySQL AB」節参照.
If you use the MySQL database software in a commercial context
such that you profit by its use, we ask that you further the development
of the MySQL software by purchasing some level of support. We feel
that if the MySQL database helps your business, it is reasonable to
ask that you help MySQL AB.
(Otherwise, if you ask us support questions, you are not only using
for free something into which we've put a lot a work, you're asking
us to provide free support, too.)
Many users of the MySQL database want to display the
MySQL AB dolphin logo on their web sites, books, or
boxed products. We welcome and encourage this, although it should be
noted that the word MySQL and the MySQL dolphin logo
are trademarks of MySQL AB and may only be used as stated in
our trademark policy at
http://www.mysql.com/company/trademark.html.
The MySQL dolphin logo was designed by the Finnish advertising
agency Priority in 2001. The dolphin was chosen as a suitable symbol
for the MySQL database since it is a smart, fast, and lean animal,
effortlessly navigating oceans of data. We also happen to like dolphins.
The original MySQL logo may only be used by representatives of
MySQL AB and by those having a written agreement allowing them
to do so.
We have designed a set of special Conditional Use logos that may be
downloaded from our web site at
http://www.mysql.com/press/logos.html
and used on third-party web sites without written permission from
MySQL AB.
The use of these logos is not entirely unrestricted but, as the name
implies, subject to our trademark policy that is also available on our
web site. You should read through the trademark policy if you plan to
use them. The requirements are basically:
MySQL AB, are the creator and
owner of the site that displays the MySQL trademark.
MySQL AB
or to the value of MySQL AB trademarks. We reserve the right to
revoke the right to use the MySQL AB trademark.
MySQL database under GPL in an
application, your application must be Open Source and
be able to connect to a MySQL server.
Contact us at trademark@mysql.com to inquire about special arrangements to fit your needs.
In the following cases you need a written permission from MySQL AB
before using MySQL logos:
MySQL AB logo anywhere except on your web site.
MySQL AB logo except the Conditional Use
logos mentioned previously on web sites or elsewhere.
Out of legal and commercial reasons we have to monitor the use of MySQL
trademarks on products, books, etc. We will usually require a fee for
displaying MySQL AB logos on commercial products, since we think
it is reasonable that some of the revenue is returned to fund further
development of the MySQL database.
MySQL partnership logos may only be used by companies and persons
having a written partnership agreement with MySQL AB. Partnerships
include certification as a MySQL trainer or consultant.
Please see 「1.3.1.5 Partnering」節.
MySQL in Printed Text or Presentations
MySQL AB welcomes references to the MySQL database, but
note that the word MySQL is a trademark of MySQL AB.
Because of this, you should append the trademark symbol (TM) to
the first or most prominent use of the word MySQL in a text and
where appropriate, state that MySQL is a trademark of
MySQL AB. Please refer to our trademark policy at
http://www.mysql.com/company/trademark.html for details.
MySQL in Company and Product Names
Use of the word MySQL in product or company names or in Internet
domain names is not allowed without written permission from MySQL AB.
Long promised by MySQL AB and long awaited by our users,
MySQL Server 4.0 is now available in beta version for download from
http://www.mysql.com/ and our mirrors.
Main new features of MySQL Server 4.0 are geared toward our existing business and community users, enhancing the MySQL database software as the solution for mission-critical, heavy-load database systems. Other new features target the users of embedded databases.
MySQL is starting from 4.0.6 been labelled gamma, which means that 4.0.x has been available more than 2 months (first in alpha and then in beta) without any found serious hard to fix bugs and should now be ready for production use.
We will drop the gamma prefix when MySQL 4.0 has been out for more than a month without any serious bugs.
Further new features are being added in MySQL 4.1, which is now available from our bk source tree, and is targeted for alpha release in first quarter of 2003. 「2.3.4 開発ソースツリーからのインストール」節参照.
All binary releases pass our extensive test suite without any errors on any of the platforms we test on. MySQL 4.0 has been tested on by a large number of users and is in production used by several big sites.
libmysqld makes MySQL Server suitable for a vastly expanded realm of
applications.
組み込み MySQL サーバーライブラリを使用することで、
MySQL を色々なアプリケーション、電子機器
(それらにデータベースが利用されている事などは
エンドユーザーが気にすることはない)
に埋め込むことが可能です。
組み込み MySQL は、
インターネットのアプリケーションや、キオスク、
ハードウェア、ソフトウェアを組み合わせた物、
高パフォーマンスのインターネットサーバー、
CD-ROMに全てが収まっているデータベース、
などの裏方での利用に最適です。
Many users of libmysqld will benefit from the MySQL
Dual Licensing. For those not wishing to be bound by the GPL,
the software is also made available under a commercial license.
The embedded MySQL library uses the same interface as the normal
client library, so it is convenient and easy to use. 「8.4.9 libmysqld, the Embedded MySQL Server Library」節参照.
INSERTs, searching on packed indexes, creation of
FULLTEXT indexes, as well as COUNT(DISTINCT).
InnoDB storage engine is now offered as a feature of the
standard MySQL server, including full support for transactions
and row-level locking.
latin1_de, which corrects the German sorting order,
placing German umlauts in the same order as German telephone books.
TRUNCATE TABLE (like in Oracle) and IDENTITY as a
synonym for automatically incremented keys (like in Sybase). Many users will
also be happy to learn that MySQL Server now supports the UNION statement,
a long-awaited standard SQL feature.
DELETE and UPDATE statements.
By adding support for symbolic linking to MyISAM on the table
level (and not just the database level as before), as well as by enabling symlink
handling by default on Windows, we hope to show that we take enhancement
requests seriously.
Functions like SQL_CALC_FOUND_ROWS and FOUND_ROWS() make it
possible to know how many rows a query would have returned without a
LIMIT clause.
For the upcoming MySQL Server 4.x releases, expect the following features now still under development:
fail-safe replication;
already existing in 4.0, the LOAD DATA FROM MASTER command
will soon automate slave setup. The online backup will make
it easy to add a new replication slave without taking down
the master, and have a very low performance penalty on
update-heavy systems.
mysqld parameters (startup options) can soon be set without
taking down the servers.
FULLTEXT search properties of MySQL Server 4.0 enable the
use of FULLTEXT indexing of large text masses with both binary and
natural-language searching logic. Users can customise minimal word
length and define their own stop word lists in any human language,
enabling a new set of applications to be built on MySQL Server.
key cache.
MySQL command help
in the client.
MySQL Server 4.0 lays the foundation for the new features of
MySQL Server 4.1 and onward, such as nested subqueries (4.1),
stored procedures (5.0), and
foreign key integrity rules for MyISAM tables (5.0),
which form the top of the wish list for many of our customers.
After those additions, critics of the MySQL Database Server have to be more imaginative than ever in pointing out deficiencies in the MySQL Database Management System. For long already known for its stability, speed, and ease of use, MySQL Server will then match the requirement checklist of very demanding buyers.
This section introduces you to the MySQL mailing lists, and gives some guidelines as to how to use them. By subscribing to a mailing list, you will receive as e-mail messages all other postings on the list, and you will be able to send in your own questions and answers.
メイン MySQL メーリングリストを購読するには、メッセージを 電子メールアドレス mysql-subscribe@lists.mysql.com に送ってください。
メイン MySQL メーリングリストの購読の中止は、メッセージを 電子メールアドレス mysql-unsubscribe@lists.mysql.com に送ってください。
メッセージを送る先のアドレスだけが重要です。メッセージのサブジェクトと 本文は無視されます。
もし、あなたのリプライアドレスが妥当な物でない場合、アドレスを明確に指定することが出来ます。
subscribe あるいは unsubscribe のあとにハイフンを付け、そのあとにあなたの
アドレスを記述します。ただし `@' 文字は `=' に置き変えて書きます。
例えば、 your_name@host.domain で購読したい場合、
mysql-subscribe-your_name=host.domain@lists.mysql.com 宛にメッセージを送ります。
mysql-subscribe@lists.mysql.com や mysql-unsubscribe@lists.mysql.com へのメールは ezmlm メーリングリストプロセッサによって自動的に処理されます。 ezmlm についての情報は ezml ウェブサイトを参考してください (http://www.ezmlm.org/)
本メーリングリストへの投稿を行うには、mysql@lists.mysql.com にメッセージを送ります。
しかし、subscribe あるいは unsubscribe のメールを
mysql@lists.mysql.com に送らないでください。
これらのアドレスへ送られたメールは、何千ものユーザーに配送されてしまいます。
あなたのローカルサイトが多くの mysql@lists.mysql.com 購読者を持つことも
あります。この場合、ローカルメーリングリストを作り、lists.mysql.com からの
一つのメッセージがそのサイトに送られ、ローカルなリストで複写されるように
してください。この場合、ローカルの MySQL リストへの追加と削除は、
あなたのシステム管理者に問い合わせて下さい。
あなたのメーラーでMySQL メーリングリストからのメールを
適切なメールボックスへ振り分けるには、
（振り分け用の）フィルタをメッセージヘッダを頼りに動作するよう設定して下さい。
その場合、List-ID: ヘッダか Delivered-To: ヘッダが
識別の役に立つことでしょう。
次の MySQL メーリングリストがあります:
announce-subscribe@lists.mysql.com announce
mysql-subscribe@lists.mysql.com mysql
mysql-digest-subscribe@lists.mysql.com mysql-digest
mysql リストです。
このリストからは、一日分の全てのメッセージががまとめられた（ダイジェスト）形式で送られてきます。
bugs-subscribe@lists.mysql.com bugs
mysqlbug を使
用して投稿すべきです(Windows 上で実行している場合は、OS と
MySQL バージョンの記述を含めるべきです)。
できれば投稿前にMySQL の最新の安定バージョンか開発バージョンを使用して
問題をテストしてください！
含められたテストケース上で、mysql test < script を使
用することで、誰もがバグを再現できるべきです。このリストに投稿された全て
のバグは、次の MySQL リリースで修正されるかドキュメント化されま
す！ 小さなコードの変更だけですめば、我々はこの問題を修正するパッチの投
稿も行ないます。
bugs-digest-subscribe@lists.mysql.com bugs-digest
bugs リストです。
internals-subscribe@lists.mysql.com internals
internals-digest-subscribe@lists.mysql.com internals-digest
internals リストのダイジェスト版です。
java-subscribe@lists.mysql.com java
java-digest-subscribe@lists.mysql.com java-digest
java リストのダイジェスト版です。
win32-subscribe@lists.mysql.com win32
win32-digest-subscribe@lists.mysql.com win32-digest
win32 リストのダイジェスト版です。
myodbc-subscribe@lists.mysql.com myodbc
myodbc-digest-subscribe@lists.mysql.com myodbc-digest
myodbc リストのダイジェスト版です。
mysqlcc-subscribe@lists.mysql.com mysqlcc
MySQL Control Center graphical client 全般についてのリストです。
mysqlcc-digest-subscribe@lists.mysql.com mysqlcc-digest
mysqlcc リストのダイジェスト版です。
A digest version of the mysqlcc list.
plusplus-subscribe@lists.mysql.com plusplus
plusplus-digest-subscribe@lists.mysql.com plusplus-digest
plusplus リストのダイジェスト版です。
msql-mysql-modules-subscribe@lists.mysql.com msql-mysql-modules
msql-mysql-modules-digest-subscribe@lists.mysql.com msql-mysql-modules-digest
msql-mysql-modules リストのダイジェスト版です。
上述したのと同じ方法で全てのリストの購読または購読中止ができます。あなた
の購読または購読中止のメッセージは、mysql ではなく適切なメーリングリス
トに送ってください。例えば、 myodbc リストを購読または購読中止するには、
myodbc-subscribe@lists.mysql.com または
myodbc-unsubscribe@lists.mysql.com にメールを送ります。
メーリングリストから有益な回答が得られない場合、MySQL ABに 有料のサポートを求めることもできます。有料サポートが必要な場合、 MySQL 開発チームに直接御連絡下さい( 「1.4.1 Support Offered by MySQL AB」節参照)。
次の表は英語以外の MySQL メーリングリストを示します。注意: これら は MySQL AB によって運用されていません。そのため、我々はそれらの 品質を保証できません。
mysql-france-subscribe@yahoogroups.com フランス語メーリングリスト
list@tinc.net 韓国語メーリングリスト
subscribe mysql your@e-mail.address をメールしてください。
mysql-de-request@lists.4t2.com ドイツ語メーリングリスト
subscribe mysql-de your@e-mail.address をメールしてください。
これについては http://www.4t2.com/mysql で情報を見つけられます。
mysql-br-request@listas.linkway.com.br ポルトガル語メーリングリスト
subscribe mysql-br your@e-mail.address をメールしてください。
mysql-alta@elistas.net スペイン語メーリングリスト
subscribe mysql your@e-mail.address をメールしてください。
メーリングリストへ質問を尋ねる前に、以下の手順を踏んでください：
ここで回答が見つけられない場合は、近くの MySQL 熟練者ととも に調べて下さい。まだあなたの質問の回答が見つけられなければ、先に進み、次 のセクションの mysql@lists.mysql.com へメールを送る方法についてを読んで ください。
良いバグレポートを書くのは忍耐が要りますが、それを最初に正しく行なうこと は我々とあなたから時間を節約します。 そのバグについての完全なテストケースを含む良いバグレポートは、次のリリー スでそれが修正される可能性がとても高くなります。 この節では、かなりの、または全く我々 の助けにならないことにあなたの時間を浪費しないように、あなたがレポートを 正しく書くことを手助けします。
我々は、バグレポートまた可能ならば全ての問題についてのレポートの作成に
mysqlbug スクリプトを使用することを奨励します。mysqlbug は
ソース配布内の `scripts' ディレクトリ、または、バイナリ配布では
MySQL をインストールしたディレクトリ配下の `bin' ディレク
トリから見つけられます。mysqlbug を使用できない場合は、この節に挙
げられている全ての必要な情報を含めるべきです。
mysqlbug スクリプトは、下記の多くの情報を自動的に見つけ出すことで、
レポートの作成を手助けします。しかし、重要な何かが足りない場合、あなたの
メッセージにそれを含めてください！ この節を慎重に読んで、ここで述べられ
ている全ての情報がレポート中に含まれていることを確認してください。
バグや問題を報告する通常の場所は、mysql@lists.mysql.com です。
バグを明確に示すテストケースを作ることができれば、
bugs@list.mysql.com リストにそれを投稿してください。注意: この
リストには、完全で再現可能なバグ情報を mysqlbug スクリプトを使用
して投稿すべきです。 Windows 上で実行している場合は、OS と
MySQL バージョンの記述を含めるべきです。できれば、投稿前に
MySQL Server の最新の安定バージョンか開発バージョンを使用して問題をテ
ストすべきです！ 含められたテストケース上で、``mysql test < script'' を使
用することで、または、バグレポートに含められたシェル/Perlスクリプトを実
行することで、誰もがバグを再現できるべきです。この bugs リストに投稿された全て
のバグは、次の MySQL リリースで修正されるかドキュメント化されま
す！ 小さなコードの変更だけですめば、我々はこの問題を修正するパッチの投
稿も行ないます。
多すぎる情報を含むメッセージに答えることはできますが、少なすぎる情報を含 むものにはできないということを覚えていてください。しばしば人は事実を省い てしまいます。問題の原因をわかっていると思い、いくつかの詳細を重大でない と見なしてしまうからです。良い原則は: 何かを言おうか迷ったときには、言っ てください！ 最初にあなたが十分な情報を含めなかったために、再び質問して 回答を待つことを強要されるより、数行をあなたのレポートに書く方が千倍速く て迷惑ではありません。
良くある間違いは、使用している MySQL 配布のバージョン番号を示さ ない、または MySQL server をインストールしたプラットフォームを(プラッ トフォームのバージョン番号を含めて)示さない事です。これはとても関連した 情報で、100 のバグレポートのうち 99 の場合、この情報がないと役に立ちませ ん！ 我々は ``何故私では動作しないの？'' のような質問をとても良く受けま す。そして我々は、要求された機能はその MySQL バージョンに実装さ れていない、または、レポート中に述べられているバグは新しい MySQL バージョンで既に修正されているであることを見つけます。時々、 エラーはプラットフォーム依存で、オペレーティングシステムとプラットフォー ムのバージョン番号を知らないことには、何も修正することはできません。
問題に関連している場合は、コンパイラについての情報も与えることを忘れない でください。しばしば人はコンパイラのバグを見つけて、問題は MySQL に関連していると考えます。多くのコンパイラはいつも開発中 で、バージョンを上げることによってより良いバージョンになります。問題がコ ンパイラに依存しているかどうかを確定するには、どのコンパイラが使用されて いるかを知ることが必要です。全てのコンパイルの問題はバグレポートとみなさ れ、それに従って報告されるべきであることに注意してください。
最も役に立つのは、問題の良い説明がバグレポートに含められることです。つま り、問題に導かれる全ての行なったことの例と、正確に記述された問題それ自身 です。良いバグレポートは、バグや問題を再現する方法を示す完全な例を含むも のです。 「E.1.6 Making a Test Case When You Experience Table Corruption」節参照.
問題がエラーメッセージを与える場合、それをレポートに含めることはとても重 要です！ 我々がプログラムを使用するアーカイブから何かを検索しようとする 場合、エラーメッセージはプログラムが与えたものと正確に一致する方が良いで す(大文字小文字も守られるべきです！)。どのようなエラーメッセージだったか を覚えるなんてことはしてはいけません；レポートに完全なメッセージをコピー し張りつけてください。
MyODBC での問題がある場合、MyODBC トレースファイルの生成を試みるべきです。 「8.3.7 Reporting Problems with MyODBC」節参照.
あなたのレポートを読む多くの人が 80桁ディスプレイを使用しているというこ
とを覚えておいて下さい。従って、mysql コマンドラインツールを使用
してレポートまたはサンプルを生成する時、そのようなディスプレイの有効幅を
超える出力(例えば、EXPLAIN SELECT ステートメント; 後述のサンプル
を見てください)には、--vertical オプション(または \G ステー
トメント終端)を使用すべきです。
mysqladmin version の
実行でわかります。mysqladmin は MySQL のインストール
ディレクトリ配下の `bin' ディレクトリに見つけられます。
uname -a の実行によってこの情報が得られます。
mysqld が死んだ場合は、mysqld がクラッシュしたクエリも
レポートしてください。通常、これはロギングが有効な mysqld の実行に
よって、見つけられます。 「E.1.5 Using Log Files to Find Cause of Errors in mysqld」節参照。
mysqldump --no-data db_name tbl_name1 tbl_name2 ... からの出力を含めて
ください。これはデータベース内の任意のテーブルについての情報を得るとても
簡単で強力な方法で、我々があなたの状況に一致するものを生成する手助けにな
ります。
SELECT ステートメントでの速度に関するバグや問題では、
EXPLAIN SELECT ... の出力と、少なくとも SELECT ステートメ
ントが与える行の数を常に含めるべきです。あなたの状況について、より多くの
情報を、誰かがあなたを助けられるように、より適切に与えてください！ 例え
ば、次はとても良いバグレポートの例です（もちろん mysqlbug スクリプトで投
稿されてます）:
mysql コマンド行ツール配下での実行例(注意: 出力幅がディスプレイ装
置の80桁を超えるステートメントには、\G ステートメント終端を使用し
てください):
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
<output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
<A short version of the output from SELECT,
including the time taken to run the query>
mysql> SHOW STATUS;
<output from SHOW STATUS>
mysqladmin variables extended-status processlist の
出力結果をメールにを含むべきです。 これはあなたのシステムの情報を
提供します！
mysqldump を使用し
てあなたのテーブルをダンプし、あなたの問題を説明した `README' ファ
イルを作るべきです。
tar と gzip または zip を使用して、ファイルの圧縮アー
カイブを生成し、そのアーカイブを ftp を使用して
ftp://support.mysql.com/pub/mysql/secret/ に転送してください。それか
ら問題の短い説明を mysql@lists.mysql.com に送ってください。
ftp を使用して ftp://support.mysql.com/pub/mysql/secret/ にデー
タを転送することができます。データが本当に最高機密で我々にさえ見せたくな
い場合は、先に進んで、他の変数名等を使用してサンプルを作ってみてください。
しかしこれは最後の選択と思ってください。
mysqld デーモン開始時に使用したオプションと
MySQL クライアントプログラム実行に使用したオプションを示してく
ださい。 mysqld, mysql または configure スクリプト
へのオプションはしばしば回答へのキーになり、とても関連しています！ とに
かくそれらを含めるというのは悪い考えではありません！ Perl や PHP などの
モジュールを使用している場合、それらのバージョン番号も含めてください。
mysqlaccess の出力、
mysqladmin reload の出力、接続しようとした時に得られた全てのエラー
メッセージを含めてください！ 権限をテストする時、まず mysqlaccess
を実行すべきです。その後、mysqladmin reload version を実行し、最
後に問題が発生するプログラムでの接続を試みるべきです。mysqlaccess
はMySQL インストールディレクトリ配下の `bin' ディレクトリ
に見つけられます。
parse error が発生する場合、構文を厳密にチェックしてください！ 何
が間違っているのかを見つけられなければ、多分、使用しているクエリを
MySQL Server の現在のバージョンがサポートしていないということです。現
在のバージョンを使用していて、http://www.mysql.com/documentation/manual.php のマ
ニュアルがあなたの使用しているクエリ構文をカバーしていない場合は、これは
MySQL Server があなたのクエリをサポートしていないという意味です。この
場合、あなたの選択は、その構文をあなた自身で実装することか、
mysql-support@mysql.com に email でこれを実装するように申し込むこ
とです！
マニュアルがあなたの使用している構文をカバーしているのにMySQL
の古いバージョンを使用している場合、文法が実装された時期について
MySQL Server の変更履歴をチェックすべきです。 「D MySQL Change History」節参照。この場合、よ
り新しいバージョンの MySQL へのアップグレードを選択できます。
myisamchk か
CHECK TABLE/REPAIR TABLE 文で検査し、修復を試みるべきです
「4 Database Administration」節参照.
mysqld は 更新の最中に kill されない限りは
テーブルを絶対に破壊しません！ もしなぜ mysqld が死ぬのか
見つけた場合は、我々があなたに問題解決のための修正を提供することが、
はるかに簡単になります!
「A.1 How to Determine What Is Causing Problems」節参照
もしあなたがサポート顧客なら、より高い優先度で取り扱われるように、バグレポー トを mysql-support@mysql.com と、そして同様に、他の誰かが問題を経 験済み(そして、もしかしたら解決済み)かどうかを調べるために、適切なメーリン グリストにもクロスポストしてください。
MyODBC のバグ報告上の情報については、 「8.3.4 MyODBC での問題をどのように報告すべきか？」節 を参照 してください。
いくつかの一般的な問題の解決法のために → 「A Problems and Common Errors」節.
回答があなたに個人的に送られて、メーリングリストに送られていない時、回答 を要約し、あなたの問題の解決の手助けになった返事の恩恵を他の人にも与える ために、その要約をメーリングリストに送信することは、良いエチケットです！
あなたの回答が広く関心を持たれると考えられる場合、尋ねた人に個人的に直接 返事をする代わりに、メーリングリストに投稿したいと思うでしょう。オリジナ ルの投稿者以外の人もそれから恩恵を受けられるように十分一般的に回答を作成 することを試みてください。メーリングリストに投稿する場合は、あなたの回答 が以前の回答と重複していないか確認して下さい。
あなた返事の中で、質問の本質部分の要約を試みてください。質問全体を引用す ることを義務と感じないで下さい。
HTML モードを ON にしたブラウザからメールメッセージを投稿しないでくださ い！ 多くのユーザはブラウザでメールを読んでいません！
In addition to the various MySQL mailing lists, you can find experienced
community people on IRC (Internet Relay Chat).
These are the best networks/channels currently known to us:
#mysql
Primarily MySQL questions but other database and SQL questions welcome.
#mysqlphp
Questions about MySQL+PHP, a popular combo.
#mysql
MySQL questions.
If you are looking for IRC client software to connect to an IRC network,
take a peek at X-Chat (http://www.xchat.org/).
X-Chat is available for Unix as well as for Windows platforms.
この章では、MySQL がどのように ANSI SQL 標準に関係するかを説明し ます。MySQL Server は ANSI SQL 標準に対して多くの拡張を持ちます。そして、 ここでそれらが何か、またそれらの使用方法を見つけられるでしょう。また、 MySQL Server に足りない機能についての情報と、いくつかの違いを回避する方 法も見つけられるでしょう。
Our goal is to not, without a very good reason, restrict MySQL Server usability for any usage. Even if we don't have the resources to do development for every possible use, we are always willing to help and offer suggestions to people who are trying to use MySQL Server in new territories.
One of our main goals with the product is to continue to work toward
ANSI 99 compliancy, but without sacrificing speed or reliability.
We are not afraid to add extensions to SQL or support for non-SQL
features if this greatly increases the usability of MySQL Server for a big
part of our users. (The new HANDLER interface in MySQL Server 4.0
is an example of this strategy. 「6.4.2 HANDLER Syntax」節参照.)
We will continue to support transactional and non-transactional databases to satisfy both heavy web/logging usage and mission-critical 24/7 usage.
MySQL Server was designed from the start to work with medium size databases (10-100 million rows, or about 100 MB per table) on small computer systems. We will continue to extend MySQL Server to work even better with terabyte-size databases, as well as to make it possible to compile a reduced MySQL version that is more suitable for hand-held devices and embedded usage. The compact design of the MySQL server makes both of these directions possible without any conflicts in the source tree.
We are currently not targeting realtime support or clustered databases (even if you can already do a lot of things with our replication services).
We don't believe that one should have native XML support in the database, but will instead add the XML support our users request from us on the client side. We think it's better to keep the main server code as ``lean and clean'' as possible and instead develop libraries to deal with the complexity on the client side. This is part of the strategy mentioned previously of not sacrificing speed or reliability in the server.
Entry-level SQL92. ODBC levels 0-3.51.
We are aiming toward supporting the full ANSI SQL99 standard, but without concessions to speed and quality of the code.
If you start mysqld with the --ansi option, the following
behaviour of MySQL Server changes:
|| is string concatenation instead of OR.
REAL will be a synonym for FLOAT instead of a synonym for
DOUBLE.
SERIALIZABLE.
「6.7.3 SET TRANSACTION 構文」節参照.
GROUP BY that is not in the
field list.
This is the same as using
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.
MySQL Server は、他の SQL データベース内に見られないであろう、いくつか
の拡張を含んでいます。あなたがそれらを使用する場合、コードは他の SQL サー
バに移行できなくなるので注意してください。いくつかのケースでは、形式
/*! ... */ のコメントを使用することで、MySQL 拡張を含む
移行可能コードを書くことができます。この場合、MySQL Server はコメント
内のコードを実行しますが、ほかのSQLサーバーはこれを無視します。例えば:
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...
'!' の後ろにバージョン番号を追加すると、文法は MySQL バー
ジョンが使用されるバージョン番号と等しいか大きい場合にのみ実行されます:
CREATE /*!32302 TEMPORARY */ TABLE t (a int);
上記は バージョン 3.23.02 かそれ以上の場合という意味で、そのとき MySQL Server は
TEMPORARY キーワードを使用します。
MySQL 拡張を以下に示します:
MEDIUMINT, SET, ENUM そして様々な
BLOB と TEXT 型。
AUTO_INCREMENT, BINARY, NULL, UNSIGNED そして
ZEROFILL。
BINARY 属性であなたのフィールドを宣言すべきです。これは、MySQL
サーバホストの上で使用される ASCII 順に従って比較が実行されるようになり
ます。
db_name.tbl_name 構文を使用して違うデータベースのテーブルにアクセスできます。
いくつかのSQLサーバーは同様の機能を提供しますが、これを User space でコールします。
MySQL Server は以下のようなテーブルスペースをサポートしません:
create table ralph.my_table...IN my_tablespace.
LIKE が許されます。
SELECT ステートメント内の INTO OUTFILE と
STRAIGHT_JOIN の使用。 「6.4.1 SELECT 構文」節参照.
SQL_SMALL_RESULT option in a SELECT statement.
EXPLAIN SELECT。
CREATE TABLE ス
テートメント内の INDEX または KEY の使用。
「6.5.3 CREATE TABLE 構文」節参照.
CREATE TABLE での TEMPORARY か IF NOT EXISTS の使用。
list 要素が一つ以上の COUNT(DISTINCT list) の使用。
ALTER TABLE ステートメント内の CHANGE col_name, DROP col_name,
DROP INDEX, IGNORE, RENAME の使用。
「6.5.4 ALTER TABLE 構文」節参照.
RENAME TABLE の使用。 「6.5.5 RENAME TABLE 構文」節参照。
ALTER TABLE ステートメント内の複数の ADD, ALTER,
DROP, CHANGE 節の使用。
IF EXISTS 付きの DROP TABLE の使用。
DROP TABLE で破棄できる
DELETE ステートメントの LIMIT 節。
INSERT と REPLACE ステートメントの DELAYED 節。
INSERT, REPLACE, DELETE, UPDATE ステートメント
の LOW_PRIORITY 節。
LOAD DATA INFILE の使用。多くの場合、この構文は ORACLE の
LOAD DATA INFILE と互換があります。 「6.4.9 LOAD DATA INFILE 構文」節参照.
ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, and
REPAIR TABLE ステートメント。
SHOW ステートメント。
「4.5.6 SHOW 構文」節参照.
SET ステートメント。 「5.5.6 SET 構文」節参照.
GROUP BY 部に全てのフィールドを持つ必要はありません。
This gives better performance for some very specific, but quite normal
queries.
「6.3.6.3 Functions for Use with GROUP BY Clauses」節参照.
GROUP BY とともに ASC と DESC を記述できます。
|| と && 演算子を、C プログラミング言語
のように、論理和と論理積を意味すると理解します。MySQL では
|| と OR、&& と AND は同義語です。この良い構
文のため、MySQL Server は ANSI SQL の文字列結合演算子 || をサポー
トしません。CONCAT() を代わりに使用してください。CONCAT()
は任意の数の引数を使用できるので、|| 演算子の使用を
MySQL Server に変換するのは簡単です。
CREATE DATABASE または DROP DATABASE.
「6.5.1 CREATE DATABASE 構文」節参照.
MOD() と同義の %。 N % M は MOD(N,M) と等価です。
% は C プログラマーと PostgreSQL との互換のためにサポートされます。
=, <>, <= ,<, >=,>,
<<, >>, <=>, AND, OR, LIKE
演算子は、SELECT 文中で、FROM の左側のフィールドの比較に
使用されます。
例えば：
mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
LAST_INSERT_ID() 関数。
「8.4.3.130 mysql_insert_id()」節参照.
REGEXP と NOT REGEXP 正規表現演算子
CONCAT() または CHAR()。
MySQL Server では、これらの関数は任意の数の引数を取ることができます。
BIT_COUNT(), CASE, ELT(),
FROM_DAYS(), FORMAT(), IF(), PASSWORD(),
ENCRYPT(), md5(), ENCODE(), DECODE(),
PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS(),
WEEKDAY() 関数。
TRIM() to trim substrings. ANSI SQL only supports removal
of single characters.
GROUP BY 関数 STD(), BIT_OR() そして BIT_AND()。
DELETE + INSERT の代わりの REPLACE の使用。
「6.4.8 REPLACE 構文」節参照.
FLUSH, RESET, DO 構文。
:= でステートメント内での変数の設定が可能:
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
我々は MySQL Server を ANSI SQL 標準と ODBC SQL 標準に従うように試みてい ますが、いくつかのケースで MySQL Server には何らかの違いがあります:
-- は空白が続く場合だけコメントになります。
VARCHAR フィールドでは、値が格納される時に末尾の空白が削除されます。
「1.7.5 Known Errors and Design Deficiencies in MySQL」節参照。
CHAR フィールドは黙って VARCHAR フィール
ドに変更されます。 「6.5.3.1 暗黙のフィールド定義変更」節参照。
REVOKE を発行する必
要があります。 「4.3.1 GRANT と REVOKE 構文」節参照.
NULL AND FALSE は FALSE ではなく NULL と評価されます。
このケースで、多くの余計な条件を評価する必要があることは良いことではないと、
我々は考えているからです。
次の機能が MySQL Server の現在のバージョンにはありません。新しい拡張の 優先度については、次を参考にしてください http://www.mysql.com/doc/en/TODO.html. これはこのマニュアル中の TODO リストの最新バージョンです。 「1.8 MySQL and The Future (The TODO)」節参照.
SELECTs
MySQL Server until version 4.0 only supports nested queries of the form
INSERT ... SELECT ... and REPLACE ... SELECT ....
You can, however, use the function IN() in other contexts.
Subselects are being implemented in the 4.1 development tree.
しかし多くの場合、subselect を使わないクエリに書き直すことができます:
SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
This can be rewritten as:
SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id;
The queries:
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2
WHERE table1.id=table2.id);
Can be rewritten as:
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;
さらに複雑なサブクエリでは、サブクエリを保持するために一時テーブルを作成で
きます。しかし、この方法でも動かない場合があります。このケースには、
DELETE ステートメントでもっとも頻繁に遭遇します。DELETE ステー
トメントでは、標準 SQL では（sub select の中を除いて）join をサポートして
いません。サブクエリが MySQL Server にサポートされるまで、この状況には２
つの選択肢があります。
最初の選択肢は、手続きプログラミング言語（Perl や PHP のような）を使用して、
SELECT クエリを発行して削除されるレコードのプライマリキーを獲得し、
それから DELETE ステートメント（DELETE FROM ... WHERE
... IN (key1, key2, ...)）を構築するためにその値を使用することです。
二番目の選択肢は、対話型 SQL を使用し、DELETE ステートメントのセッ
トを（標準 || オペレータの代わりに）MySQL 拡張
CONCAT() を使用して、自動的に組み立てることです。例えば:
SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', "'", tab1.pkid, "'", ';')
FROM tab1, tab2
WHERE tab1.col1 = tab2.col2;
このクエリをスクリプトファイル中に置き、入力を mysql コマンドライン
インタプリタに切替え、その出力を二番目のインタプリタインスタンスにパイプし
ます:
shell> mysql --skip-column-names mydb < myscript.sql | mysql mydb
MySQL Server 4.0 supports multi-table deletes that can be used to efficiently delete rows based on information from one table or even from many tables at the same time.
SELECT INTO TABLE
MySQL Server doesn't yet support the Oracle SQL extension:
SELECT ... INTO TABLE .... MySQL Server supports instead the
ANSI SQL syntax INSERT INTO ... SELECT ..., which is basically
the same thing. 「6.4.3.1 INSERT ... SELECT 構文」節参照.
INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID
FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;
Alternatively, you can use SELECT INTO OUTFILE... or CREATE
TABLE ... SELECT.
MySQL Server supports transactions with the InnoDB and BDB
Transactional table handlers. 「7 MySQL テーブル型」節参照.
InnoDB provides ACID compliancy.
However, the non-transactional table types in MySQL Server such as
MyISAM follow another paradigm for data integrity called
``Atomic Operations.''
アトミック・オペレーションが同等かあるいはより良いパフォーマンスを
提供するというのが、我々の経験、および考えです。
With MySQL Server supporting both paradigms, the user is able to decide if
he needs the speed of atomic operations or if he need to use
transactional features in his applications. This choice can be made
on a per-table basis.
厳密に integrity 維持するには MySQL Server の機能をどのように使用するの でしょう？ そして、トランザクション的パラダイムでこれらの機能をどのように 比較するのでしょう？
COMMIT の代わりに ROLLBACK の呼び出しに依存しているなら、
トランザクションはより便利になるでしょう。
おまけに、トランザクションは完了できなかった更新や不整合を起こした
データが、確実にデータベースに登録されないようにできます。
そのサーバーには、自動的な rollback をする機会が与えられ、
あなたのデータは守られるでしょう。
MySQL Server はほとんどの場合、更新前の簡単なチェックを含ませることができたり、
あるいはデータベースの矛盾を検査して自動修復や警告の表示を行ったりする
簡単なスクリプトを実行することができるような、
ポテンシャルをあなたに提供します。
MySQL ログの使用や外部へのログの追加を行ったりする事で、
通常、データに不整合のおきたテーブルを完全に修復できることに注意してください。
LOCK TABLES or atomic updates, ensuring
that you never will get an automatic abort from the database, which is
a common problem with transactional databases.
The transactional paradigm has its benefits and its drawbacks. Many users and application developers depend on the ease with which they can code around problems where an abort appears to be, or is necessary. However, even if you are new to the atomic operations paradigm, or more familiar with transactions, do consider the speed benefit that non-transactional tables can offer on the order of three to five times the speed of the fastest and most optimally tuned transactional tables.
In situations where integrity is of highest importance, MySQL Server offers
transaction-level or better reliability and integrity even for
non-transactional tables.
If you lock tables with LOCK TABLES, all updates will stall
until any integrity checks are made. If you only obtain a read lock
(as opposed to a write lock), reads and inserts are still allowed
to happen. The new inserted records will not be seen by any of the
clients that have a read lock until they release their read
locks. With INSERT DELAYED you can queue inserts into a local
queue, until the locks are released, without having the client wait
for the insert to complete. 「6.4.4 INSERT DELAYED 構文」節参照.
``Atomic,'' in the sense that we mean it, is nothing magical. It only means that you can be sure that while each specific update is running, no other user can interfere with it, and there will never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there will not be any dirty reads.
Following are some techniques for working with non-transactional tables:
LOCK TABLES, and you don't need cursors when you can update
records on the fly.
ROLLBACK, you can use the following strategy:
LOCK TABLES ... to lock all the tables you want to access.
UNLOCK TABLES to release your locks.
ROLLBACKs, although not always. The only situation
this solution doesn't handle is when someone kills the threads in the
middle of an update. In this case, all locks will be released but some
of the updates may not have been executed.
WHERE clause in the UPDATE statement. If the record wasn't
updated, we give the client a message: "Some of the data you have changed
has been changed by another user." Then we show the old row versus the new
row in a window, so the user can decide which version of the customer record
he should use.
This gives us something that is similar to column locking but is actually
even better because we only update some of the columns, using values that
are relative to their current values. This means that typical UPDATE
statements look something like these:
UPDATE tablename SET pay_back=pay_back+'relative change';
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
money_he_owes_us=money_he_owes_us+'new_money'
WHERE
customer_id=id AND address='old address' AND phone='old phone';
As you can see, this is very efficient and works even if another client
has changed the values in the pay_back or money_he_owes_us
columns.
ROLLBACK and/or LOCK
TABLES for the purpose of managing unique identifiers for some tables.
This can be handled much more efficiently by using an
AUTO_INCREMENT column and either the SQL function
LAST_INSERT_ID() or the C API function mysql_insert_id().
「8.4.3.130 mysql_insert_id()」節参照.
You can generally code around row-level locking. Some situations really
need it, but they are very few. InnoDB tables support row-level
locking. With MyISAM, you can use a flag column in the table and do
something like the following:
UPDATE tbl_name SET row_flag=1 WHERE id=ID;MySQL returns 1 for the number of affected rows if the row was found and
row_flag wasn't already 1 in the original row.
You can think of it as though MySQL Server changed the preceding query to:
UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
ストアドプロシジャは、サーバ内でコンパイルでき格納できる SQL コマンドの セットです。一度これが行なわれると、クライアントはクエリ全体の再発行を保 持する必要がなく、ストアドプロシジャを参照できます。これはさらにより速い速度を提 供します。クエリは一度だけ解釈され、より少ないデータがサーバとクライアン ト間で送信されるからです。サーバ内に関数ライブラリを持つことによりレ ベルを上げることもできます。
トリガは特別なイベントが発生した時に呼び出されるストアドプロシジャです。 例えば、トランザクションテーブルからレコードが削除される度にトリガされ、 それに対応する顧客を顧客テーブルから自動的に削除するという、 ストアドプロシジャをインストールすることができます。
The planned update language will be able to handle stored procedures. Our aim is to have stored procedures implemented in MySQL Server around version 5.0. We are also looking at triggers.
注意: SQL の外部キーはテーブルを結合するためには使用できませんが、指示の
完全性の検査のために良く使用されます(foreign key constraints)。
SELECT ステートメントで複数
テーブルから結果を得たい場合、テーブルの結合によってこれを行ないます：
SELECT * FROM table1,table2 WHERE table1.id = table2.id;
「6.4.1.1 JOIN 構文」節参照. 「3.5.6 Using Foreign Keys」節参照.
In MySQL Server 3.23.44 and up, InnoDB tables support checking of
foreign key constraints. 「7.5 InnoDB テーブル (3.23.6以上)」節参照. For other table types, MySQL Server
does parse the FOREIGN KEY syntax in CREATE TABLE
commands, but without further action being taken.
MySQL 内での FOREIGN KEY 構文は、他の SQL ベンダの
CREATE TABLE コマンドとの互換のためだけに存在します; これは何も行
ないません。ON DELETE ... がない FOREIGN KEY 構文は、目的
の作成のために主に使われます。いくつかの ODBC アプリケーションは、自動的
に WHERE 節を提供するために、これを使用しますが、しかしこれは通常
簡単に無効にできます。FOREIGN KEY は時々強制チェックとして使用さ
れます。しかし、テーブルに正しい順で行が挿入される場合、このチェックは実
際には不要です。いくつかのアプリケーションがそれが存在することを要求する
ため MySQL はこれらの節だけをサポートします（それが動作するかど
うかに関わらず）。
MySQL Server では、外部キーを持つテーブルからレコードを削除する時に適
切な DELETE ステートメントをアプリケーションに追加することで、
ON DELETE ... が実装されていないという問題を回避できます。実際に
は、これは速く(いくつかの場合はより速く)そして外部キーの使用よりもさらに
可搬性があります。
In MySQL Server 4.0 you can use multi-table delete to delete rows from many
tables with one command. 「6.4.6 DELETE 構文」節参照.
In the near future we will extend the FOREIGN KEY implementation
so that the information will be saved in the table specification file
and may be retrieved by mysqldump and ODBC. At a later stage we
will implement the foreign key constraints for applications that can't
easily be coded to avoid them.
Do keep in mind that foreign keys are often misused, which can cause severe problems. Even when used properly, it is not a magic solution for the referential integrity problem, although it does make things easier in some cases.
Some advantages of foreign key enforcement:
Disadvantages:
It is planned to implement views in MySQL Server around version 5.0.
Views are mostly useful for letting users access a set of relations as one table (in read-only mode). Many SQL databases don't allow one to update any rows in a view, but you have to do the updates in the separate tables.
As MySQL Server is mostly used in applications and on web systems where the application writer has full control on the database usage, most of our users haven't regarded views to be very important. (At least no one has been interested enough in this to be prepared to finance the implementation of views.)
One doesn't need views in MySQL Server to restrict access to columns, as MySQL Server has a very sophisticated privilege system. 「4.2 General Security Issues and the MySQL Access Privilege System」節参照.
他のいくつかの SQL データベースは、`--' をコメントの開始のために使
用します。MySQL Server は `#' をコメント開始文字とします。
mysql コマンドラインツールが `--' で始まる全ての行を削除した
としてもです。MySQL では C コメントスタイル /* これはコメ
ント */ も使用できます。 「6.1.6 コメント 構文」節参照。
MySQL Server バージョン 3.23.3 以上は `--' をサポートしません;
この退化したコメントスタイルは、次のコードのように !payment! の
payment の値を自動的に挿入するような何かを使用して自動的に生成される
SQL クエリで多くの問題を引き起こすためです:
UPDATE tbl_name SET credit=credit-!payment!
payment の値が負の場合に何が起きると思いますか？
1--1 は正しい SQL なので、我々は `--' をコメント開始と見なす
ことはひどいことだと思います。
しかし MySQL Server バージョン 3.23 では次を使用できます:
1-- これはコメント
以降の説明では、バージョン 3.23 よりも前の MySQL を実行している場 合だけが対象です:
テキストファイルの SQL プログラムが `--' コメントを含んでいる場合、 次を使用すべきです:
shell> replace " --" " #" < text-file-with-funny-comments.sql \
| mysql database
通常の次の代わりに:
shell> mysql database < text-file-with-funny-comments.sql
次の方法でも、コマンドファイル中の `--' コメントを `#' コメン トに変更できます:
shell> replace " --" " #" -- text-file-with-funny-comments.sql
それらは次のコマンドで戻してください:
shell> replace " #" " --" -- text-file-with-funny-comments.sql
The following problems are known and have a very high priority to get fixed:
ANALYZE TABLE on a BDB table may in some case make the table
unusable until one has restarted mysqld. When this happens you will
see errors like the following in the MySQL error file:
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
ALTER TABLE on a BDB table on which you are
running multi-statement transactions until all those transactions complete.
(The transaction will probably be ignored.)
ANALYZE TABLE, OPTIMIZE TABLE, and REPAIR TABLE may
cause problems on tables for which you are using INSERT DELAYED.
LOCK TABLE ... and FLUSH TABLES ... doesn't
guarantee that there isn't a half-finished transaction in progress on the
table.
mysql client on the
database if you are not using the -A option or if you are using
rehash. This is especially notable when you have a big table
cache.
The following problems are known and will be fixed in due time:
RPAD function, or any other string function that ends
up adding blanks to the right, in a query that has to use temporary
table to be resolved, then all resulting strings will be RTRIM'ed. This
is an example of the query:
SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, '
') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON
t1.record=t2.joinID ORDER BY t2.record;
Final result of this bug is that use will not be able to get blanks on
the right side of the resulting field.
The above behaviour exists in all versions of MySQL.
The reason for this is due to the fact that HEAP tables, which are used
first for temporary tables, are not capable of handling VARCHAR columns.
This behaviour will be fixed in one of 4.1 releases.
SET CHARACTER SET, one can't use translated
characters in database, table, and column names.
_ or % with ESCAPE in LIKE
... ESCAPE.
DECIMAL column with a number stored in different
formats (+01.00, 1.00, 01.00), GROUP BY may regard each value
as a different value.
DELETE FROM merge_table used without a WHERE
will only clear the mapping for the table, not delete everything in the
mapped tables.
BLOB values can't ``reliably'' be used in GROUP BY or
ORDER BY or DISTINCT.
これらの場合、 BLOB の比較の際には最初の max_sort_length バイト
（デフォルト1024）だけが使用されます。
これは mysqld の -O max_sort_length オプションで変更可能です。
A workaround for most cases is to use a substring:
SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.
BIGINT or DOUBLE (both are
normally 64 bits long). It depends on the function which precision one
gets. The general rule is that bit functions are done with BIGINT
precision, IF, and ELT() with BIGINT or DOUBLE
precision and the rest with DOUBLE precision. One should try to
avoid using unsigned long long values if they resolve to be bigger than
63 bits (9223372036854775807) for anything else than bit fields!
MySQL Server 4.0 has better BIGINT handling than 3.23.
BLOB と TEXT はのぞいて、は、
検索されるときに最後についているスペースを自動で取り除きます。
CHAR 型ではこれは OK で、この特徴は ANSI SQL92 に従っていると見なされるでしょう。
MySQL Server のバグは、 VARCHAR でも同様に行ってしまうことです。
ENUM and SET columns in one table.
MIN(), MAX() and other aggregate functions, MySQL
currently compares ENUM and SET columns by their string
value rather than by the string's relative position in the set.
safe_mysqld redirects all messages from mysqld to the
mysqld log. One problem with this is that if you execute
mysqladmin refresh to close and reopen the log,
stdout and stderr are still redirected to the old log.
If you use --log extensively, you should edit safe_mysqld to
log to `'hostname'.err' instead of `'hostname'.log' so you can
easily reclaim the space for the old log by deleting the old one and
executing mysqladmin refresh.
UPDATE statement, columns are updated from left to right. If
you refer to an updated column, you will get the updated value instead of the
original value. For example:
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;This will update
KEY with 2 instead of with 1.
mysql> SELECT * FROM temporary_table, temporary_table AS t2;
RENAME doesn't work with TEMPORARY tables or tables used in a
MERGE table.
DISTINCT differently if you are using
'hidden' columns in a join or not. In a join, hidden columns are
counted as part of the result (even if they are not shown) while in
normal queries hidden columns don't participate in the DISTINCT
comparison. We will probably change this in the future to never compare
the hidden columns when executing DISTINCT.
An example of this is:
SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;
and
SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;
In the second case you may in MySQL Server 3.23.x get two identical rows
in the result set (because the hidden id column may differ).
Note that this happens only for queries where you don't have the
ORDER BY columns in the result, something that you are not allowed
to do in ANSI SQL.
rollback data, some things
behave a little differently in MySQL Server than in other SQL servers.
This is just to ensure that MySQL Server never needs to do a rollback
for a SQL command. This may be a little awkward at times as column
values must be checked in the application, but this will actually give
you a nice speed increase as it allows MySQL Server to do some
optimisations that otherwise would be very hard to do.
If you set a column to an incorrect value, MySQL Server will, instead of
doing a rollback, store the best possible value in the column:
NULL into a column that doesn't take
NULL values, MySQL Server will store 0 or '' (empty
string) in it instead. (This behaviour can, however, be changed with the
-DDONT_USE_DEFAULT_FIELDS compile option.)
DATE and
DATETIME columns (like 2000-02-31 or 2000-02-00). The idea is
that it's not the SQL server job to validate date. If MySQL can store a
date and retrieve exactly the same date, then MySQL will store the
date. If the date is totally wrong (outside the server's ability to store
it), then the special date value 0000-00-00 will be stored in the column.
ENUM column to an unsupported value, it will be set to
the error value empty string, with numeric value 0.
SET column to an unsupported value, the value will
be ignored.
PROCEDURE on a query that returns an empty set,
in some cases the PROCEDURE will not transform the columns.
MERGE doesn't check if the underlying
tables are of compatible types.
NaN, -Inf, and Inf
values in double. Using these will cause problems when trying to export
and import data. We should as an intermediate solution change NaN to
NULL (if possible) and -Inf and Inf to the
minimum respective maximum possible double value.
LIMIT on negative numbers are treated as big positive numbers.
ALTER TABLE to first add a UNIQUE index to a
table used in a MERGE table and then use ALTER TABLE to
add a normal index on the MERGE table, the key order will be
different for the tables if there was an old key that was not unique in the
table. This is because ALTER TABLE puts UNIQUE keys before
normal keys to be able to detect duplicate keys as early as possible.
The following are known bugs in earlier versions of MySQL:
DROP TABLE on a table that is
one among many tables that is locked with LOCK TABLES.
LOCK table with WRITE.
FLUSH TABLES.
UPDATE that updated a key with
a WHERE on the same key may have failed because the key was used to
search for records and the same row may have been found multiple times:
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;A workaround is to use:
mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;This will work because MySQL Server will not use an index on expressions in the
WHERE clause.
For platform-specific bugs, see the sections about compiling and porting.
This section lists the features that we plan to implement in MySQL Server.
もしあなたが優先順位に影響を及ぼしたければ、どうかライセンスかサポート登録して、 我々にあなたがより速く欲しいものを言ってください。 「1.4 MySQL ライセンスとサポート」節参照.
The plan is that we in the future will support the full ANSI SQL99 standard, but with a lot of useful extensions. The challenge is to do this without sacrificing the speed or compromising the code.
All done. We now only do bug fixes for MySQL 4.0. 「D.3 Changes in release 4.0.x (Gamma)」節参照. Development has shifted to 4.1 & 5.0
The following features are planned for inclusion into MySQL 4.1. For a list what is already done in MySQL 4.1, see 「D.2 Changes in release 4.1.x (Alpha)」節参照.
The following features are planned for inclusion into MySQL 5.0. Note that because we have many developers that are working on different projects, there will also be many additional features. There is also a small chance that some of these features will be added to MySQL 4.1. For a list what is already done in MySQL 4.1, see 「D.2 Changes in release 4.1.x (Alpha)」節参照.
SHOW COLUMNS FROM table_name (used by mysql client to allow
expansions of column names) should not open the table, only the
definition file. This will require less memory and be much faster.
ROLLUP and CUBE OLAP (Online Analytical Processing) grouping
options for data warehousing applications.
DELETE on MyISAM tables to use the record cache.
To do this, we need to update the threads record cache when we update
the `.MYD' file.
SET CHARACTER SET we should translate the whole query
at once and not only strings. This will enable users to use the translated
characters in database, table, and column names.
RENAME TABLE on a table used in an active
MERGE table possibly corrupting the table.
RENAME DATABASE. To make this safe for all storage engines,
it should work as follows:
RENAME command.
VARCHAR support (there is already support for this in
MyISAM).
BIT 型を 1 bit 取るように最適化 （今 BIT は一文字とります）
HEAP) tables:
INSERT ... SELECT to optionally use concurrent inserts.
SELECT MIN(column)
... GROUP BY.
long_query_time with a granularity
in microseconds.
myisampack code into the server.
INSERT/DELETE/UPDATE so that we
can gracefully recover if the index file gets full.
ALTER TABLE を
実行した場合、一時テーブルをこの disk に作成するようにする
DATE/DATETIME type that handles time zone information
properly so that dealing with dates in different time zones is easier.
MyISAM)
without threads.
INSERT SQL_CONCURRENT and mysqld --concurrent-insert to do
a concurrent insert at the end of the file if the file is read-locked.
lockd works with modern Linux kernels; if not, we have
to fix lockd! To test this, start mysqld with
--enable-locking and run the different fork* test suits. They shouldn't
give any errors if lockd works.
LIMIT, like in LIMIT @a,@b.
UPDATE statements. For example:
UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c.
GROUP BY, as in the following example:
SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id.
DEFAULT values to columns. Give an error when using
an INSERT that doesn't contain a column that doesn't have a
DEFAULT.
mysql_query() commands in a row
without reading results or give a nice error message when one does this.
ctime() が動かないか検証。
TIMESTAMP と AUTO_INCREMENT フィールドを更新しないように、
IMAGE オプションを LOAD DATA INFILE に追加。
LOAD DATE INFILE ... UPDATE syntax.
LOAD DATA INFILE ... REPLACE INTO now.
LOAD DATA INFILE understand syntax like:
LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
TEXT_FIELDS (text_field1, text_field2, text_field3)
SET table_field1=CONCAT(text_field1, text_field2),
table_field3=23
IGNORE text_field3
This can be used to skip over extra columns in the text file,
or update columns based on expressions of the read data.
LOAD DATA INFILE 'file_name' INTO TABLE 'table_name' ERRORS TO err_table_name.
This would cause any errors and warnings to be logged into the
err_table_name table. That table would have a structure like:
line_number - line number in datafile error_message - the error/warning message and maybe data_line - the line from the datafile
mysql から自動的に Netscape に出力
LOCK DATABASES. (いろいろなオプション付きで)
t1 JOIN t2 ON ... と t1 JOIN t2 USING ... の使用の追加。
現在、 LEFT JOIN のみが使用できます。
show status. Records reads and
updates. Selects on 1 table and selects with joins. Mean number of
tables in select. Number of ORDER BY and GROUP BY queries.
mysql in the middle of a query, you should open
another connection and kill the old running query.
Alternatively, an attempt should be made to detect this in the server.
SHOW INFO FROM tbl_name for basic table information
should be implemented.
SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a); in this
case a is assumed to come from the crash_me table.
CONNECT BY PRIOR ... to search hierarchy structures.
mysqladmin copy database new-database; requires COPY
command to be added to mysqld.
SHOW HOSTS for printing information about the hostname cache.
DELETE and REPLACE options to the UPDATE statement
(this will delete rows when one gets a duplicate key error while updating).
DATETIME to store fractions of seconds.
NULL for calculated columns.
Item_copy_string on numerical values to avoid
number->string->number conversion in case of:
SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id
ALTER TABLE doesn't abort clients
that execute INSERT DELAYED.
UPDATE clause,
they contain the old values from before the update started.
pread()/pwrite() on Windows to enable
concurrent inserts.
SUM(DISTINCT).
ANY(), EVERY(), and SOME() group functions. In
ANSI SQL these work only on boolean columns, but we can extend these to
work on any columns/expressions by applying: value == 0 -> FALSE and
value <> 0 -> TRUE.
MAX(column) is the same as the column type:
mysql> CREATE TABLE t1 (a DATE); mysql> INSERT INTO t1 VALUES (NOW()); mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1; mysql> SHOW COLUMNS FROM t2;
UPDATE the row
if it exists and INSERT a new row if the row didn't exist
(like REPLACE works with INSERT / DELETE).
get_changed_tables(timeout,table1,table2,...).
SET TIMESTAMP=#;.
MyISAM tables, probably after
the implementation of stored procedures with triggers.
MINUS, INTERSECT, and FULL OUTER JOIN.
(Currently UNION [in 4.0] and LEFT OUTER JOIN are supported.)
SQL_OPTION MAX_SELECT_TIME=# to put a time limit on a query.
LIMIT to allow retrieval of data from the end of a result set.
safe_mysqld: according to FSSTND (which
Debian tries to follow) PID files should go into `/var/run/<progname>.pid'
and log files into `/var/log'. It would be nice if you could put the
"DATADIR" in the first declaration of "pidfile" and "log", so the
placement of these files can be changed with a single statement.
zlib() for gzip-ed files to LOAD DATA INFILE.
BLOB columns (partly solved now).
AUTO_INCREMENT value when one sets a column to 0.
Use NULL instead.
JOIN with parentheses.
GET_LOCK. When doing this,
one must also handle the possible deadlocks this change will introduce.
Time is given according to amount of work, not real time.
Our users have successfully run their own benchmarks against a number
of Open Source and traditional database servers.
We are aware of tests against Oracle server, DB/2 server,
Microsoft SQL Server, and other commercial products.
Due to legal reasons we are restricted from publishing some of those
benchmarks in our reference manual.
This section includes a comparison with mSQL for historical
reasons and with PostgreSQL as it is also an Open Source
database. If you have benchmark results that we can publish, please
contact us at benchmarks@mysql.com.
For comparative lists of all supported functions and types as well
as measured operational limits of many different database systems,
see the crash-me web page at
http://www.mysql.com/information/crash-me.php.
mSQLmSQL should be quicker at:
INSERT operations into very simple tables with few columns and keys.
CREATE TABLE and DROP TABLE.
SELECT on something that isn't an index. (A table scan is very
easy.)
mSQL や多くの他の SQL 実装よりとても速いです:
SELECT operations.
VARCHAR
上にインデックスを持つことができます。
SELECT with many expressions.
SELECT on large tables.
mSQL では、全ての他の接続は、最初のもの - クエリが長いか短いかに
関わらず - が実行され、終わるまで待つ必要があります。その後次の接続が与
えられ、他の全ては再び待ちます。
mSQL can become pathologically slow if you change the order of
tables in a SELECT. In the benchmark suite, a time more than
15,000 times slower than MySQL Server was seen. This is due to mSQL's
lack of a join optimiser to order tables in the optimal order.
However, if you put the tables in exactly the right order in
mSQL2 and the WHERE is simple and uses index columns,
the join will be relatively fast!
「5.1.4 The MySQL Benchmark Suite」節参照.
ORDER BY and GROUP BY.
DISTINCT.
TEXT または BLOB フィールドの使用。
GROUP BY and HAVING.
mSQL does not support GROUP BY at all.
MySQL Server supports a full GROUP BY with both HAVING and
the following functions: COUNT(), AVG(), MIN(),
MAX(), SUM(), and STD(). COUNT(*) is
optimised to return very quickly if the SELECT retrieves from
one table, no other columns are retrieved, and there is no
WHERE clause. MIN() and MAX() may take string
arguments.
INSERT and UPDATE with calculations.
MySQL Server can do calculations in an INSERT or UPDATE.
For example:
mysql> UPDATE SET x=x*10+y WHERE x<20;
SELECT with functions.
MySQL Server has many functions (too many to list here; see 「6.3 SELECT と WHERE 節で使用する関数」節).
MEDIUMINT
です。10,000,000 レコードを持つ場合、1レコードあたり1バイトの節約でもと
ても重要です。
mSQL2 は4つの型(char,text,int,real)しかないので、小さなテーブルを
得るのは難しいです。
mSQL 安定性の経験がありません。そのため、我々はこれにつ
いては何も言えません。
mSQL よりも柔軟なライセンスを持っています。そして mSQL よ
りもより安いです。少なくとも、あなたが使用を選択した製品全てに、ライセン
スまたは email サポートへの支払いを考慮することを覚えていて下さい。
MySQL を含めた製品を売る場合、もちろんこのライセンスの獲得が要求
されます。
mSQL と同じ perl インタフェースと、いくつかの追
加機能を持ちます。
mSQL has a JDBC driver, but we have too little
experience with it to compare.
GROUP BY などはまだ
mSQL には実装されていませんので、it has a lot of chatching up to
do. この上でいくつかの見通しを得るために、去年の mSQL `HISTORY' ファ
イルを見て、MySQL Reference Manual News 節と比較できます( 「D MySQL Change History」節)。
速く開発された多くのものが、かなり明白になります。
mSQL と MySQL は多くの興味深いサードパーティツールを持っ
ています。上位への移行 (mSQL -> MySQL) はとても簡単です。
MySQL は、ほとんど全ての興味深い mSQL アプリケーションを
持っています。
MySQL には、簡単な msql2mysql プログラムが用意されています。
これは、mSQL と MySQL の C API 関数のスペルの違いを修正するプログラムです。
For example, it changes instances of msqlConnect() to
mysql_connect().
mSQL から MySQL への変換は通常、数分使用するだけです。
mSQL Tools for MySQL
According to our experience, it doesn't take long to convert tools
such as msql-tcl and msqljava that use the
mSQL C API so that they work with the MySQL C API.
The conversion procedure is:
msql2mysql をソースに実行します。バイナリプログラム
replace が必要です。これは MySQL で配布されます。
MySQL と mSQL 間の C API の違い:
MYSQL 構造体を接続型として使用します (mSQL は
int を使用します)。
mysql_connect() は MYSQL 構造体へのポインタをパラメータとして使用します。そ
れをグローバルに定義したり、その獲得に malloc() を使用するのは簡単です。
mysql_connect() also takes two parameters for
specifying the user and password. You may set these to
NULL, NULL for default use.
mysql_error() は MYSQL 構造体をパラメータとして使用します。古いコードを移
行する場合、あなたの古い msql_error() コードへパラメータを追加してください。
mSQLはテキストのエラーメッセージしか返しません。
mSQL and MySQL Client/Server Communications Protocols DifferThere are enough differences that it is impossible (or at least not easy) to support both.
The most significant ways in which the MySQL protocol differs
from the mSQL protocol are listed here:
mSQL 2.0 SQL Syntax Differs from MySQLColumn types
MySQL Server
CREATE TABLE 構文」節):
ENUM type for one of a set of strings.
SET type for many of a set of strings.
BIGINT type for 64-bit integers.
UNSIGNED option for integer and floating-point columns.
ZEROFILL option for integer columns.
AUTO_INCREMENT option for integer columns that are a
PRIMARY KEY.
「8.4.3.130 mysql_insert_id()」節参照.
DEFAULT value for all columns.
mSQL2
mSQL column types correspond to the MySQL types shown in the following table:
mSQL type | Corresponding MySQL type |
CHAR(len) | CHAR(len)
|
TEXT(len) | TEXT(len). len is the maximal length.
And LIKE works.
|
INT | INT. With many more options!
|
REAL | REAL. Or FLOAT. Both 4- and 8-byte versions are available.
|
UINT | INT UNSIGNED
|
DATE | DATE. Uses ANSI SQL format rather than mSQL's own format.
|
TIME | TIME
|
MONEY | DECIMAL(12,2). A fixed-point value with two decimals.
|
Index Creation
MySQL Server
CREATE TABLE
statement.
mSQL
CREATE INDEX statements.
To Insert a Unique Identifier into a Table
MySQL Server
AUTO_INCREMENT as a column type
specifier.
「8.4.3.130 mysql_insert_id()」節参照.
mSQL
SEQUENCE on a table and select the _seq column.
To Obtain a Unique Identifier for a Row
MySQL Server
PRIMARY KEY or UNIQUE key to the table and use this.
New in Version 3.23.11: If the PRIMARY or UNIQUE key consists of only one
column and this is of type integer, one can also refer to it as
_rowid.
mSQL
_rowid column. Observe that _rowid may change over time
depending on many factors.
To Get the Time a Column Was Last Modified
MySQL Server
TIMESTAMP column to the table. This column is automatically set
to the current date and time for INSERT or UPDATE statements if
you don't give the column a value or if you give it a NULL value.
mSQL
_timestamp column.
NULL Value Comparisons
MySQL Server
NULL is always NULL.
mSQL
mSQL, NULL = NULL is TRUE. You
must change =NULL to IS NULL and <>NULL to
IS NOT NULL when porting old code from mSQL to MySQL Server.
String Comparisons
MySQL Server
BINARY attribute, which causes comparisons to be done according to the
ASCII order used on the MySQL server host.
mSQL
Case-insensitive Searching
MySQL Server
LIKE is a case-insensitive or case-sensitive operator, depending on
the columns involved. If possible, MySQL uses indexes if the
LIKE argument doesn't start with a wildcard character.
mSQL
CLIKE.
Handling of Trailing Spaces
MySQL Server
CHAR and VARCHAR
columns. Use a TEXT column if this behaviour is not desired.
mSQL
WHERE Clauses
MySQL Server
AND is evaluated
before OR). To get mSQL behaviour in MySQL Server, use
parentheses (as shown in an example later in this section).
mSQL
mSQL query:
mysql> SELECT * FROM table WHERE a=1 AND b=2 OR a=3 AND b=4;To make MySQL Server evaluate this the way that
mSQL would,
you must add parentheses:
mysql> SELECT * FROM table WHERE (a=1 AND (b=2 OR (a=3 AND (b=4))));
Access Control
MySQL Server
mSQL
PostgreSQLWhen reading the following, please note that both products are continually evolving. We at MySQL AB and the PostgreSQL developers are both working on making our respective databases as good as possible, so we are both a serious alternative to any commercial database.
The following comparison is made by us at MySQL AB. We have tried to be as accurate and fair as possible, but although we know MySQL Server thoroughly, we don't have a full knowledge of all PostgreSQL features, so we may have got some things wrong. We will, however, correct these when they come to our attention.
We would first like to note that PostgreSQL and MySQL Server are both widely used
products, but with different design goals, even if we are both striving
toward ANSI SQL compliancy. This means that for some applications MySQL Server
is more suited, while for others PostgreSQL is more suited. When choosing
which database to use, you should first check if the database's feature set
satisfies your application. If you need raw speed, MySQL Server is probably your
best choice. If you need some of the extra features that only PostgreSQL
can offer, you should use PostgreSQL.
When adding things to MySQL Server we take pride to do an optimal, definite solution. The code should be so good that we shouldn't have any need to change it in the foreseeable future. We also do not like to sacrifice speed for features but instead will do our utmost to find a solution that will give maximal throughput. This means that development will take a little longer, but the end result will be well worth this. This kind of development is only possible because all server code are checked by one of a few (currently two) persons before it's included in the MySQL server.
We at MySQL AB believe in frequent releases to be able to push out new features quickly to our users. Because of this we do a new small release about every three weeks, and a major branch every year. All releases are thoroughly tested with our testing tools on a lot of different platforms.
PostgreSQL is based on a kernel with lots of contributors. In this setup it makes sense to prioritise adding a lot of new features, instead of implementing them optimally, because one can always optimise things later if there arises a need for this.
Another big difference between MySQL Server and PostgreSQL is that nearly all of the code in the MySQL server is coded by developers that are employed by MySQL AB and are still working on the server code. The exceptions are the transaction engines and the regexp library.
This is in sharp contrast to the PostgreSQL code, the majority of which is coded by a big group of people with different backgrounds. It was only recently that the PostgreSQL developers announced that their current developer group had finally had time to take a look at all the code in the current PostgreSQL release.
Both of the aforementioned development methods have their own merits and drawbacks. We here at MySQL AB think, of course, that our model is better because our model gives better code consistency, more optimal and reusable code, and in our opinion, fewer bugs. Because we are the authors of the MySQL server code, we are better able to coordinate new features and releases.
On the crash-me page
(http://www.mysql.com/information/crash-me.php)
you can find a list of those database constructs and limits that
one can detect automatically with a program. Note, however, that a lot of
the numerical limits may be changed with startup options for their respective
databases. This web page is, however, extremely useful when you want to
ensure that your applications work with many different databases or
when you want to convert your application from one database to another.
MySQL Server offers the following advantages over PostgreSQL:
MySQL Server is generally much faster than PostgreSQL. MySQL
4.0.1 also has a query cache that can boost up the query speed for
mostly-read-only sites many times.
Cygwin emulation. We have
heard that PostgreSQL is not yet that stable on Windows but we haven't
been able to verify this ourselves.
VACUUM
once in a while to reclaim space from UPDATE and DELETE
commands and to perform statistics analyses that are critical to get
good performance with PostgreSQL. VACUUM is also needed after
adding a lot of new rows to a table. On a busy system with lots of changes,
VACUUM must be run very frequently, in the worst cases even
many times a day. During the VACUUM run, which may take hours
if the database is big, the database is, from a production standpoint,
practically dead. Please note: in PostgreSQL version 7.2, basic vacuuming
no longer locks tables, thus allowing normal user access during the vacuum.
A new VACUUM FULL command does old-style vacuum by locking the table
and shrinking the on-disk copy of the table.
crash-me
(http://www.mysql.com/information/crash-me.php), as well
as a benchmark suite. The test system is actively updated with code to
test each new feature and almost all reproduceable bugs that have come to
our attention. We test MySQL Server with these on a lot of platforms before
every release. These tests are more sophisticated than anything we have
seen from PostgreSQL, and they ensure that the MySQL Server is kept to a high
standard.
PostgreSQL.
ALTER TABLE.
HEAP
tables or disk based MyISAM. 「7 MySQL テーブル型」節参照.
InnoDB, and BerkeleyDB. Because every
transaction engine performs differently under different conditions, this
gives the application writer more options to find an optimal solution for
his or her setup, if need be per individual table. 「7 MySQL テーブル型」節参照.
MERGE tables gives you a unique way to instantly make a view over
a set of identical tables and use these as one. This is perfect for
systems where you have log files that you order, for example, by month.
「7.2 MERGE Tables (3.23.25以上)」節参照.
myisampack, MySQL の圧縮された読み込み専用テーブルジェネレータ」節参照.
INSERT,
SELECT, and UPDATE/DELETE grants per user on a database or
a table, MySQL Server allows you to define a full set of different
privileges on the database, table, and column level. MySQL Server also
allows you to specify the privilege on host and user combinations.
「4.3.1 GRANT と REVOKE 構文」節参照.
InnoDB) are implemented as files
(one table per file), which makes it really easy to back up, move, delete,
and even symlink databases and tables, even when the server is down.
MyISAM tables (the most common
MySQL table type). A repair tool is only needed when a physical corruption
of a datafile happens, usually from a hardware failure. It allows a
majority of the data to be recovered.
Drawbacks with MySQL Server compared to PostgreSQL:
MyISAM tables, is
in many cases faster than page locks, row locks, or versioning. The
drawback, however, is that if one doesn't take into account how table
locks work, a single long-running query can block a table for updates
for a long time. This can usually be avoided when designing the
application. If not, one can always switch the trouble table to use one
of the transactional table types. 「5.3.2 テーブル・ロッキングの問題」節参照.
UPDATE and in MySQL Server 4.1 with subselects.
In MySQL Server 4.0 one can use multi-table deletes to delete from many
tables at the same time. 「6.4.6 DELETE 構文」節参照.
PostgreSQL currently offers the following advantages over MySQL Server:
Note that because we know the MySQL road map, we have included in the following table the version when MySQL Server should support this feature. Unfortunately we couldn't do this for previous comparisons, because we don't know the PostgreSQL roadmap.
| Feature | MySQL version |
| Subselects | 4.1 |
| Foreign keys | 5.0 (3.23 with InnoDB) |
| Views | 5.0 |
| Stored procedures | 5.0 |
| Triggers | 5.0 |
| Unions | 4.0 |
| Full join | 4.1 |
| Constraints | 4.1 or 5.0 |
| Cursors | 4.1 or 5.0 |
| R-trees | 4.1 (for MyISAM tables) |
| Inherited tables | Not planned |
| Extensible type system | Not planned |
Other reasons someone may consider using PostgreSQL:
Drawbacks with PostgreSQL compared to MySQL Server:
VACUUM makes PostgreSQL hard to use in a 24/7 environment.
INSERT, DELETE, and UPDATE.
For a complete list of drawbacks, you should also examine the first table in this section.
The only Open Source benchmark that we know of that can be used to
benchmark MySQL Server and PostgreSQL (and other databases) is our own. It can
be found at http://www.mysql.com/information/benchmarks.html.
We have many times asked the PostgreSQL developers and some PostgreSQL users to help us extend this benchmark to make it the definitive benchmark for databases, but unfortunately we haven't gotten any feedback for this.
We, the MySQL developers, have, because of this, spent a lot of hours to get maximum performance from PostgreSQL for the benchmarks, but because we don't know PostgreSQL intimately, we are sure that there are things that we have missed. We have on the benchmark page documented exactly how we did run the benchmark so that it should be easy for anyone to repeat and verify our results.
The benchmarks are usually run with and without the --fast option.
When run with --fast we are trying to use every trick the server can
do to get the code to execute as fast as possible. The idea is that the
normal run should show how the server would work in a default setup and
the --fast run shows how the server would do if the application
developer would use extensions in the server to make his application run
faster.
When running with PostgreSQL and --fast we do a VACUUM
after every major table UPDATE and DROP TABLE to make the
database in perfect shape for the following SELECTs. The time for
VACUUM is measured separately.
When running with PostgreSQL 7.1.1 we could, however, not run with
--fast because during the INSERT test, the postmaster (the
PostgreSQL deamon) died and the database was so corrupted that it was
impossible to restart postmaster. After this happened twice, we decided
to postpone the --fast test until the next PostgreSQL release. The
details about the machine we run the benchmark on can be found on the
benchmark page.
Before going to the other benchmarks we know of, we would like to give some background on benchmarks.
It's very easy to write a test that shows any database to be the best database in the world, by just restricting the test to something the database is very good at and not testing anything that the database is not good at. If one, after doing this, summarises the result as a single figure, things are even easier.
This would be like us measuring the speed of MySQL Server compared to PostgreSQL by looking at the summary time of the MySQL benchmarks on our web page. Based on this MySQL Server would be more than 40 times faster than PostgreSQL, something that is, of course, not true. We could make things even worse by just taking the test where PostgreSQL performs worst and claim that MySQL Server is more than 2000 times faster than PostgreSQL.
The case is that MySQL does a lot of optimisations that PostgreSQL doesn't do. This is, of course, also true the other way around. An SQL optimiser is a very complex thing, and a company could spend years just making the optimiser faster and faster.
When looking at the benchmark results you should look for things that you do in your application and just use these results to decide which database would be best suited for your application. The benchmark results also show things a particular database is not good at and should give you a notion about things to avoid and what you may have to do in other ways.
We know of two benchmark tests that claim that PostgreSQL performs better than MySQL Server. These both where multi-user tests, a test that we here at MySQL AB haven't had time to write and include in the benchmark suite, mainly because it's a big task to do this in a manner that is fair to all databases.
One is the benchmark paid for by Great Bridge, the company that for 16 months attempted to build a business based on PostgreSQL but now has ceased operations. This is probably the worst benchmark we have ever seen anyone conduct. This was not only tuned to only test what PostgreSQL is absolutely best at, but it was also totally unfair to every other database involved in the test.
Note: We know that even some of the main PostgreSQL developers did not like the way Great Bridge conducted the benchmark, so we don't blame the PostgreSQL team for the way the benchmark was done.
This benchmark has been condemned in a lot of postings and newsgroups, so here we will just briefly repeat some things that were wrong with it.
Open Source company like us to verify the benchmarks,
or even check how the benchmarks were really done. The tool is not even
a true benchmark tool, but an application/setup testing tool. To refer
to this as a ``standard'' benchmark tool is to stretch the truth a long way.
VACUUM before the test) and tuned the startup for the tests,
something they hadn't done for any of the other databases involved. They
say ``This process optimises indexes and frees up disk space a bit. The
optimised indexes boost performance by some margin.'' Our benchmarks
clearly indicate that the difference in running a lot of selects on a
database with and without VACUUM can easily differ by a factor
of 10.
SELECTs and JOINs (especially
after a VACUUM), but doesn't perform as well on INSERTs or
UPDATEs. The benchmarks seem to indicate that only SELECTs
were done (or very few updates). This could easily explain the good results
for PostgreSQL in this test. The bad results for MySQL will be obvious a
bit down in this document.
Tim Perdue, a long-time PostgreSQL fan and a reluctant MySQL user, published a comparison on PHPbuilder (http://www.phpbuilder.com/columns/tim20001112.php3).
When we became aware of the comparison, we phoned Tim Perdue about this because there were a lot of strange things in his results. For example, he claimed that MySQL Server had a problem with five users in his tests, when we know that there are users with similar machines as his that are using MySQL Server with 2000 simultaneous connections doing 400 queries per second. (In this case the limit was the web bandwidth, not the database.)
It sounded like he was using a Linux kernel that either had some problems with many threads, such as kernels before 2.4, which had a problem with many threads on multi-CPU machines. We have documented in this manual how to fix this and Tim should be aware of this problem.
The other possible problem could have been an old glibc library and that Tim didn't use a MySQL binary from our site, which is linked with a corrected glibc library, but had compiled a version of his own. In any of these cases, the symptom would have been exactly what Tim had measured.
We asked Tim if we could get access to his data so that we could repeat the benchmark and if he could check the MySQL version on the machine to find out what was wrong and he promised to come back to us about this. He has not done that yet.
Because of this we can't put any trust in this benchmark either. :(
Over time things also change and the preceding benchmarks are not that relevant anymore. MySQL Server now has a couple of different storage engines with different speed/concurrency tradeoffs. 「7 MySQL テーブル型」節参照. It would be interesting to see how the above tests would run with the different transactional table types in MySQL Server. PostgreSQL has, of course, also got new features since the test was made. As these tests are not publicly available there is no way for us to know how the database would perform in the same tests today.
Conclusion:
The only benchmarks that exist today that anyone can download and run
against MySQL Server and PostgreSQL are the MySQL benchmarks.
We here at MySQL AB
believe that Open Source databases should be tested with Open Source tools!
This is the only way to ensure that no one does tests that nobody can
reproduce and use this to claim that one database is better than another.
Without knowing all the facts it's impossible to answer the claims of the
tester.
The thing we find strange is that every test we have seen about PostgreSQL, that is impossible to reproduce, claims that PostgreSQL is better in most cases while our tests, which anyone can reproduce, clearly show otherwise. With this we don't want to say that PostgreSQL isn't good at many things (it is!) or that it isn't faster than MySQL Server under certain conditions. We would just like to see a fair test where PostgreSQL performs very well, so that we could get some friendly competition going!
For more information about our benchmark suite, see 「5.1.4 The MySQL Benchmark Suite」節.
We are working on an even better benchmark suite, including multi-user tests, and a better documentation of what the individual tests really do and how to add more tests to the suite.
Go to the first, previous, next, last section, table of contents.