>>800
いや、あろうがなかろうがUPDATEする　って感じのイメージなんだけど
そのときに、触ってないカラムはそのままにしたいんだよね

いや、違う！勘違いしてた！
>>800の方法で解決だ！うっかりしてた！この手があったか！

あ、ダメかも。ちょっと実験してみる。

>>804

試してみてくらはい。
ちなみに自分のコードは↓こんな感じ。

INSERT INTO テーブル (`user_id`, `col1`, `col2`)
VALUES ("user001","$val1","$val2")
ON DUPLICATE KEY UPDATE `col1` = "$val1", `col2` = "$val1"

テーブルは
CREATE TABLE `テーブル` (
`id` int(11) NOT NULL auto_increment,
`user_id` varchar(32) NOT NULL,
`col1` varchar(64) NOT NULL,
`col2` varchar(64) NOT NULL,
UNIQUE KEY `unique_key` (`user_id`,`col1`)
) ENGINE=InnoDB DEFAULT CHARSET=sjis;

これだと、`user_id`,`col1`のユニーク制約に引っかからない場合はINSERT、制約に引っかかる場合はUPDATEが走ります。

http://dev.mysql.com/doc/refman/5.1/ja/insert-on-duplicate.html

DBサーバを冗長化する方法を調べています。
・トランザクションの開始と終了を同期させる。
・１つのDBに対して複数のトランザクションを同時に
実行しない （そもそもできるのかよく分かってないのですが…）
これで２つのDBの内容を同期できると考えているのですが
そういうわけでもないのでしょうか？
よろしくお願いします。

質問よろしいでしょうか。
MySQLのバージョンは5.1系を想定しています。

「複数のテーブル全てにおいてユニークなID」を発行したいのですが、良い方法をアドバイスお願いします。
現在は
「ユニークIDカウントテーブル」を作り、
UPDATE tbl_id_counter SET id = id + 1;
SELECT id FROM tbl_id_counter WHERE 1;

こんな感じでIDを発行しようとしています。
tbl_id_counterテーブルにはレコードは1つしかありません。

この方法ですと、UPDATEとSELECTの間に他のユーザーのUPDATEが入ると、取得するIDが重なってしまう危険性があります。
LOCKすれば良さそうなのですが、他に何かより良い方法はありますでしょうか？

「UPDATEするとともに結果を取得する方法は無いものだろうか？」
というのが、現在自分が思いつくアイデアです。

サーバのメモリ周りに関する質問です。
メモリの確保が思った以上におおくて、スワップアウトが発生してしまいます。
メモリの計算を何か間違えているでしょうか？
実メモリは8GB、mysql単で動いているサーバです。
下記はmymemcheckの結果を抜粋したものです。
OSはFreeBSD7.2-R amd64、mysqlは5.1.45を使用しています。
--- topの結果の一部 --- (mysqldの再起動直後で、時間がたつとswap使用率が98%とかになります)
Mem: 5856M Active, 863M Inact, 629M Wired, 406M Cache, 399M Buf, 40M Free
Swap: 2048M Total, 61M Used, 1987M Free, 2% Inuse

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
83172 mysql 2713 44 0 16302M 5902M ucond 1 0:04 4.05% mysqld

--- mymemcheckの結果の一部 ---
min_memory_needed = global_buffers + (thread_buffers * max_connections)
= 7240417280 + 65536 * 3000
= 7437025280 (6.926 [G])

[ 32bit Linux x86 limitation ]
ref
*http://dev.mysql.com/doc/mysql/en/innodb-configuration.html

* need to include read_rnd_buffer.
* no need myisam_sort_buffer because allocate when repair, check alter.

2G > process heap
process heap = innodb_buffer_pool + key_buffer
+ max_connections * (sort_buffer + read_buffer + read_rnd_buffer)
+ max_connections * stack_size
= 6291456000 + 402653184
+ 3000 * (8192 + 8192 + 8192)
+ 3000 * 262144
= 7554269184 (7.035 [G])

2G > 7.035 [G] ... LIMIT OVER!!

質問させて下さい。

テーブルAは連番IDでログのように記録しています。
重複するデータがたくさんあります。

テーブルBは、テーブルAの要素の補完のようなもので、タグ付けを行っています。

テーブルBから、指定したタグ「small」と一致するレコードを検索するSQL文を作りました。
（重複する animal は省きたいので DISTINCT を入れました）

SELECT DISTINCT animal FROM table_B WHERE tag = 'small'

以上で希望する結果になったのですが、
この結果を、table_A で、最も新しく出現する順番に（id降順）ソートさせたい場合 SQL文はどのように書けばよいのでしょうか？
サブクエリ等調べてはいるのですが、手持ちの資料が少なく困っています。
MySQL 5.1です。

table_A
-----------
id animal
-----------
1010 cat
1009 dog
1008 dog
1007 cat
1006 bird

table_B
-----------
animal tag
-----------
cat small
cat big
dog small
dog big

SELECT DISTINCT tb.animal
FROM
　table_A ta,
　table_B tb
WHERE
　　　　tb.tag = 'small'
　AND tb.animal = ta.animal
ORDER BY ta.id

pdo を使用してデータを登録すると
どうしても文字化けが発生してしまいます。

テーブルはsjisなのですがPDOではsjisは使えないのでしょうか？

分からないんで質問します。

例えば、地元近辺の駐車場の空き状況をデータベースにして
駐車場管理者／利用者からお金を取るシステムを作ったとします。
MySQL自体は自分のサーバーに入れて誰にもいじらすことがない場合、
商用ライセンスが適用されますか？

この場合だとソフト自体は売ってないですよね？
金が発生するなら即商用ライセンスですか？
何度読んでも商用ライセンスの意味が把握できません・・・

システムが自分の資産で
地主さんにサービスを提供する形態なら商用ライセンスは不要。

それでお金とられたら
mixiとかGREEとかモバゲーがえらいことになる。

システム自体を1セット20万円とかで地主さんに売る場合は別。
商用ライセンス買わない場合はシステム全体がGPLになる。

>>818
システム自体は自分の資産ですから、
自分の場合、商用ライセンスは不要っぽいですね＼(^o^)／
ありがとうございました！

無くてもいいけど別に買ってもいいんだよ
MySQLの商用サポートはかなり優秀

じゃー1でいいんでないかい。
聞きに行くサーバが複数台あれば2でもいいんじゃないかいー。

>>820
では商用サポートって具体的に何をやってくれるんですか、と検索したところ：

http://openstandia.jp/services/mysql/mysql_license_support.html

…バグFixとか生涯調査とか別に要らないですわ。
ただ、将来的には個人情報を扱うことになって情報漏洩とかあったら困るんで
採算取れるなら考えますけどね。

>>818
逆に、GPLのまま売ってもいいなら商用ライセンスも要らないな。
売価の20万円で元がとれて、他に明かしたくない独自コードが含まれて
いるわけでもない場合はそれもありだろう。

バグFixってもサポートがパッチを当ててくれるわけでもない。バグ情報送ってくるだけ。
バグが原因で情報漏れおきてもMySQLが損害賠償してくれるわけでもない。自己責任。
障害調査は自前で運用できないとこなら必要だろうが、DBAいるなら不要。
サポートいるようなところがオープンソース使うはずないじゃんって話。
オープンソースで喰えると思ってMySQLに入社した人は頭おかしい。
世の中わかってないにも程がある。

>>825
情報、どうもサンクスコです
それなら尚更サポートなんて要らないですね
DBA居なくて運用しているところなんてあるんですかねｗ
因みにSQL自体はMySQLで勉強して、安定したらそのうちPostgreSQLに移ることにします

>>815
遅くなったけど有難う。動いたけれど凄く重かった。
試行錯誤して単一テーブルで済ますようにしたら改善しました。

駆け出しものです。
MySQL Migration Toolkitを使って会社で使っているmssql serverをマイグレーションしようと考えています。
ネットや書籍,セミナーなどあっちこっち出向くんですがあまり情報がありません。
一読しておけばよいような書籍・サイトさらにはセミナーなどご指南いただければ幸いです。

質問させてください。

回線断時にEndTransactionしようとするとアプリごと終了するのですが
これはどうにもならない問題なのでしょうか？

このへんかなあ？

Bug #31145 ALTER TABLE DROP COLUMN, ADD COLUMN crashes (linux) or freezes (win) the server
http://bugs.mysql.com/bug.php?id=31145

>>835
それですね！
バグが報告されているヴァージョンが5.1.43以前で
自分のヴァージョンが5.1.37ですから間違いなさそうです
症状もまったくもって同じです

最新ヴァージョンにはもうパッチが当ててあるようですね
治っているならいいです、次回、折を見て最新ヴァージョンに切り替えます

それにしても2007年9月に報告されたバグが
去年の暮れまで放置されてたなんて
MySQLの開発って意外と杜撰なんですね…

ありがとうございました！

普通そういう使い方しないからなｗ

ここまでバージョンあがってるのにいまだにこんなバグ出るほうがおかしくね？
開発管理は最初から今まで進歩しないてアマチュアレベルだとおもうけどな

不具合修正にも優先順位がある。
メリットが少ない変更は後回しなだけ。

といいつつ正直、将来は心配。

動かないならまだしも、クラッシュするってサービス止まっちゃうじゃないか。
最優先で修正されるべきなんじゃないの？

今回の問題は
あろうことか、「開発者側の当事者」が
「いや、俺も5.0.52で試したけど再現性なかったよ」
って書いたもんで、約二年間も放置されていた、ってことでしょう

実際には、バグ報告者は5.1.20でバグを発見しているんで
5.0.52で再現性を試みる自体が開発者としておかしいんですが

ALTER TABLE程度でいちいちフリーズされるのはどうかと思います
（「さいさい変更を加えるのは最初の設計が悪い」とかは言いっこなしですよ）
まぁ、優先順位が高かったからこそ、二度目のバグ報告で
一ヶ月も経たないうちに対策されたんだと思います

とにかく、自分は今回の件でMySQLに対する信用は落ちました

MySQLを擁護するつもりはまったくないけど
バグの10個や20個で騒いでたらシステム開発はできんよ

MySQL 5.1でこれまでに修正されたバグは3,500個以上
Oracleだって9.2.0.1～9.2.0.8で修正されたバグは6,000個以上
Windows2000には出荷当時63,000個のバグがあると言われていた

ちょっとスパゲッティな気はするけどね＞MySQL

>>842
>MySQL 5.1でこれまでに修正されたバグは3,500個以上

あらららら、MySQL 5.1ってもう十分に枯れたシステムだと思ってたんですけど違ったんですね…
こうなるとPostgreSQLの修正されたバグの数が知りたくなりますね…

でも、今回の件は許せない
トヨタのリコール隠しくらい許せない

思う存分数えてください
http://www.postgresql.org/docs/8.4/interactive/release.html

MySQL 5.1が確か2008年11月リリースだと思ったから
PostgreSQL 8.3.5あたりから数えるといいよ

MySQLとポスグレはリリースタイミングが違うから期間ごとのバグ数比較してもしかたがないような気もする。
ポスグレは毎年新バージョンリリースしてるんで比較するなら8.4.1、8.4.2、8.4.3、8.4.4のバグ数と5.1.27以降のバグ数じゃね？
ちなみにポスグレの8.4.0はリリースバージョンだから基本バグなしってスタンス。

今ざっくり数えてみたらポスグレの8.4は841から844で修正170くらいだな。

>>844
そんな殺生な…

と思ったら

>>845
誠に乙です

このスレでこう呟くのもアレですが
やっぱりPostgreSQL、いいなぁ…

>>846
だったらPostgreにすりゃあいいでしょーが w

客先とかの都合で変えられないんだったら諦めなしゃーないし w

>>847
元々最初に触ったデータベースはPostgreSQLでしたし、そのうち移ります…
世間様はまだMySQLを崇拝していらっしゃるんで、MySQLは完全に捨て切れないですが…

>>816
どなたかヒントをお願いします。

>>848
> 世間様はまだMySQLを
日本はPostgreが先行だったと思ったが。