Planet MySQL http://www.planetmysql.org/ Sun, 29 Jan 2012 04:30:01 +0000 jp Planet MySQL - http://www.planetmysql.org/ mysqldumpの--order-by-primaryオプションについて http://d.hatena.ne.jp/sh2/20120122 http://d.hatena.ne.jp/sh2/20120122 TIPSです。このようなテーブルがありまして、 CREATE TABLE `link` ( `id1` int(11) NOT NULL DEFAULT &#39;0&#39;, `id2` int(11) NOT NULL DEFAULT &#39;0&#39;, PRIMARY KEY (`id1`,`id2`), KEY `ix1` (`id2`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; データは以下のような感じで、このときは2,900万レコードありました。 +---------+---------+ | id1 | id2 | +---------+---------+ | 5 | 69 | | 5 | 1022 | | 5 | 1487 | … | 1081 | 2021414 | | 1081 | 2087813 | | 1082 | 11 | | 1082 | 225 | … | 2494267 | 158887 | | 2494267 | 178845 | | 2494267 | 631394 | +---------+---------+ mysqldumpコマンドでバックアップすると、11秒で444MBのダンプファイルが出力されました。 $ time mysqldump -u xxx -pxxx xxx link &#62; link.sql real 0m11.391s user 0m8.527s sys 0m0.529s $ ls -lh -rw-rw-r-- 1 taira taira 444M 1月 22 18:39 2012 link.sql ところが、mysqlコマンドでリストアしようとすると異常に遅い。 $ time mysql -u xxx -pxxx xxx &#60; link.sql real 94m23.951s user 0m11.661s sys 0m0.171s わずか444MBのリストアに1時間半というのは尋常でない値で、どうしてだろうと思ってダンプファイルを見てみるとデータが主キーでソートされていないのです。 -- -- Dumping data for table `link` -- LOCK TABLES `link` WRITE; /&#42;!40000 ALTER TABLE `link` DISABLE KEYS &#42;/; INSERT INTO `link` VALUES (1104,5),(1690,5),(6932,5),(7679,5),(8419,5),(10247,5) ,(11909,5),(13663,5),(13957,5),(16421,5),(51108,5),(56051,5),(68176,5),(73209,5) ,(74134,5),(80094,5),(80243,5),(90949,5),(105566,5),(141127,5),(146550,5),(14655 9,5),(147375,5),(164871,5),(172267,5),(197350,5),(214173,5),(256744,5),(260201,5 ),(295368,5),(363992,5),(467450,5),(535783,5),(619395,5),(651702,5),(688537,5),( 704851,5),(768590,5),(797017,5),(832366,5),(913097,5),(1072902,5),(1073296,5),(1 073968,5),(1074097,5),(1076529,5),(1076588,5),(1076596,5),(1099565,5),(1119078,5 ),(1134413,5),(1206043,5),(1217529,5),(1221166,5),(1284145,5),(1366678,5),(14288 06,5),(1520730,5),(1534350,5),(1601227,5),(1605124,5),(1643972,5),(1764627,5),(1 790257,5),(1806513,5),(2002342,5),(2092470,5),(2303850,5),(2323218,5),(2448464,5 ),(2459478,5),(2474731,5),(11,10),(58,10),(64,10),(68,10),(69,10),(91,10),(92,10 ),(102,10),(110,10),(115,10),(139,10),(159,10),(161,10),(312,10),(326,10),(1034, … 主キーでソートされていないデータのINSERTが遅いというのは、クラスタインデックスを利用しているInnoDBの宿命のようなものです。それにしても、なぜ主キーでソートされていないのでしょうか。 調べた結果、以下のことが分かりました。 mysqldumpは単純に「SELECT /*!40001 SQL_NO_CACHE */ * FROM `link`」というSQLを実行しているだけである。 単純な全レコード取得に対して、MySQLがテーブルフルスキャン(InnoDBでは主キーのフルスキャンと同義)を選ぶとは限らない。 mysql&#62; EXPLAIN SELECT &#42; FROM link FORCE INDEX (PRIMARY); +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ | 1 | SIMPLE | link | index | NULL | PRIMARY | 8 | NULL | 29403733 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ 1 row in set (0.00 sec) mysql&#62; EXPLAIN SELECT &#42; FROM link; +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ | 1 | SIMPLE | link | index | NULL | ix1 | 4 | NULL | 29403733 | Using index | +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ 1 row in set (0.00 sec) 今回id2カラムに対してix1というインデックスが作成されていて、InnoDBのセカンダリインデックスはリーフブロックの各インデックスエントリに主キーを含むのでこれは事実上カバーリングインデックスになっています。key_lenの値を見ると主キーの場合は8であるのに対してix1の場合は4となっており、MySQLからするとどうやらix1の方が効率的に見えてしまうようなのです。結果としてダンプファイルのデータは主キーでソートされていない状態で出力され、リストアの性能が大きく低下することになります。mysqldumpが悪いのかそれともmysqldが悪いのかは判断が難しいところですが、とにかくこれは不具合だと思いましたので報告しておきました(Bug#64097)。MySQL 5.5.20と5.1.61で確認済みです。 幸いにも簡単な回避方法があって、mysqldumpに--order-by-primaryオプションを付与することで「SELECT /*!40001 SQL_NO_CACHE */ * FROM `link` ORDER BY `id1`,`id2`」と明示的に主キーでソートしてくれるようになります。InnoDBのテーブルに対してmysqldumpを実行する際は、当面--order-by-primaryオプションを付与しておいた方が安全ではないかというのが私の見解です。 おまけとして、innodb_buffer_pool_sizeの設定とダンプファイルのデータが主キーでソートされているかどうかによって、リストア時間がどのように変化するのかを調べてみました。 innodb_buffer_pool_sizeがテーブルサイズに比べて大きい場合は、ダンプファイルが主キーでソートされていなくてもそれほど問題はありません。一方innodb_buffer_pool_sizeがテーブルサイズに比べて小さい場合は、リストア時間に大きな差が現れます。innodb_buffer_pool_sizeが小さく主キーでソートされていないパターンでは、リストア中ずっとストレージに対するランダムアクセスが続いていました。今回はストレージにPLEXTOR SSD M2Pシリーズ PX-256M2Pを使用してこの性能なので、普通のHDDだとさらに長い時間がかかることになります。 mysqldumpコマンドでバックアップすると、11秒で444MBのダンプファイルが出力されました。 $ time mysqldump -u xxx -pxxx xxx link > link.sql real 0m11.391s user 0m8.527s sys 0m0.529s $ ls -lh -rw-rw-r-- 1 taira taira 444M 1月 22 18:39 2012 link.sql ところが、mysqlコマンドでリストアしようとすると異常に遅い。 $ time mysql -u xxx -pxxx xxx < link.sql real 94m23.951s user 0m11.661s sys 0m0.171s わずか444MBのリストアに1時間半というのは尋常でない値で、どうしてだろうと思ってダンプファイルを見てみるとデータが主キーでソートされていないのです。 -- -- Dumping data for table `link` -- LOCK TABLES `link` WRITE; /*!40000 ALTER TABLE `link` DISABLE KEYS */; INSERT INTO `link` VALUES (1104,5),(1690,5),(6932,5),(7679,5),(8419,5),(10247,5) ,(11909,5),(13663,5),(13957,5),(16421,5),(51108,5),(56051,5),(68176,5),(73209,5) ,(74134,5),(80094,5),(80243,5),(90949,5),(105566,5),(141127,5),(146550,5),(14655 9,5),(147375,5),(164871,5),(172267,5),(197350,5),(214173,5),(256744,5),(260201,5 ),(295368,5),(363992,5),(467450,5),(535783,5),(619395,5),(651702,5),(688537,5),( 704851,5),(768590,5),(797017,5),(832366,5),(913097,5),(1072902,5),(1073296,5),(1 073968,5),(1074097,5),(1076529,5),(1076588,5),(1076596,5),(1099565,5),(1119078,5 ),(1134413,5),(1206043,5),(1217529,5),(1221166,5),(1284145,5),(1366678,5),(14288 06,5),(1520730,5),(1534350,5),(1601227,5),(1605124,5),(1643972,5),(1764627,5),(1 790257,5),(1806513,5),(2002342,5),(2092470,5),(2303850,5),(2323218,5),(2448464,5 ),(2459478,5),(2474731,5),(11,10),(58,10),(64,10),(68,10),(69,10),(91,10),(92,10 ),(102,10),(110,10),(115,10),(139,10),(159,10),(161,10),(312,10),(326,10),(1034, … 主キーでソートされていないデータのINSERTが遅いというのは、クラスタインデックスを利用しているInnoDBの宿命のようなものです。それにしても、なぜ主キーでソートされていないのでしょうか。 調べた結果、以下のことが分かりました。 mysqldumpは単純に「SELECT /*!40001 SQL_NO_CACHE */ * FROM `link`」というSQLを実行しているだけである。 単純な全レコード取得に対して、MySQLがテーブルフルスキャン(InnoDBでは主キーのフルスキャンと同義)を選ぶとは限らない。 mysql> EXPLAIN SELECT * FROM link FORCE INDEX (PRIMARY); +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ | 1 | SIMPLE | link | index | NULL | PRIMARY | 8 | NULL | 29403733 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+----------+-------------+ 1 row in set (0.00 sec) mysql> EXPLAIN SELECT * FROM link; +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ | 1 | SIMPLE | link | index | NULL | ix1 | 4 | NULL | 29403733 | Using index | +----+-------------+-------+-------+---------------+------+---------+------+----------+-------------+ 1 row in set (0.00 sec) 今回id2カラムに対してix1というインデックスが作成されていて、InnoDBのセカンダリインデックスはリーフブロックの各インデックスエントリに主キーを含むのでこれは事実上カバーリングインデックスになっています。key_lenの値を見ると主キーの場合は8であるのに対してix1の場合は4となっており、MySQLからするとどうやらix1の方が効率的に見えてしまうようなのです。結果としてダンプファイルのデータは主キーでソートされていない状態で出力され、リストアの性能が大きく低下することになります。mysqldumpが悪いのかそれともmysqldが悪いのかは判断が難しいところですが、とにかくこれは不具合だと思いましたので報告しておきました(Bug#64097)。MySQL 5.5.20と5.1.61で確認済みです。 幸いにも簡単な回避方法があって、mysqldumpに--order-by-primaryオプションを付与することで「SELECT /*!40001 SQL_NO_CACHE */ * FROM `link` ORDER BY `id1`,`id2`」と明示的に主キーでソートしてくれるようになります。InnoDBのテーブルに対してmysqldumpを実行する際は、当面--order-by-primaryオプションを付与しておいた方が安全ではないかというのが私の見解です。 おまけとして、innodb_buffer_pool_sizeの設定とダンプファイルのデータが主キーでソートされているかどうかによって、リストア時間がどのように変化するのかを調べてみました。 innodb_buffer_pool_sizeがテーブルサイズに比べて大きい場合は、ダンプファイルが主キーでソートされていなくてもそれほど問題はありません。一方innodb_buffer_pool_sizeがテーブルサイズに比べて小さい場合は、リストア時間に大きな差が現れます。innodb_buffer_pool_sizeが小さく主キーでソートされていないパターンでは、リストア中ずっとストレージに対するランダムアクセスが続いていました。今回はストレージにPLEXTOR SSD M2Pシリーズ PX-256M2Pを使用してこの性能なので、普通のHDDだとさらに長い時間がかかることになります。
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 22 Jan 2012 00:00:00 +0000 Sadao Hiratsuka 読まないなんてもったいない! MySQL Casual Advent Calendar http://blog.kimuradb.com/?eid=877282 http://blog.kimuradb.com/?eid=877282 タイミングとして、いま紹介するのは周回遅れ感は否めない(笑)のですが、実は一昨年の12月からMySQLのAdvent Calendarが有志により行われています。「Advent Calendarって何? それおいしいの?」という私に準ずる方はこのリンクやこのリンクを見てもらうとして、まぁ12月に日めくりでMySQLのTipsをみて「へぇ〜」を連発できるというものです(私の理解)各エントリ着眼点からおもしろいですね。12月にはAdvent Calendarを知らなくて、日めくりできなかったり、知っていても忙しくて(年末進行、年末進行)チェックできなかったかたは、是非以下のリンクからチェックしてみてください!!おもしろいですよ。 MySQL Casual Advent Calendar 2011 MySQL Casual Advent Calendar 2010 そして今年は是非参加しましょう! JUGEMテーマ：コンピュータ このリンクやこのリンクを見てもらうとして、まぁ12月に日めくりでMySQLのTipsをみて「へぇ〜」を連発できるというものです(私の理解)各エントリ着眼点からおもしろいですね。12月にはAdvent Calendarを知らなくて、日めくりできなかったり、知っていても忙しくて(年末進行、年末進行)チェックできなかったかたは、是非以下のリンクからチェックしてみてください!!おもしろいですよ。

MySQL Casual Advent Calendar 2011

MySQL Casual Advent Calendar 2010

そして今年は是非参加しましょう!

JUGEMテーマ：コンピュータ



PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sat, 21 Jan 2012 03:24:00 +0000 MeijiK MySQL 読まないなんてもったいない! MySQL関連の連載記事 http://blog.kimuradb.com/?eid=877280 http://blog.kimuradb.com/?eid=877280 MySQLには日本語・英語で様々な良本があるのですが、もちろん無料で読めるWeb上の記事にもそれに迫る(いや一部それ以上の)良い記事があります。特に今ちょうど連載されている記事は毎記事ごとに臨場感があってGoodではないでしょうか? いや、読まないなんてもったいない!! ビギナーのあなたにはこの連載記事などどうでしょうか? MySQL事始 また、MySQL 5.6.xの動向が気になったり、今後採用を検討している人がざっくり新機能を知りたい場合には次の連載記事をお勧めします。 MySQL製品最新事情 上記の二連載はエバンジェリスト梶山さんのものですが、MySQLといえば、そう漢(オトコ)を忘れてはいけません。たっぷり「濃い」説明を堪能したい中〜上級者のあなたは、オトコの記事でヒートアップしよう! MySQLチューニング虎の巻 ここからも参照されているオトコの一冊。各MySQLイベントで褒め殺し(笑)されているこの本はMySQL関係者必携の良書です。 JUGEMテーマ：コンピュータ エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド エキスパートのためのMySQL[...の他のレビューをみる&raquo; 評価： 奥野 幹也 技術評論社 ￥ 3,465 (2010-06-12)
ビギナーのあなたにはこの連載記事などどうでしょうか?

MySQL事始

また、MySQL 5.6.xの動向が気になったり、今後採用を検討している人がざっくり新機能を知りたい場合には次の連載記事をお勧めします。

MySQL製品最新事情

上記の二連載はエバンジェリスト梶山さんのものですが、MySQLといえば、そう漢(オトコ)を忘れてはいけません。たっぷり「濃い」説明を堪能したい中〜上級者のあなたは、オトコの記事でヒートアップしよう!

MySQLチューニング虎の巻

ここからも参照されているオトコの一冊。各MySQLイベントで褒め殺し(笑)されているこの本はMySQL関係者必携の良書です。

JUGEMテーマ：コンピュータ


PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 17 Jan 2012 14:49:09 +0000 MeijiK MySQL MySQL 5.6.4でマイクロ秒までサポート(TIME, DATETIME, TIMESTAMP) http://blog.kimuradb.com/?eid=877275 http://blog.kimuradb.com/?eid=877275 オトコの熱いブログエントリのとおり大幅な進歩を遂げつつあるMySQL 5.6 最新のMySQL 5.6.4では首記のとおり、時刻を格納するカラムにマイクロ秒まで格納できるようになりました。 fsp(fractional seconds part)として0〜6を指定できます。Release notesにある以下の例だと、それぞれ小数点以下三桁、六桁が指定できます。 CREATE TABLE t1 (t TIME(3), dt DATETIME(6)); fspは無指定の場合0となります。これは既存のものとの互換性のためです。 現在の時刻を示す関数にもfspが指定できるようになり、それを格納できます。こんな感じになります。 mysql> insert into t1 values(now(6),now(6)); Query OK, 1 row affected (0.00 sec) mysql> select * from t1; +--------------+----------------------------+ | t | dt | +--------------+----------------------------+ | 23:54:49.672 | 2012-01-08 23:54:49.672366 | +--------------+----------------------------+ 1 row in set (0.00 sec) 商用RDBMSの多くが秒以下の単位まで格納できていたので、これで移行なども簡単になると思います。 JUGEMテーマ：コンピュータ オトコの熱いブログエントリのとおり大幅な進歩を遂げつつあるMySQL 5.6
最新のMySQL 5.6.4では首記のとおり、時刻を格納するカラムにマイクロ秒まで格納できるようになりました。
fsp(fractional seconds part)として0〜6を指定できます。Release notesにある以下の例だと、それぞれ小数点以下三桁、六桁が指定できます。

CREATE TABLE t1 (t TIME(3), dt DATETIME(6));

fspは無指定の場合0となります。これは既存のものとの互換性のためです。

現在の時刻を示す関数にもfspが指定できるようになり、それを格納できます。こんな感じになります。

mysql> insert into t1 values(now(6),now(6));
Query OK, 1 row affected (0.00 sec)

mysql> select * from t1;
+--------------+----------------------------+
| t | dt |
+--------------+----------------------------+
| 23:54:49.672 | 2012-01-08 23:54:49.672366 |
+--------------+----------------------------+
1 row in set (0.00 sec)

商用RDBMSの多くが秒以下の単位まで格納できていたので、これで移行なども簡単になると思います。

JUGEMテーマ：コンピュータ



PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 08 Jan 2012 15:07:22 +0000 MeijiK MySQL [勝手に補足]触って学べるOSS-DB試験第3回運用管理 http://blog.kimuradb.com/?eid=877277 http://blog.kimuradb.com/?eid=877277 日経 Linux (リナックス) 2012年 01月号 [雑誌] 日経 Linux (リナックス) 201...の他のレビューをみる&raquo; 評価： --- 日経BP社 ￥ 1,490 (2011-12-08) 本誌ではAndroid 4.0のすべて、などありますが、また地味にDBを進めます。 例題1.多くのRDBMSではディスク上にデータベース格納領域を初期化する必要があります。この格納領域をPostgreSQLでは「データベースクラスタ」と呼びます。通常「クラスタ」といって我々が想像するようなものではありません。MySQLでいうところのデータディレクトリです。(そしてMySQLの場合はmysql_install_dbで初期化します) Firebirdはシステム関連のデータベースはインストール時に作成され、あとはデータベース=ファイルなので、特に「データベース格納領域」という概念はありません。 例題2.うーん、容量見積もりですが、これは役立つのですかね? FILLFACTOR(OracleのPCTFREE)みたいなやつは、まぁデフォルトの90で、あとはインデックス無し? そしてtextの平均超を与えてもらえれば。。。。って単なる計算問題ではないのでしょうか?　 例題3.プロセスの概念。マルチプロセスで作成されている、というのがわかればいいわけですね。MySQLはマルチスレッド、そしてFirebirdは両方あります。(クラシックサーバ=プロセスモデル、スーパーサーバ=スレッドモデル) 例題4.認証はそれぞれのデータベース独特ですね。MySQLの場合通常のデータベース認証であるユーザ/パスワードのユーザ部分にホスト名やIP Addressを含む定義ができます。またMySQL 5.5.16からプラガブルな認証モジュール(PAMやWindows統合認証)が商用バージョンのみ添付されるようになりました。 Firebirdの場合、通常の認証以外にUnixの認証や、Windowの統合認証も利用できます。 例題5.例題6.をみる場合は、ここいらをまず見た方がいいですね。すべてミックさんの連載です。 第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（1） 第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（2） 第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（3） これらが雑誌に掲載されたときの、私の補足記事でMySQL/Firebirdはカバーできるはずです。 [勝手に補足]DBアタマアカデミー第4回クエリ評価エンジンと実行計画 [勝手に補足]DBアタマアカデミー第4回クエリ評価エンジンと実行計画(続き) 例題5.については選択肢2.3.がPostgreSQL用のもので、答えは普遍的なものです。 また、例題6.のうち、ANALYZEは一般的、VACUUMはPostgreSQL独特のものです。 と、いうことで6問中一般的なのは例題3(むりやり)例題5の二つで、後はPostgreSQL独自ということで。 JUGEMテーマ：コンピュータ

本誌ではAndroid 4.0のすべて、などありますが、また地味にDBを進めます。

例題1.多くのRDBMSではディスク上にデータベース格納領域を初期化する必要があります。この格納領域をPostgreSQLでは「データベースクラスタ」と呼びます。通常「クラスタ」といって我々が想像するようなものではありません。MySQLでいうところのデータディレクトリです。(そしてMySQLの場合はmysql_install_dbで初期化します)

Firebirdはシステム関連のデータベースはインストール時に作成され、あとはデータベース=ファイルなので、特に「データベース格納領域」という概念はありません。

例題2.うーん、容量見積もりですが、これは役立つのですかね? FILLFACTOR(OracleのPCTFREE)みたいなやつは、まぁデフォルトの90で、あとはインデックス無し? そしてtextの平均超を与えてもらえれば。。。。って単なる計算問題ではないのでしょうか?　

例題3.プロセスの概念。マルチプロセスで作成されている、というのがわかればいいわけですね。MySQLはマルチスレッド、そしてFirebirdは両方あります。(クラシックサーバ=プロセスモデル、スーパーサーバ=スレッドモデル)

例題4.認証はそれぞれのデータベース独特ですね。MySQLの場合通常のデータベース認証であるユーザ/パスワードのユーザ部分にホスト名やIP Addressを含む定義ができます。またMySQL 5.5.16からプラガブルな認証モジュール(PAMやWindows統合認証)が商用バージョンのみ添付されるようになりました。

Firebirdの場合、通常の認証以外にUnixの認証や、Windowの統合認証も利用できます。

例題5.例題6.をみる場合は、ここいらをまず見た方がいいですね。すべてミックさんの連載です。

第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（1）
第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（2）
第4回　クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（3）

これらが雑誌に掲載されたときの、私の補足記事でMySQL/Firebirdはカバーできるはずです。

[勝手に補足]DBアタマアカデミー第4回クエリ評価エンジンと実行計画
[勝手に補足]DBアタマアカデミー第4回クエリ評価エンジンと実行計画(続き)

例題5.については選択肢2.3.がPostgreSQL用のもので、答えは普遍的なものです。
また、例題6.のうち、ANALYZEは一般的、VACUUMはPostgreSQL独特のものです。

と、いうことで6問中一般的なのは例題3(むりやり)例題5の二つで、後はPostgreSQL独自ということで。

JUGEMテーマ：コンピュータ



PlanetMySQL Voting: Vote UP / Vote DOWN]]> Wed, 04 Jan 2012 10:34:00 +0000 MeijiK データベース [勝手に補足]触って学べるOSS-DB試験第2回基本的なSQLからパラメーターの設定まで http://blog.kimuradb.com/?eid=877276 http://blog.kimuradb.com/?eid=877276 日経 Linux (リナックス) 2011年 12月号 [雑誌] 日経 Linux (リナックス) 201...の他のレビューをみる&raquo; 評価： --- 日経BP社 --- (2011-11-08) 本誌ではWindowsファイル共有を超高速化、などありますが、こちらは地味にDB関連を進めます。。。。お手元に本誌を用意してレッツトライ! 例題1. データベースの一覧を表示するコマンド、ということですが、これはPostgreSQLに特化したものですね「&yen;と英文字一文字」というのは。MySQL ではSHOW DATABASES;になります。Firebirdはデータベース毎に１つ(もしくはそれ以上の)ファイルが割り当てられ、それを指定して動作するため、データベースの一覧という概念はありません。 データ型は一般的で各データベース共通のものと、独特なものがあります。表2.にはなぜかnumeric, decimalがリストアップされていませんがPostgreSQLにもちゃんとあります。これも表にはありませんが、幾何データ型はPostgreSQL特有のものです。 例題2. 文字列照合の問題ですが、このレベルではFirebird/PostgreSQL/MySQLともに共通です。答えも一緒です。 例題3. DBサーバとは別のサーバから接続できるように設定したい。の設定ですが、これもPostgreSQL特有の設定です。逆にMySQLやFirebirdでは別のサーバから設定できるのがデフォルトで、例えばMySQLではskip-networkingオプションを指定して、tcp/ip接続をできないようにして、 --socket で適切な名前付きパイプまたは Unix ソケット ファイルで接続する、という風にします。 例題4. これも考え方は各データベースにより違います。MySQLは起動時に構成ファイル(my.cnf)グローバルに読み込まれ、接続時にローカル(セッション)にコピーされる、と考えるとわかりやすいです。グローバルで動的に変更できるパラメタもありますが、それを変更後、同じ項目がセッションに反映されるのは再接続時イメージです。my.cnfを再度グローバルに反映するには、MySQLサーバの再起動が必要です。 Firebirdの場合はfirebird.confとシステム監査用のfbtrace.confはFirebirdサーバの再起動時に読み込まれます。ユーザのfbtrace.confはトレース開始時点、またalias.confはCREATE/CONNECT DATABASEでデータベースにアクセスした時点で読まれます。 今回は4問のうち、汎用的なものは1問、それ以外はPostgreSQL特有のものでした。ではまた〜。 JUGEMテーマ：コンピュータ

本誌ではWindowsファイル共有を超高速化、などありますが、こちらは地味にDB関連を進めます。。。。お手元に本誌を用意してレッツトライ!

例題1. データベースの一覧を表示するコマンド、ということですが、これはPostgreSQLに特化したものですね「¥と英文字一文字」というのは。MySQL ではSHOW DATABASES;になります。Firebirdはデータベース毎に１つ(もしくはそれ以上の)ファイルが割り当てられ、それを指定して動作するため、データベースの一覧という概念はありません。

データ型は一般的で各データベース共通のものと、独特なものがあります。表2.にはなぜかnumeric, decimalがリストアップされていませんがPostgreSQLにもちゃんとあります。これも表にはありませんが、幾何データ型はPostgreSQL特有のものです。

例題2. 文字列照合の問題ですが、このレベルではFirebird/PostgreSQL/MySQLともに共通です。答えも一緒です。

例題3. DBサーバとは別のサーバから接続できるように設定したい。の設定ですが、これもPostgreSQL特有の設定です。逆にMySQLやFirebirdでは別のサーバから設定できるのがデフォルトで、例えばMySQLではskip-networkingオプションを指定して、tcp/ip接続をできないようにして、 --socket で適切な名前付きパイプまたは Unix ソケット ファイルで接続する、という風にします。

例題4. これも考え方は各データベースにより違います。MySQLは起動時に構成ファイル(my.cnf)グローバルに読み込まれ、接続時にローカル(セッション)にコピーされる、と考えるとわかりやすいです。グローバルで動的に変更できるパラメタもありますが、それを変更後、同じ項目がセッションに反映されるのは再接続時イメージです。my.cnfを再度グローバルに反映するには、MySQLサーバの再起動が必要です。

Firebirdの場合はfirebird.confとシステム監査用のfbtrace.confはFirebirdサーバの再起動時に読み込まれます。ユーザのfbtrace.confはトレース開始時点、またalias.confはCREATE/CONNECT DATABASEでデータベースにアクセスした時点で読まれます。

今回は4問のうち、汎用的なものは1問、それ以外はPostgreSQL特有のものでした。ではまた〜。

JUGEMテーマ：コンピュータ



PlanetMySQL Voting: Vote UP / Vote DOWN]]> Tue, 03 Jan 2012 07:40:00 +0000 MeijiK データベース MySQL 5.0のプロダクトライフサイクルが終了 http://d.hatena.ne.jp/sh2/20120101 http://d.hatena.ne.jp/sh2/20120101 あけましておめでとうございます。今年もよろしくお願いいたします。 新年最初から注意喚起ですが、2011年12月31日をもってMySQL 5.0のプロダクトライフサイクルが終了しました。今後MySQL 5.0に対して新たなバグ修正やセキュリティ修正は提供されませんので、現在MySQL 5.0を利用している方はバージョンアップを計画されることをおすすめいたします。 オラクル社による買収以降、ソフトウェア製品のサポートポリシーは以下のウェブサイトで確認できるようになっています。 Oracle Lifetime Support Policy for Oracle Software MySQL 5.0：2011年12月まで MySQL 5.1：2013年12月まで MySQL 5.5：2015年12月まで (Extended Supportは2018年12月まで) MySQL 5.0のプロダクトライフサイクルが終了したということで、一年ぶりにバグ曲線を作成してみました。 MySQL 5.0や5.1と比較すると、MySQL 5.5のバグ曲線は早くも収束し始めているようです。しかしmysqldumpで--single-transactionと--flush-logsを組み合わせると一貫性バックアップにならない、sjis環境で意図したインデックスが使われない、レプリケーション環境でメモリの二重解放が発生するなど昨年見つかったいくつかの不具合についてその後の進展が見られず、MySQL 5.5が十分に枯れたと判断するにはまだ早いと考えています。 MySQL 5.0のプロダクトライフサイクルが終了しました。今後MySQL 5.0に対して新たなバグ修正やセキュリティ修正は提供されませんので、現在MySQL 5.0を利用している方はバージョンアップを計画されることをおすすめいたします。 オラクル社による買収以降、ソフトウェア製品のサポートポリシーは以下のウェブサイトで確認できるようになっています。 Oracle Lifetime Support Policy for Oracle Software MySQL 5.0：2011年12月まで MySQL 5.1：2013年12月まで MySQL 5.5：2015年12月まで (Extended Supportは2018年12月まで) MySQL 5.0のプロダクトライフサイクルが終了したということで、一年ぶりにバグ曲線を作成してみました。 MySQL 5.0や5.1と比較すると、MySQL 5.5のバグ曲線は早くも収束し始めているようです。しかしmysqldumpで--single-transactionと--flush-logsを組み合わせると一貫性バックアップにならない、sjis環境で意図したインデックスが使われない、レプリケーション環境でメモリの二重解放が発生するなど昨年見つかったいくつかの不具合についてその後の進展が見られず、MySQL 5.5が十分に枯れたと判断するにはまだ早いと考えています。
PlanetMySQL Voting: Vote UP / Vote DOWN]]> Sun, 01 Jan 2012 00:00:00 +0000 Sadao Hiratsuka