私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part14
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ☆
レスフィルター : (試験中)
2つのテーブルからマッチする値をとる際、1テーブル(one)のidの値とマッチしないid番号のみ2テーブル(two)からマッチするかチェックさせたいのですがどのようにできるでしょうか?
select * from one where id like '%hoge%'
これでマッチしない値
select * from one_option sub_id like '%hoge%'
できれば1文で結合したいです。
お願いいたします。
select * from one where id like '%hoge%'
これでマッチしない値
select * from one_option sub_id like '%hoge%'
できれば1文で結合したいです。
お願いいたします。
なぜかrootの権限消失してしまって、何度インスコしなおしても戻らん。
OSから入れなおしか?
OSから入れなおしか?
何言っているの?定義ファイルが壊れているだけだろ。何回インストールしてもだめだろ。
>>118
すげー親切にありがとう。テーブルサイズの変更っていうか
テーブル自体削除したりしても、idbdata1のサイズが変わらん
から、???だった。
初心者でなんもわからんくてすまん。ドキュメント読んでくるわ
すげー親切にありがとう。テーブルサイズの変更っていうか
テーブル自体削除したりしても、idbdata1のサイズが変わらん
から、???だった。
初心者でなんもわからんくてすまん。ドキュメント読んでくるわ
>>120
すべてについて常識の範囲内で想定するとしてだ。
単純に、コスト(金と手間)とセキュリティリスクの見合いになると思うなぁ。
最大でも数万レコード程度にしかならず、
かつ何らかの操作ミス等で漏洩しても許容できるような内容なら
統合しといたほうがいいと思う。
このレベルを超えるなら、こんな所で聞いてないで信頼できるベンダーに外注しなさい。
すべてについて常識の範囲内で想定するとしてだ。
単純に、コスト(金と手間)とセキュリティリスクの見合いになると思うなぁ。
最大でも数万レコード程度にしかならず、
かつ何らかの操作ミス等で漏洩しても許容できるような内容なら
統合しといたほうがいいと思う。
このレベルを超えるなら、こんな所で聞いてないで信頼できるベンダーに外注しなさい。
>>120
顧客の個人情報が含むなら、万全の対策をすべきだな。
漏出すると会社が潰れかねない。
例えば、等身大ラブドール販売会社ドールスコートはwinnyで顧客情報を流出させた。
http://sakura02.bbspink.com/test/read.cgi/adultgoods/1142163387/26-125
それが致命傷になり現在ではこんなことになっている。
http://doll.surpara.com/
顧客の個人情報が含むなら、万全の対策をすべきだな。
漏出すると会社が潰れかねない。
例えば、等身大ラブドール販売会社ドールスコートはwinnyで顧客情報を流出させた。
http://sakura02.bbspink.com/test/read.cgi/adultgoods/1142163387/26-125
それが致命傷になり現在ではこんなことになっている。
http://doll.surpara.com/
5.1.26出たけどまだRCなのか
最初に出すって言ってからもうすぐ1年だよ
いつGAになるんだ
最初に出すって言ってからもうすぐ1年だよ
いつGAになるんだ
URLをストアドファンクションでインサートしているんですが問題が発生しています。
以下のストアドなんですが、
http://example.com/hogehogeからアクセスがあった場合、
http://example.com/
http://example.com/hogehoge
の二つをカウントアップしているようです。
http://example.com/hogehogeのみカウントアップさせたいのですがなにが間違っているのでしょうか?
CREATE FUNCTION f_logging_referer(
f_page_id INT,
f_url TEXT,
f_device VARCHAR(100)
) RETURNS INT
BEGIN
declare _uid INT DEFAULT 0;
select url_id into _uid from t_url where str_url = f_url;
if _uid < 1 then
return 0;
end if;
-- 最後のアクセス更新 (同じページIDが存在したらUPDATE)
insert into t_url_lastlog(`page_id`,`str_url`,`str_device`) values (`f_page_id`,`f_url`,`f_device`)
on duplicate key update `str_url` = `f_url`,`str_device` = `f_device`;
// URLをカウントアップ
select 1 into cnt from t_url_count where str_url = f_url and page_id = f_page_id;
if cnt = 1 then
update t_url_count set `num_count` = num_count+1 where `num_refmonth_id` = `s_rnid`;
else
insert into t_url_count(page_id,str_url,num_count) values(f_page_id,f_url,1);
END iF;
return 1;
END;
以下のストアドなんですが、
http://example.com/hogehogeからアクセスがあった場合、
http://example.com/
http://example.com/hogehoge
の二つをカウントアップしているようです。
http://example.com/hogehogeのみカウントアップさせたいのですがなにが間違っているのでしょうか?
CREATE FUNCTION f_logging_referer(
f_page_id INT,
f_url TEXT,
f_device VARCHAR(100)
) RETURNS INT
BEGIN
declare _uid INT DEFAULT 0;
select url_id into _uid from t_url where str_url = f_url;
if _uid < 1 then
return 0;
end if;
-- 最後のアクセス更新 (同じページIDが存在したらUPDATE)
insert into t_url_lastlog(`page_id`,`str_url`,`str_device`) values (`f_page_id`,`f_url`,`f_device`)
on duplicate key update `str_url` = `f_url`,`str_device` = `f_device`;
// URLをカウントアップ
select 1 into cnt from t_url_count where str_url = f_url and page_id = f_page_id;
if cnt = 1 then
update t_url_count set `num_count` = num_count+1 where `num_refmonth_id` = `s_rnid`;
else
insert into t_url_count(page_id,str_url,num_count) values(f_page_id,f_url,1);
END iF;
return 1;
END;
ごくごく単純に言って、
マスタには書き込んだ分の読み取りが発生するので、読み取り量が1.5倍になる。読み取りを均等に分散させるとして、1:2のまま。
スレーブには書き込んだ分の書き込みが発生するので、読み取りを均等に分散させるとして、1:1になる。
ところで、そもそも君は何故レプリケーションする必要に迫られているか?
パフォーマンスの問題を解決したいなら、オーバーヘッド分を犠牲にしてでもレプリケーションするべきだろう。
フェイルオーバーしたいなら、オーバーヘッド分を犠牲にしてでもレプリケーションするべきだろう。
つまり君には、レプリケーションのオーバーヘッドに関わらず、
もはやレプリケーションする道しか残されていないのです。
ただ、単純なレプリケーションでは更新の分散はできないので、1:2なんつー状況で打てる手は少ないと思う。
マスタの分割をセットで考えたほうがいいだろう。
マスタには書き込んだ分の読み取りが発生するので、読み取り量が1.5倍になる。読み取りを均等に分散させるとして、1:2のまま。
スレーブには書き込んだ分の書き込みが発生するので、読み取りを均等に分散させるとして、1:1になる。
ところで、そもそも君は何故レプリケーションする必要に迫られているか?
パフォーマンスの問題を解決したいなら、オーバーヘッド分を犠牲にしてでもレプリケーションするべきだろう。
フェイルオーバーしたいなら、オーバーヘッド分を犠牲にしてでもレプリケーションするべきだろう。
つまり君には、レプリケーションのオーバーヘッドに関わらず、
もはやレプリケーションする道しか残されていないのです。
ただ、単純なレプリケーションでは更新の分散はできないので、1:2なんつー状況で打てる手は少ないと思う。
マスタの分割をセットで考えたほうがいいだろう。
5.1はいつGAになるんですか?
Sunに買収されたんだしロードマップくらい用意して欲しいです。
そろそろ出るって言われ続けて相当引っ張ったWindows NT 5.0
(Windows 2000)を思い出します。10年位前の話。
Sunに買収されたんだしロードマップくらい用意して欲しいです。
そろそろ出るって言われ続けて相当引っ張ったWindows NT 5.0
(Windows 2000)を思い出します。10年位前の話。
春のカンファレンスで2008Q1って言ってたんだよね
出ませんでしたが。
仕事に影響あるので困る。
出ませんでしたが。
仕事に影響あるので困る。
データ抽出の開始行の40000番目のレコードを見つけるのに時間がかかってるんじゃない?
開始行の番号が小さいうちは気にならないけど、番号が大きくなるとそれだけHDDの走査対象が増えるからだと思います。
開始行の番号が小さいうちは気にならないけど、番号が大きくなるとそれだけHDDの走査対象が増えるからだと思います。
>>131
http://lists.mysql.com/announce/537
MySQL 5.1.26-rc is slated to be the last release candidate before we
declare MySQL 5.1 as "production ready" (GA).
…だそうです。
その後のお願いメール。
http://lists.mysql.com/announce/539
http://lists.mysql.com/announce/537
MySQL 5.1.26-rc is slated to be the last release candidate before we
declare MySQL 5.1 as "production ready" (GA).
…だそうです。
その後のお願いメール。
http://lists.mysql.com/announce/539
>>133
ORDER BYを指定しないと戻り値のソート順は不定じゃないの?
フルスキャンするのにテンポラリが作られてたりして。
インデックス付きのカラムを指定してみてはいかがだろうか。
インデックススキャンで済めば、そんなにかからないだろ。
ORDER BYを指定しないと戻り値のソート順は不定じゃないの?
フルスキャンするのにテンポラリが作られてたりして。
インデックス付きのカラムを指定してみてはいかがだろうか。
インデックススキャンで済めば、そんなにかからないだろ。
133です。
>>134
言われる通りっぽいです。
根拠はありませんが、何も指定しない状態でレコードを抽出すると
その行までのデータをシークしていく様子ですね。
>>136
LIMITで指定せずにORDER BYでインデックス付きのカラムから指定したら
正常に取り出せました。
ありがとうございます!
ソートしていたら、基地外なほど応答がなかったのでソート外したんです。
すると、やや速度は上がったのですが今回のようになりました。
取り出される結果自体は、多分データベースに追加した順番でしたので
全部を参照するだけであれば問題ないはずだったのですが
やはりインデックス付きのid用カラムを使用するべきですよね。
はじめからidを振っていなかったので400,000件のデータに追加できずに
データ初期化する事になりましたが、解決できました。
ありがとうございました。
>>134
言われる通りっぽいです。
根拠はありませんが、何も指定しない状態でレコードを抽出すると
その行までのデータをシークしていく様子ですね。
>>136
LIMITで指定せずにORDER BYでインデックス付きのカラムから指定したら
正常に取り出せました。
ありがとうございます!
ソートしていたら、基地外なほど応答がなかったのでソート外したんです。
すると、やや速度は上がったのですが今回のようになりました。
取り出される結果自体は、多分データベースに追加した順番でしたので
全部を参照するだけであれば問題ないはずだったのですが
やはりインデックス付きのid用カラムを使用するべきですよね。
はじめからidを振っていなかったので400,000件のデータに追加できずに
データ初期化する事になりましたが、解決できました。
ありがとうございました。
質問させて下さい。
MySQL5.0.51a、Linuxを使用しています。
以下のような場合に
`i_img_no` `i_img_disp`
を取得したいと思っています。
取得条件は各`i_img_cat_no`の中から一番、数値の低いi_img_dispを持つ`i_img_no`と`i_img_disp`を取得と言った具合です。
CREATE TABLE `i_img` (
`i_img_no` int(10) unsigned NOT NULL PRIMARY KEY AUTO_INCREMENT COMMENT 'No',
`i_img_cat_no` int(4) unsigned NOT NULL default '0' COMMENT '画像カテゴリNO',
`i_img_name` varchar(32) NOT NULL default '' COMMENT '画像名',
`i_img_url` varchar(255) UNIQUE NOT NULL default '' COMMENT '画像URL',
`i_img_disp` int(10) unsigned NOT NULL default '0' COMMENT '表示回数',
`i_img_up_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新日時',
`i_img_reg_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '登録日時',
`i_img_del_flg` TINYINT NOT NULL DEFAULT '0' COMMENT '削除フラグ 0=未削除 1=論理削除 2=一時削除'
) ENGINE = innodb CHARACTER SET ujis COLLATE ujis_japanese_ci COMMENT '画像表示情報';
i_img ( 他のカラムは長いので省略 )
---------------------------
i_img_no i_img_cat_no i_img_disp
1 1 3
2 1 10
3 1 20
4 2 10
5 2 30
....
x 2 5
---------------------------
上記であれば、以下の結果を取得したいのです。
---------------------------
i_img_no i_img_cat_no i_img_disp
3 1 20
5 2 30
---------------------------
ドキュメント等を見て
SELECT
MAX(`i_img_disp`),
`i_img_no`
FROM
`i_img`
WHERE
`i_img_del_flg` = 0
GROUP BY `i_img_cat_no`
としてみたのですが、これではMAX(`i_img_disp`)時の`i_img_no`を取得してくれず
二つのカラムの関係が非同期になってしまいます。
何か上手くいく方法はないものかと、
GROUP BY `i_img_cat_no`
ORDER BY MAX(`i_img_disp`) ASC
や
GROUP BY `i_img_cat_no`
ORDER BY MAX(COUNT(`i_img_disp`)) ASC
や
SELECT MAX(`i_img_disp`, `i_img_no`)
等も試してみたのですが、構文エラーや思った結果が得られず行き詰まっております。
どうかお力添え頂けないでしょうか。
宜しくお願い致します。
MySQL5.0.51a、Linuxを使用しています。
以下のような場合に
`i_img_no` `i_img_disp`
を取得したいと思っています。
取得条件は各`i_img_cat_no`の中から一番、数値の低いi_img_dispを持つ`i_img_no`と`i_img_disp`を取得と言った具合です。
CREATE TABLE `i_img` (
`i_img_no` int(10) unsigned NOT NULL PRIMARY KEY AUTO_INCREMENT COMMENT 'No',
`i_img_cat_no` int(4) unsigned NOT NULL default '0' COMMENT '画像カテゴリNO',
`i_img_name` varchar(32) NOT NULL default '' COMMENT '画像名',
`i_img_url` varchar(255) UNIQUE NOT NULL default '' COMMENT '画像URL',
`i_img_disp` int(10) unsigned NOT NULL default '0' COMMENT '表示回数',
`i_img_up_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '更新日時',
`i_img_reg_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '登録日時',
`i_img_del_flg` TINYINT NOT NULL DEFAULT '0' COMMENT '削除フラグ 0=未削除 1=論理削除 2=一時削除'
) ENGINE = innodb CHARACTER SET ujis COLLATE ujis_japanese_ci COMMENT '画像表示情報';
i_img ( 他のカラムは長いので省略 )
---------------------------
i_img_no i_img_cat_no i_img_disp
1 1 3
2 1 10
3 1 20
4 2 10
5 2 30
....
x 2 5
---------------------------
上記であれば、以下の結果を取得したいのです。
---------------------------
i_img_no i_img_cat_no i_img_disp
3 1 20
5 2 30
---------------------------
ドキュメント等を見て
SELECT
MAX(`i_img_disp`),
`i_img_no`
FROM
`i_img`
WHERE
`i_img_del_flg` = 0
GROUP BY `i_img_cat_no`
としてみたのですが、これではMAX(`i_img_disp`)時の`i_img_no`を取得してくれず
二つのカラムの関係が非同期になってしまいます。
何か上手くいく方法はないものかと、
GROUP BY `i_img_cat_no`
ORDER BY MAX(`i_img_disp`) ASC
や
GROUP BY `i_img_cat_no`
ORDER BY MAX(COUNT(`i_img_disp`)) ASC
や
SELECT MAX(`i_img_disp`, `i_img_no`)
等も試してみたのですが、構文エラーや思った結果が得られず行き詰まっております。
どうかお力添え頂けないでしょうか。
宜しくお願い致します。
副問い合わせの基本パターンだ。
select i_img_no, i_img_cat_no, i_img_disp
from i_img img1
where i_img_disp =
(
select max(i_img_disp)
from i_img img2
where img1.i_img_cat_no = img2.i_img_cat_no
);
がんばって覚えてね
select i_img_no, i_img_cat_no, i_img_disp
from i_img img1
where i_img_disp =
(
select max(i_img_disp)
from i_img img2
where img1.i_img_cat_no = img2.i_img_cat_no
);
がんばって覚えてね
>>141
>としてみたのですが、これではMAX(`i_img_disp`)時の`i_img_no`を取得してくれず
それより、その select は普通のSQLではエラーになるので、御注意。
普通の SQL では、group by があるときは、group by の対象フィールドか、集計関数の結果しか select できないので。
>としてみたのですが、これではMAX(`i_img_disp`)時の`i_img_no`を取得してくれず
それより、その select は普通のSQLではエラーになるので、御注意。
普通の SQL では、group by があるときは、group by の対象フィールドか、集計関数の結果しか select できないので。
23k程度のファイルの内容(文字列)をTEXT型のカラムに保存しようとしています。(UTF-8)
ですが、INSERTすると途中までしか入りません。
UTF-8なので3byteになる文字があるとはいえ、
TEXTの上限である約65kに収まらない理由がピンと来ません。
厳密には内容によって変わると思いますが
23kのファイルがTEXT型には収まらない可能性はある、といった経験則のある方いらっしゃいますか?
また、収まらないのであればmediumtextかと思ってるのですが、上限がかなり大きいです。
MySQLでデータ型を決めるとき、大容量のデータ型のカラムを確保しておくだけでロスが生じる、
ということはないと考えて大丈夫でしょうか?
プログラムでINTかLONGかで確保するメモリが違うというような意味合いなんですが・・・
ですが、INSERTすると途中までしか入りません。
UTF-8なので3byteになる文字があるとはいえ、
TEXTの上限である約65kに収まらない理由がピンと来ません。
厳密には内容によって変わると思いますが
23kのファイルがTEXT型には収まらない可能性はある、といった経験則のある方いらっしゃいますか?
また、収まらないのであればmediumtextかと思ってるのですが、上限がかなり大きいです。
MySQLでデータ型を決めるとき、大容量のデータ型のカラムを確保しておくだけでロスが生じる、
ということはないと考えて大丈夫でしょうか?
プログラムでINTかLONGかで確保するメモリが違うというような意味合いなんですが・・・
んとね、MySQLでは照合順序がUTF8のときは、全ての文字が3byteになるの。
よって、入らないというのが正解で、正常す。
大容量のデータ型だと、確かInnoDBでは超無駄になったと思う。
フルテキストインデックス使わないならTEXT型のメリットって知れてるし、
バイナリとして格納しちゃえば?
よって、入らないというのが正解で、正常す。
大容量のデータ型だと、確かInnoDBでは超無駄になったと思う。
フルテキストインデックス使わないならTEXT型のメリットって知れてるし、
バイナリとして格納しちゃえば?
>>135
おー、やっとか!
せめていつGAになるかがもっと早く分かってれば来年春に稼動予定のシステムで
5.1を採用したんだけどなぁ。結局5.0で進めることに先月決定した。
お願いメールも見たよ。鶏か卵かみたいな話になるけど、GAって名前にならないと
ユーザーは増えないと思う。
おー、やっとか!
せめていつGAになるかがもっと早く分かってれば来年春に稼動予定のシステムで
5.1を採用したんだけどなぁ。結局5.0で進めることに先月決定した。
お願いメールも見たよ。鶏か卵かみたいな話になるけど、GAって名前にならないと
ユーザーは増えないと思う。
質問させていただきます
SQLで既存のテーブルに新しくフィールドを追加しました。
最初はnullなのでそこにデータを入れたいのですが、ファイルから一度に出力させることは出来ないでしょうか?
わかりにくくてすいませんが
他のフィールドにはすでにデータが入っていて、新しいフィールドにはなにもない状況。
新しいフィールドに入れるデータはテキスト形式であるので、
load data infile,,,,としたいのですが、特定のフィールドのみにテキストからデータを挿入するやり方がわからずに質問させていただきました
SQLで既存のテーブルに新しくフィールドを追加しました。
最初はnullなのでそこにデータを入れたいのですが、ファイルから一度に出力させることは出来ないでしょうか?
わかりにくくてすいませんが
他のフィールドにはすでにデータが入っていて、新しいフィールドにはなにもない状況。
新しいフィールドに入れるデータはテキスト形式であるので、
load data infile,,,,としたいのですが、特定のフィールドのみにテキストからデータを挿入するやり方がわからずに質問させていただきました
?
テキストを整形して
新しいフィールドだけをUPDATEするSQLの塊を作って流し込めばいいじゃない。
もしくは、運用中でなければ
別テーブルに全部流し込んでおいて、
現行テーブルを削除→別テーブルをリネームで、そっくり入れ換えるとか。
テキストを整形して
新しいフィールドだけをUPDATEするSQLの塊を作って流し込めばいいじゃない。
もしくは、運用中でなければ
別テーブルに全部流し込んでおいて、
現行テーブルを削除→別テーブルをリネームで、そっくり入れ換えるとか。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql スレッド一覧へ
みんなの評価 : ☆類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について