MySQL 総合 Part26 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>697
処理速度を優先するために一気に上がる仕様になっている。 Windows上のクライアントツールってワークベンチが1番人気？ MySQLはgrepコマンドよりも検索が遅いらしいですが
どうにかして速くする方法はありませんか？ むしろgrepよりも速いDBなんかあんのかよ？ｗ
全文検索したけりゃ転置インデックスでもはれ。 むしろgrepより遅いDBなんてあんのかよww
RDB理解してなさすぎw >>702
あ、いえ、全文検索じゃないです。
商品IDがキーになっている検索です。
likeみたいなものはないですね。 >>705
じゃあインデックスをはるだけやろ。
grepなんかよりもはるかに速いわ！ >>707
不思議なことにインデックス貼ってるんですよ show create table テーブル名 と
実行しているSQL文を晒せ 論文出しておきますね。
これの7ページ、3.1 検索処理 に比較結果が載っています。
ユニケージ開発手法に基づく Unix ファイルシステムとシェルを用いたデータベースの構築と操作
https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&;item_id=178874&file_id=1&file_no=1
> ユニケージにより構築されたデータベースは特段の高速化の工夫を施さずとも、
> MySQLより高速であることがわかった >>708
EXPLAINで、インデックスがホントに使われてるか確認しろ。
まさか、ストレージエンジンがヘンなのとか、レコード数がメチャ少ないとか、ドケチ設定にしてるとか、そういうDBに超不利な比較をやっとらんやろな？ >>712
ちゃんと実行条件を揃えて計測しているようですよ
> 10^6件レコードのテーブルに対して実行し、timeコマンドによる実行時間を計測した。
> MySQLへのクエリ送信には、mysqlコマンドを使用した。
> ユニケージでは"商品ID"フィールドをキーとしてファイルをソートしておき 、
> MySQLでは同フィールドをプライマリキーとしてテーブルを作成した。
> mysqlコマンドはソケットインタフェースを経由する。ユニケージでも実行条件を
> 揃えるため、sshコマンドを利用してネットワーク越しに処理を実行して結果を取得した 実行条件を揃えてあるとは言いがたいな
これなら何の検索かけて無くても同じ速度出るだろ コレはワロス
何と何を比較した結果か全く理解してないのな
よくこんなんで論文とか書くわ 実行条件揃えたというなら、
このテーブルとファイルをこのまま使って
1000件の商品IDをランダムに検索かけて
その商品名を表示させてみ ユニケージはどこかでHadoopよりも速いって書いていた気がします
たぶんローカルでの検索 vs ネットワーク越しのHadoopサーバーからの検索でしょう
データ更新やデータ同期の話を全部すっ飛ばして
ローカル検索、しかもインデックスを使わない全件検索の比較しかしないで
速いと言っていただけな気がします。 ここで例としてあげられたロジックらしきものって
ファイルの先頭から条件を満たすレコードを抜き出して
計算し､表示しているだけだよ
シーケンシャルファイルのバッチ処理と同じ
しかも予めソートされているとなれば一気読み一気処理 参考文献
[1] UNIXという考え方・・・単にUNIXの考え方を書いてある本
[2] The Open Group Base ・・・ただのPOSIXの仕様
[3] 松田康之 川下からの（略）・・・ ズブズブの関係
http://www.shoninsha.co.jp/modules/computer3/2009/07/14/14/
[4] NYSOL・・・MCMD2: Mコマンドとは - NYSOL（ページののタイトル）
https://www.nysol.jp/mcmd2/jp/sect-whatis.html
> 大規模表構造データ(CSV)を高速に処理する目的で開発されたコマンド群である。
> ある大企業で実施された大規模システム開発プロジェクトにおいて
> 「松田康之氏」（上の人）が発案したものであり
大規模表構造データ(CSV)とはただのCSVのことのようである
https://www.nysol.jp/mcmd2/jp/sect-csv.html
> MCMDが処理する表構造データはFigure 2.5に例示されるような
> CSV(Comma Separated Values)フォーマットである
[5] 當仲 寛哲 ユニケージ原論・・・この論文書いた人
[6] POSIX中心主義・・・ユニケージの社員が言ってること
[7] ものづくりのための・・・同上
参考文献 なんや、マジメに相手してやって損したわ。。。
アホらし。 この場合はローカルかネットワーク越しかはほとんど関係ない
SQL見ればわかるやろ
RDB使ってこんな設計するやついたら殴り倒すわ VoicyとNFTアートとNFTゲームとDeFiとnoteに今すぐ参入したほうがいいぞ。
特にVoicyとNFTアートとDeFiはこれから伸びるだろうからおススメ
NFTアートとDeFiはこれから100倍規模の市場になるだろう！ mysqlのストレージエンジンにmemoryってのがあるけど、これについて確認なんですけど
これって利用する場合起動のたびにcreate tableしてデータをinsertする、そして
シャットダウン時に更新されているならディスクに書き戻す必要があるって事だよね？ やはり。使う状況を考えないといけないエンジンだなぁ。 そんな考えることでは。ｗ
速度優先の小さいテーブルをテンポラリとかキャッシュとかで使いたいときだけ。 とある絞り込み条件での
・総件数
・特定の並び順での任意の範囲のレコード(1000件ある内の100〜200行目など)
の2つを取りたい場合ってどうやる？
同一の絞り込み条件のクエリ2回投げる？ 適切にインデックスが張られてれば数数えるのは低コストだしね UNIQUE制約って、インデックスとしても機能すんだっけか 逆で、UNIQUE制約のためにはインデックスが必須なんちゃうかったっけ？ 以下のようなデータがあるとします。
name｜feature
バナナ｜黄色
バナナ｜甘い
みかん｜オレンジ
みかん｜甘い
「featureが黄色で甘い」＝バナナを抽出したいのですが、
SELECT * FROM fruits WHERE feature IN('黄色','甘い')
としても、「みかん」まで抽出されてしまいます。
だからといって
SELECT * FROM fruits WHERE feature='黄色' AND feature='甘い'
だとヒットしません。
サブクエリを使う以外で、複数AND条件に一致するデータを抽出する方法はないでしょうか？ バナナ1行返ればいいなら group by ~ having で
条件に合うものを count したり sum したり
2行欲しいならサブクエリ必要と思われ >>739
素直にサブクエリ使いなよ
考えるだけ無駄だし時間もかかる わかりました。そうします。お二人ともありがとうございました。 JOINでなんとかならんか？
最近使わないからすぐ出てこないけど。 カテゴリーが異なるものを同じカラムで扱うのは無理がある >>744
いや、それは解釈による。
プロパティだと思えば複数あって当然。 >みかん｜オレンジ
は？ってなったわw
色のことね >>739
コスト的にはサブクエリと同じかもしれんがself joinでいけるやろ
SELECT * FROM fruits a INNER JOIN fruits b ON a.name = b.name
WHERE a.feature='黄色' AND b.feature='甘い'
もしくは
SELECT * FROM fruits a INNER JOIN fruits b ON a.name = b.name AND a.feature='黄色' AND b.feature='甘い' >>748
それでは検索したいものが３つ4つと増えた時に困る
プログラムで生成するのは余裕だろうが
あるいはgroup by使ってもいいけどサブクエリNGとした理由が何かだね >>749
> それでは検索したいものが３つ4つと増えた時に困る
それはサブクエリも似たようなもんやろ。 「featureが黄色」でname取得
「featureが甘い」でname取得
何れにも存在するname取得
これが簡単そう >>750
検索対象が増えるたびに結合数が増えてくんだが、、、
あとselect句のことも考えてあげて >>753
それはサブクエリも似たようなもんやろ。
4レスぶり2回目。 group by havingしたサブクエリの結果で
もう1回データ取ってくるんやろ
MySQLはgroup byされた任意の数の行を
列にピボットできる関数ないからね >>757
select * from fruits x where
(select count(*) from fruits y where
y.name = x.name and
y.feature in ('黄色', '甘い')) = 2; 結局、プログラム使えてDBの負荷下げるなら、
検索の数だけSQL実行するのが良いんじゃないか？
その方がシンプルだし、バグが発生しづらいだろ >>759
そんなサブクエリよりは結合のが速いんちゃうの？
マイちゃんマリアちゃんならとくに。
レコード数とかインデックスとかカーディナリティとかメモリの余裕とかにもよるかもしらんが。 ネタかもしれないがたまにはSQLを書いてみる。
SELECT * FROM fruits WHERE name='バナナ ' AND feature IN('黄色','甘い'); 妖しげなSQLで
SELECT name FROM (
SELECT distinct name, feature FROM fruits WHERE feature IN('黄色','甘い') GROUP BY name,feature) w
GROUP BY name HAVING COUNT(name) = 2; >>764
count(distinct feature) 使えばネストしなくていいよ >>765
考えたんですが､私の頭ではちょっと無理っぽい >>767
その前にname,feature には一意制約付いてないのかな
>>764 は付いてない可能性を考慮して書いたと思うが
select name from fruits
where feature in ('黄色', '甘い')
group by name
having count(distinct feature) = 2;
一意制約ついているなら count(*) でOK 739です。みなさん色々議論していただきありがとうございます。
まさに、>>768の書き方がシンプルで目的通りになりました！
サブクエリやプログラムで回す事を考えていましたが、
768のソースがわかりやすく、コストも少ないと思います。
本当に素晴らしいSQLをありがとうございました >>768
確かに、一意制約がないという前提で書いてました
質問者が書いてないことについては最悪を想定ですね 1秒に5回ぐらいのfloat x 5のデータ
最初の一年分をクエリするとすぐレスポンスあるのに
２年目以降で遅くなるの何故だ >>773
1. テーブル定義、インデックス定義、データ件数
2. 最初の1年分を取得するクエリ、2年目以降を取得するクエリ
3. それぞれのクエリのEXPLAIN ANALYZEの結果
4. MySQLバージョン、稼働環境
遅い原因を確認するためには1~3の情報は最低必要
ただ1レコードfloat(4バイト) x 5カラムで
秒間5件の1年分を全部取得するようなクエリなら
容量が大きいので遅くてもなんら不思議はない CREATE TABLE mytable (`id` bigint unsigned NOT NULL AUTO_INCREMENT, `timestamp` bigint unsigned , `v1` float , `v2` float, `v3` float, `v4` float , PRIMARY KEY(`id`)) ;
select * from mytable where timestamp <= 1645082937 limit 30000 ぱっと見ですまんが、timestampにもインデックス張ってみたら >>776
パッと見でもそうでなくても、絶対そうやろ。ｗ timestampという名前のカラムのデータ型がbigintというあたりでネタだと気づけよ！ 犬のマイクロチップ義務化法。
これがスマートダストサイズになって痛みもない、
ってことになったら人間にも適用しようとするんだろうね。
://twitter.com/MIYAKE_YOHEI/status/1254403308137009152?s=20
新型コロナワクチン接種証明書のインプラント 希望者に埋め込み スウェーデン
１０〜１５年後にはマイクロチップを埋め込んだ人が一般的になる。
://twitter.com/amanomotoyasu/status/1473396195355951104?s=20
山梨の株式会社「PATIC TRUST」のホームページに、現在は削除されていますが、
プロジェクトの目的はRFIDマイクロチップを全ての人に埋め込み、
国際的なデジタル認証システムを構築することであると書かれています。
://twitter.com/shantiphula/status/1313095383271174150?s=20
https://twitter.com/5chan_nel (5ch newer account) 早く人間用マイクロチップほしいよね
家のカギとSuicaを手の甲に内蔵したいわ >>781
mariadbのほうが高機能
mysqlはお金を払うとサポートが受けられる 以下のような２つのテーブルを紐付けたい場合にはどう書けばよいのでしょうか？
具体的には、Prodテーブルのフィールドをshopsテーブルのnameを共通で紐付けたいです。
* shop_id => Shops.name
* send_shop_id => Shops.name
Prodテーブル
id name shop_id send_shop_id
1 Mac 4 1
2 MacBook 3 2
3 MacBookAir 2 3
4 iPhone 1 4
Shops
id name
1 北海道
2 東京
3 大阪
4 沖縄
期待する結果
Prod.id Prod.name Shop.name as shop_id Shops.name as send_shop_id
1 Mac 沖縄 北海道
2 MacBook 大阪 東京
3 MacBookAir 東京 大阪
4 iPhone 北海道 沖縄 以下のような２つのテーブルを紐付けたい場合にはどう書けばよいのでしょうか？
具体的には、Prodテーブルのフィールドをshopsテーブルのnameを共通で紐付けたいです。
* shop_id => Shops.name
* send_shop_id => Shops.name
Prodテーブル
id name shop_id send_shop_id
1 Mac 4 1
2 MacBook 3 2
3 MacBookAir 2 3
4 iPhone 1 4
Shops
id name
1 北海道
2 東京
3 大阪
4 沖縄
期待する結果
Prod.id Prod.name Shop.name as shop_id Shops.name as send_shop_id
1 Mac 沖縄 北海道
2 MacBook 大阪 東京
3 MacBookAir 東京 大阪
4 iPhone 北海道 沖縄 >>786
2回ジョインして
from Prod p
join Shop s1 on p.shop_id = s1.id
join Shop s2 on p.send_shop_id = s2.id >>787
ありがとうございます！
助かりました！ >>789
ジョインジョインで解決しました！
ありがとうございます！ 基本的にOracleでライセンス買ってるとMySQLでも商用ライセンス買う必要有るの? >>791
ああ前提がOracle→MySQLへのマイグレーション考えてます そんなことは無いです
普通にOracle捨ててMariaDBにしました
死ぬほどつらかったけど楽勝でした デストリはどこもかしこもmiria使ってるな
ユーザーにとってはどっちでも良いんだけどね indexの数値(float)を間違って10大きな数値にしてしまった
一括で10減らすコマンドないでしょうか ■ このスレッドは過去ログ倉庫に格納されています
