元スレMySQL 総合 Part19
mysql覧 / PC版 / みんなの評価 :
前へ
401 :
テーブル member
no 姓 名
1 田中 角栄
2 小泉 純一郎
3 阿部
4 福田
5 小泉 太郎
でselectで姓を検索するとき、レコードの「名」に値がある場合、
それを検索対象に入れての完全一致の結果を得たいのですが、
どう書けばいいんでしょうか？
「小泉」で検索、結果 0
「阿部」で検索、結果 1
「阿部」＋「晋三」で検索、結果 1
「小泉」＋「純一郎」で検索されたとき、結果 1
こんな感じで結果を得たいのです
わかりにくくてすみません…。
403 = :
インデックス使われないからあまりやりたくないけど
select * from member
where 姓 = '安部' and (名 is null or 名 = '晋三')
でいいんじゃないの
404 = :
> 「阿部」＋「晋三」で検索、結果 1
晋三が見当たらないんですが
405 = :
だから、何？
406 = 401 :
>>403
それでいけそうです。ありがとうございます！
408 = :
性条件って何？童貞とか？ｗｗ
409 = :
>>408 私はあなたをSuitonしたいと本気で思いました。
410 = :
>>409 そうですか。それならば謝罪いたしましょう
411 = :
http://dev.mysql.com/doc/refman/5.1-olh/ja/create-index.html
>たとえば、接頭辞の最大長は MyISAM テーブルでは 1000 バイト、InnoDB テーブルでは 767 バイトです。
これはすなわちインデックスを張れる最大のサイズと解釈して良いのでしょうか？
URLを格納するVarcharフィールドにインデックスを張りたいのですがこの制約に引っかかってしまうので困っています
413 = :
>>411
そのページに書いてあるとおりにすればOK
> col_name(length) 構文を使用してインデックス接頭辞長を指定することによって、
> カラム値の先頭の部分のみを使用するインデックスを作成できます。
CREATE TABLE test (c1 VARCHAR(1000));
CREATE INDEX idx1 ON test (c1(200));
414 = :
>>413
ありがとうございます！
415 = :
文字列のお尻で高速に検索かけたいときはどうしてますか？
418 = :
>>417
YES
419 = :
>>418
Thank you, baby!
420 = :
お尻を責めるならあらかじめひっくり返しておけ
ということか。万事に通ずる法則だな。
421 = :
一万件も同様の事があると思えんｗ
422 :
質問です
mysqlって何件くらいのデータ数で重くなりますか？
カラムにもよると思いますがおおよその答えでいいのでお願いします。
423 = :
カラムによります。
424 = :
>>422
1件より2件の方が重いです。
425 = 422 :
まあ答えるの難しいよね
なんて質問したらいいのかな
でも言いたいことはわかるよね？
426 = :
>>425
適切な例を示せばいいんだよ。
そうすれば今度は「実測しろ」って言われるから。
427 = :
とりあえず、メモリに入り切るかどうかだろ。
428 = :
>>422
沢山だと重い。少なければ重くない。
429 = 422 :
>>426
実測とかそんな高等テクニック持ってないし
ググっても見つからないからここで聞いてる
例を出して聞くと揚げ足取られるからなかなか難しいんですよ
でもこれって誰もが聞きたいことじゃないかな？
430 = :
回答出てるじゃん、>>424とか>>428とか。
これじゃ不満なわけ？
431 = :
自分でやってみればいいのに
メモリやCPUによっても変わってくるし答えようが無い
432 = :
>>422
１００万件ぐらいまでならたいしたこと無い
ってどこかの大規模サイトの人がゆってた
433 = :
何万件だろうが適切にindexが設定されてて単純なクエリーなら重くない。
今度はindexのサイズが問題になるが元のtableのレコード数だけで示すことはできない。
434 = :
>>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とか)だと、
ほとんどをメモリに乗っかるようにしておけば、何も考えなくても数百万件くらいなら余裕なんじゃなかろうか。
435 = :
3秒って、そりゃまた随分と遅いなぁ
436 = :
>>435
インデックス振らなきゃそんなもんだろ
437 = :
よくデータをメモリに全部乗っけるという表現がなされますが、具体的にはどうすればいいのでしょうか？
ストレージエンジンをMemoryにするわけでは無いですよね
MyISAMのバッファをデータサイズ以上に設定しておけばOSが勝手にやってくれたりするのでしょうか
438 = :
>>437
あぁ、それウソだから。
データを全部メモリに乗せるなんて現代の技術では不可能だから。
デマに惑わされないように気をつけたほうがいいよ。
441 = :
トホホな質問が続きます
442 = :
>>441
http://www.tohoho-web.com/
を参照ください。
443 = :
質問端折り過ぎた
ORDER BYでDESCとASCが両方あるとき
インデックスが効かないんだけどどうしたらいいの？
444 = :
仮に、両カラムをDESCに揃えたらインデックス利くの?
445 = :
>>441
低レベルSQL講座が始まってんだよ
察してやれ
アホ担当の方、さあ出番ですよ
ｶﾞﾑﾊﾞって
446 = :
知っているかたがいらしたら教えてほしいのですが、
UNIQUE キーは SELECT 文等でも使われるのでしょうか。
それとも、重複チェックに使われるだけで、
INDEX キーのようには使われないのでしょうか。
447 = :
>>446
MySQLでは使われる
448 = :
>>443
インデックス格納順にアクセスすることにより
ソート処理を省く最適化のことを言っているなら、
ASCとDESC混ぜたらどうしようもないと思う
449 = :
>>447-448
良く知りもしないで適当なこと言ってんじゃねぇよｗ
450 = :
至って普通のLAMP構成でアプリ動かしてますが
MySQL5.1.50 InnoDBプラグイン使用で
スローログを見てると単純にINSERTするだけのログテーブルのINSERTに時間がかかっています
これは何が原因なのでしょうか
レコード数は現在800万程度です
みんなの評価 :
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 ○
トップメニューへ / →のくす牧場書庫について