私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part19
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
テーブル member
no 姓 名
1 田中 角栄
2 小泉 純一郎
3 阿部
4 福田
5 小泉 太郎
でselectで姓を検索するとき、レコードの「名」に値がある場合、
それを検索対象に入れての完全一致の結果を得たいのですが、
どう書けばいいんでしょうか？
「小泉」で検索、結果 0
「阿部」で検索、結果 1
「阿部」＋「晋三」で検索、結果 1
「小泉」＋「純一郎」で検索されたとき、結果 1
こんな感じで結果を得たいのです
わかりにくくてすみません…。
no 姓 名
1 田中 角栄
2 小泉 純一郎
3 阿部
4 福田
5 小泉 太郎
でselectで姓を検索するとき、レコードの「名」に値がある場合、
それを検索対象に入れての完全一致の結果を得たいのですが、
どう書けばいいんでしょうか？
「小泉」で検索、結果 0
「阿部」で検索、結果 1
「阿部」＋「晋三」で検索、結果 1
「小泉」＋「純一郎」で検索されたとき、結果 1
こんな感じで結果を得たいのです
わかりにくくてすみません…。
インデックス使われないからあまりやりたくないけど
select * from member
where 姓 = '安部' and (名 is null or 名 = '晋三')
でいいんじゃないの
select * from member
where 姓 = '安部' and (名 is null or 名 = '晋三')
でいいんじゃないの
>>403
それでいけそうです。ありがとうございます！
それでいけそうです。ありがとうございます！
where 性=’性条件’ AND 名=’名条件’
だけでいんじゃねーの。空白は空白
だけでいんじゃねーの。空白は空白
>>408 私はあなたをSuitonしたいと本気で思いました。
>>409 そうですか。それならば謝罪いたしましょう
http://dev.mysql.com/doc/refman/5.1-olh/ja/create-index.html
>たとえば、接頭辞の最大長は MyISAM テーブルでは 1000 バイト、InnoDB テーブルでは 767 バイトです。
これはすなわちインデックスを張れる最大のサイズと解釈して良いのでしょうか？
URLを格納するVarcharフィールドにインデックスを張りたいのですがこの制約に引っかかってしまうので困っています
>たとえば、接頭辞の最大長は MyISAM テーブルでは 1000 バイト、InnoDB テーブルでは 767 バイトです。
これはすなわちインデックスを張れる最大のサイズと解釈して良いのでしょうか？
URLを格納するVarcharフィールドにインデックスを張りたいのですがこの制約に引っかかってしまうので困っています
>>411
そのページに書いてあるとおりにすればOK
> col_name(length) 構文を使用してインデックス接頭辞長を指定することによって、
> カラム値の先頭の部分のみを使用するインデックスを作成できます。
CREATE TABLE test (c1 VARCHAR(1000));
CREATE INDEX idx1 ON test (c1(200));
そのページに書いてあるとおりにすればOK
> col_name(length) 構文を使用してインデックス接頭辞長を指定することによって、
> カラム値の先頭の部分のみを使用するインデックスを作成できます。
CREATE TABLE test (c1 VARCHAR(1000));
CREATE INDEX idx1 ON test (c1(200));
>>413
ありがとうございます！
ありがとうございます！
>>415じゃないけど、LIKE REVERSE('%/db/1295436346/') で前方一致になるからindexが効くという認識でよい？
>>417
YES
YES
>>418
Thank you, baby!
Thank you, baby!
お尻を責めるならあらかじめひっくり返しておけ
ということか。万事に通ずる法則だな。
ということか。万事に通ずる法則だな。
質問です
mysqlって何件くらいのデータ数で重くなりますか？
カラムにもよると思いますがおおよその答えでいいのでお願いします。
mysqlって何件くらいのデータ数で重くなりますか？
カラムにもよると思いますがおおよその答えでいいのでお願いします。
>>422
1件より2件の方が重いです。
1件より2件の方が重いです。
まあ答えるの難しいよね
なんて質問したらいいのかな
でも言いたいことはわかるよね？
なんて質問したらいいのかな
でも言いたいことはわかるよね？
>>422
沢山だと重い。少なければ重くない。
沢山だと重い。少なければ重くない。
自分でやってみればいいのに
メモリやCPUによっても変わってくるし答えようが無い
メモリやCPUによっても変わってくるし答えようが無い
何万件だろうが適切にindexが設定されてて単純なクエリーなら重くない。
今度はindexのサイズが問題になるが元のtableのレコード数だけで示すことはできない。
今度はindexのサイズが問題になるが元のtableのレコード数だけで示すことはできない。
>>422
150万件くらいのデータと8000件くらいのデータ、innodb。
SELECTでJOINあり、条件あり。
my.cnfデフォで95秒くらい。
innodb_buffer_pool_size = 6G
query_cache_size = 64M
sort_buffer_size = 64M
join_buffer_size = 64M
とかで、3秒弱。
インデックスを使うようにすると、どちらも一瞬で終わる。
パフォーマンスはデータベースの設計により大きく左右されるが、最近のマシン(メモリ4Gとか)だと、
ほとんどをメモリに乗っかるようにしておけば、何も考えなくても数百万件くらいなら余裕なんじゃなかろうか。
150万件くらいのデータと8000件くらいのデータ、innodb。
SELECTでJOINあり、条件あり。
my.cnfデフォで95秒くらい。
innodb_buffer_pool_size = 6G
query_cache_size = 64M
sort_buffer_size = 64M
join_buffer_size = 64M
とかで、3秒弱。
インデックスを使うようにすると、どちらも一瞬で終わる。
パフォーマンスはデータベースの設計により大きく左右されるが、最近のマシン(メモリ4Gとか)だと、
ほとんどをメモリに乗っかるようにしておけば、何も考えなくても数百万件くらいなら余裕なんじゃなかろうか。
>>435
インデックス振らなきゃそんなもんだろ
インデックス振らなきゃそんなもんだろ
よくデータをメモリに全部乗っけるという表現がなされますが、具体的にはどうすればいいのでしょうか？
ストレージエンジンをMemoryにするわけでは無いですよね
MyISAMのバッファをデータサイズ以上に設定しておけばOSが勝手にやってくれたりするのでしょうか
ストレージエンジンをMemoryにするわけでは無いですよね
MyISAMのバッファをデータサイズ以上に設定しておけばOSが勝手にやってくれたりするのでしょうか
質問端折り過ぎた
ORDER BYでDESCとASCが両方あるとき
インデックスが効かないんだけどどうしたらいいの？
ORDER BYでDESCとASCが両方あるとき
インデックスが効かないんだけどどうしたらいいの？
知っているかたがいらしたら教えてほしいのですが、
UNIQUE キーは SELECT 文等でも使われるのでしょうか。
それとも、重複チェックに使われるだけで、
INDEX キーのようには使われないのでしょうか。
UNIQUE キーは SELECT 文等でも使われるのでしょうか。
それとも、重複チェックに使われるだけで、
INDEX キーのようには使われないのでしょうか。
>>446
MySQLでは使われる
MySQLでは使われる
>>447-448
良く知りもしないで適当なこと言ってんじゃねぇよｗ
良く知りもしないで適当なこと言ってんじゃねぇよｗ
至って普通のLAMP構成でアプリ動かしてますが
MySQL5.1.50 InnoDBプラグイン使用で
スローログを見てると単純にINSERTするだけのログテーブルのINSERTに時間がかかっています
これは何が原因なのでしょうか
レコード数は現在800万程度です
MySQL5.1.50 InnoDBプラグイン使用で
スローログを見てると単純にINSERTするだけのログテーブルのINSERTに時間がかかっています
これは何が原因なのでしょうか
レコード数は現在800万程度です
前へ 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 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- 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 総合 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 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について