[前][次][番号順一覧][スレッド一覧]

mysql:9697

From: "HIROSE, Masaaki" <"HIROSE, Masaaki" <hirose31@xxxxxxxxxx>>
Date: Tue, 22 Jun 2004 12:16:36 +0900
Subject: [mysql 09697] Re: db.optについて

ひろせです

# 引用前後します。

on "[mysql 09696] Re: db.optについて"
   <871xk81ipa.wl@xxxxxxxxxx>
at Tue, 22 Jun 2004 10:32:01 +0900
   takeshi@xxxxxxxxxx wrote:

> > 結局、
> > db.opt がある/ないに関わらず、database の文字コードには依存しないよう
> > に、CREATE TABLE には DEFAULT CHARSET をつけるようにする、というのが安
> > 全ということでしょうかね。
> 
> 3.X, 4.0 と同様に、
> サーバー、クライアントは同じ character set を使うようにして
> 運用するのがトラブルが少ないかと。扱う文字コードも固定。
> 色々なcharacter setを使ったり、文字コードの変換を使うのは
> 特別な場合に限るような運用の方が、トラブルや現アプリの移行の
> 手間は少ないでしょうねぇ。
> 
> これに加えて client が binary で接続すれば、さらにトラブルは
> 減るでしょう。

ですね。無用に database/table/column で文字コードを混ぜなければ、
my.cnf の [mysqld] と [mysql] に default-character-set を指定しておけ
ばそんなにハマることはないんじゃないかと思います。

> それと
> "character_set_* 変数をいじらないといけないの?面倒だね"
> というように思ってしまう人が もし出てきてしまったら嫌なので
> 言いますが、
> character_set_* 変数は --default-character-set や
> SET [CHARACTER|NAMES]文によりセットされるので、
> character_set_* 変数は、通常は忘れます。私は忘れています。それで良し.
> トラブルの時にだけ、character_set* 変数を見るだけです。
> サーバー、クライアントの --default-character-set だけを
> 使う運用(SET文も使わない)が単純。

これも同意です。わたしがあれこれやっているのは、ハマったときのために挙
動 (4.1はalphaなのでそのうち変わるかもしれませんが) を調べたいのが目的
なので、通常は set character_set_* はしないと思いますし、混乱するのが
おちなのですべきではないと思います。


> > B database mysql と test には db.opt がないので、これらの database で
> >   DEFAULT CHARSET なしで CREATE TABLE した場合の table の文字コードは
> >   変数 character_set_database の値によって恣意的に決定されてしまう。
> >   [6,9]
> >   → character_set_database を変えたりしない、mysql の table に入れるデー
> >      タは専ら us-ascii だけ、test はあくまでテスト用の database である、
> >      という理由で、実際に問題になる局面は少ないかも?
> 
> > C db.opt がない database で DEFAULT CHARSET を省略した CREATE TABLE で
> >   作った table の文字コードは、SHOW CREATE DATABASE で表示される
> >   database の文字コードと異なる場合がある。[5,9]
> >   → 無用なトラブルを回避するために、4.1 での CREATE TABLE には
> >      DEFAULT CHARSET をつけるようにした方がいい?
> 
> 想像ができなかったので、現象が起きる例をみせていただくと
> ありがたいです

いずれも character_set_{database,server} を直接弄っているので、こんな
ヘンタイ的なことはしない=こじつけ的な例=実際にはあまり発生しない例で
すが…

● B の例

cat <<EOF | mysql test
show variables like 'character\_%';
drop table if exists foo;
create table foo (n int);
show create table foo\G

select '';

set character_set_database = gb2312;
set character_set_server = koi8u;
show variables like 'character\_%';
drop table if exists foo;
create table foo (n int);
show create table foo\G
EOF

後者の table の文字コードは gb2312 になる。

db.opt が存在せず、かつ、DEFAULT CHARSET なしの CREATE TABLE を実行した
場合に限り、何らかの作用で character_set_database が不安定だと table の
文字コードも不安定になる。

● C の例

cat <<EOF | mysql test
set character_set_database = gb2312;
set character_set_server = koi8u;
show variables like 'character\_%';
show create database test\G

drop table if exists foo;
create table foo (n int);

show create table foo\G
EOF

結果は

 *************************** 1. row ***************************
        Database: test
 Create Database: CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET koi8u */
 *************************** 1. row ***************************
        Table: foo
 Create Table: CREATE TABLE `foo` (
   `n` int(11) default NULL
 ) ENGINE=InnoDB DEFAULT CHARSET=gb2312

となる。

SHOW CREATE DATABASE の結果を見ると、database の文字コードは koi8u な
ので、DEFAULT CHARSET なしの CREATE TABLE を実行すると koi8u の table
が作られそうだが、実際は character_set_database が影響して gb2312 にな
る。


ではでは

-- 
ひろせ
http://www.irori.org/

[前][次][番号順一覧][スレッド一覧]

      9694 2004-06-22 00:36 ["HIROSE, Masaaki" <h] db.optについて                          
      9696 2004-06-22 10:32 ┗[<takeshi@xxxxxxxxxx>]                                       
->    9697 2004-06-22 12:16  ┣["HIROSE, Masaaki" <h]                                     
      9701 2004-06-23 10:17  ┃┗[<takeshi@xxxxxxxxxx>]                                   
      9698 2004-06-22 13:58  ┗[Hirofumi Fujiwara <f]