すんなりとはうまくいかないのでメモ。
データベースの「操作」メニューからデータベースをコピーすると、
恐らくテーブル名のアルファベット順にコピーを試みるため、
アルファベットの後ろにあるテーブルに依存したテーブルを作成しようとするとエラーになる。ださい。
ところが、エクスポートされたsqlを見ると、
最初にすべてのテーブルの構造を仮作成して、実際のテーブルの作成時にDROPして作り直している。
このやり方だと、依存の順番を解決する必要すら無くなるので合理的である。かしこい。
というわけで、データベースのコピーをとりたいと思った時は、
- まずエクスポートする。
- 新規データベースを作成する。
- そこにインポートする。
という手順をとればすんなりOK。かんたん。
関係無いが、phpMyAdminは便利機能としてhoge_ではじまるデータベースをhogeユーザにすべて見せようとする。
適切な認証管理が行われていれば当然みえなくなっていると思うが、
hogeユーザに見せたくないデータベースを持つときは、hoge_miruna ではなく miruna_hoge という名前にしといた方が無難かも知れない。
前提
- コンサバで64bitなLinuxを導入したいのでCentOS 5.4 x86_64版をインストールした。
- OSインストール時には古いphpとmysqlはインストールしなかった。
- 新しいphpとmysqlをインストールするためにremiリポジトリを使う覚悟を決めた。
- remiリポジトリではphp 5.3を入れると、mysqlを5.1に上げないといけないが、それも了承した。
- ただし、remiはyumの自動アップデートの対象には含めないことにする。
リポジトリの追加
yum -y install wget
wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm
wget http://rpms.famillecollet.com/el5.x86_64/remi-release-5-6.el5.remi.noarch.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm
vi /etc/yum.repos.d/remi.repo
[remi]
priority=1
vi /etc/yum.repos.d/epel.repo
[epel]
priority=1
enabled=0
phpとmysqlのインストール
yum remove php* mysql*
yum install --enablerepo=remi,epel mysql.x86_64 mysql-devel.x86_64 mysql-server mysql-test
yum install --enablerepo=remi,epel php php-mbstring php-mysql php-pdo
php -v
mysql -V
service mysqld start
service httpd start
mysqlのインストールに失敗する場合は
remiのmysqldは初期状態が微妙に変だ。
mysqlデータベースのuserテーブルにレコードが無いとか、色々おかしい。
killall mysqld
/usr/libexec/mysqld --skip-grant-tables &
mysql_update
mysql mysql
INSERT INTO user VALUES('localhost','root',PASSWORD('パスワード'), 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', '', '', '', '', 0, 0, 0, 0);
quit
killall mysqld
service mysqld start
うちの場合は、これでうまくいった。
GRANT命令が使えない環境下でuserテーブルをいじる方法を覚えてないと、メンテが出来なくなるね。
localhost以外からrootで接続できるようにするには、以下のクエリも実行すれば良いが、WebサーバとDBサーバを分ける等の運用をするわけではない限り必要ないと思う。セキュリティリスクを伴う。
INSERT INTO user VALUES('%','root',PASSWORD('パスワード'), 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y', '', '', '', '', 0, 0, 0, 0);
話題的には3年くらい遅れてるわけですが。
つい最近、mysql5には utf8_japanese_ci が無いことを知った。
phpmyadminは最近のバージョンまで utf8_japanese_ci がプルダウンにあったし、
設定も出来ていたように見えたので、ずっとあるもんだと錯覚していたが、そんな事はなかったぜ。
そもそも utf8_japanese_ci が utf8_general_ci とどう違うのかもよくわかっていない。
あらためて「日本語をソートする」という事を考えても、文字コード順にしか並べようが無い。
ふりがな用のフィールドを用意して、「全角で」入力し、文字コード順に並べると、
- utf8_bin を指定した場合は、「半角数字」「半角英語大文字」「半角英語小文字」「ひらがな」「全角カタカナ」「全角数字」「全角英語大文字」「全角英語小文字」「半角カタカナ」という順番になる。
- utf8_general_ci を指定した場合は、utf-8binの「半角英語大文字」と「半角英語小文字」が同一視される。
- utf8_unicode_ci を指定した場合は、「数字」「英語」「ひらがな」「カタカナ」という順番になる。
ということらしい。
utf8_unicode_ci は、パフォーマンスが低下するが、同一の文字が複数の文字コードを持つ場合に同一視するための処理が行われる。
データベースへの記録経路が単一のシステム上で完結しているなら、入力時に必要な変換処理を行った上で utf8_general_ci を使用したほうがよい。
複数のシステムがデータベースを共有していたり、直接中身を操作するような運用がある場合には、utf8_unicode_ciを使う事を検討すると良い。という感じか。
いずれにせよ「漢字を五十音順に並べることは出来ない」という事だけは押さえておこう。
utf8_japanese_ci が無いことを言及していた方はこちら。
http://lunatear.net/archives/000905.html
「utf8_general_ciでは日本語が変な順序でしか並ばない」という記述もあるが、
手元のmysql 5.1.36は、utf8_general_ciで、ひらがなとカタカナのソートはうまくいっている。
