元スレMySQL 総合 Part25
mysql覧 / PC版 / みんなの評価 :
前へ
501 = :
データの挿入時に発動するトリガーを
一時的にオフにしたいんだけど
どうしたらいいかな
502 :
トリガー内で特定の変数を見て、その値によって処理するかどうかを分岐する。
トリガーを動かしたくない場合は事前にその変数をセットする。
503 = :
>>502
マジでそんな原始的な方法しかないの？
それならトリガー削除した方がまだマシだな・・・
504 = :
トリガーを動かして欲しくないのかどうかは、使う側でしか分からないだろう
505 = :
>>504
ALTER TRIGGER fugafuga DISABLE;
とか
ALTER TABLE hogehoge DISABLE ALL TRIGGERS;
が使いたいよね
506 = :
クエリー実行してエラーが起きたとき、それが
そのクエリそのもので起きたのか、それともトリガー内で起きたのかを
区別する方法はある？
507 = :
そもそもクエリそのものが失敗してもトリガは起動されるのか？
508 = :
あっ！
509 = :
>>507
・クエリが失敗したのでトリガが起動されていない
・クエリが成功したがトリガが失敗した
このふたつの区別がつかないんだよ
511 = :
素朴な疑問ですけど、
1つのテーブルにレコードを追加していくより、
ある一定数以上はテーブルを分けた方がパフォーマンが良くないですか？
パーティショニングとかメモリを増やすとか色々対策はあると思いますけど
1つのテーブル内に詰め込むより、分けた方が速いと思うんです。
1テーブル1000万レコードから探すより、
100テーブル10万レコードから探す方が速いと思うんです。
こんな考え方に対してやっぱりおかしい・間違ってますかね？
512 :
MySQLで現在扱っているDBがあり、その性能に関しての疑問なら、
その試みを実際に試すことで回答は出ると思う。
MySQLに限定しないことなら、DB設計スレで聞く方が良いかもしれない。
言えることは、実運用時のデータアクセスの傾向と、
対するテーブル設計のチューニングに関係しそう。
513 = :
結局は設計の話になってくると思うけど、それだとどのテーブルから探すかを決定してからって事なんでしょ。
試してみて結果を教えてくださいw
514 = :
>>512-513
例に出したように1000万レコード、1テーブルに10カラムで試してみたのですが、
1テーブルでwhere検索すると数十秒～数分かかります。（検索条件による）
もちろん、テーブル設計やハードを改善していけば変わってくるのでしょうが、
そういう物理的なコストをかけるより、単純なテーブル分散の方が良いと思うのですが、
その事に対してはなにもないのでしょうか？
皆さんもある程度試したうえで発言されてると思いますが。
515 = :
さあ
516 = :
テーブルにインデックスが張ってあり、検索時にそのインデックスを効率的に利用しているかどうか、とか
あるいは、テーブル上の全レコードを見ないと結果が出せないような検索（フルスキャン）なのか、とか
あとはストレージの性能とか、色々ありそうだけど
検索条件によるって所が気にはなる
仮にテーブル分散しても、分散したテーブル全てを見ないと結果が出せないなら、それほど変わらない気がする。
試した上でやれるかと言われると、じゃデータくださいになるような気もするし。
517 = :
>>514
explainの結果貼れば一発でわかるよ
518 = :
1000万程度なら瞬時に出るはずで、1秒以上かかるなら何かがおかしいと
疑ってみるべき、そこ直さないとテーブル分割は効果まったくでないと思う
520 :
Oracleより性能良くなったり、同等だったら、
困る会社が出てくるんじゃないの？
521 = :
MySQLもOracleから出てるしなｗ
522 = :
なんでOracleがMySQLを抱え込んだのかな？
523 = :
やっぱそうなんだ
なんでもかんでもPL/SQLで組んだシステムだから、その辺りをアプリケーションサーバー側に持っていくの、かなりしんどいんだよな
524 = :
分析関数使ってる分の代替手段を考えないといけないとか
互換のない部分の心配はしなくていいのかな？
528 = :
保守することを考えてDBに機能を持たせることはやめた
トリガも廃止した
531 :
>>528
性能要件が満たせるのか？
532 = 531 :
>>528
最近のやつってRDBの良さをつぶす構成を取りたがるのはなんなんだろうな。
RDBをデータの入れ物としか思ってなくて失敗しているシステムをよく見かけるようになってきているけどな。
533 :
失敗とは言わんが、そんなにパフォーマンス気にするんやったらもっとDBMSに仕事させろやと思う事はある。
534 = 531 :
Oracle使いこなしているシステムでMySQLにするのに、MySQLに詳しいメンバーがいないなら、その時点でやばいプロジェクトだぞ。
535 :
MySQLのメーリンは不在通知の自動除去とかやってないのかい?
http://www.mysql.gr.jp/mysqlml/mysql/thread/16301-16400
536 = :
PHPでpostしてレンタルサーバーのMySQLに絵文字を入れるため
utf8mb4を使いたいのですがmy.cnfがいじれません
以下のよう既存のデータを変更しても
alter database データベース名 default character set utf8mb4;
character-set-serverとdefault-character-setが変更できないためうまくいきませんでした
何か参考になるサイトなどはないでしょうか
537 = :
>>532
WordPressがもてはやされてる時点でな
使い勝手は良いのかもしれないが、後から拡張できずに失敗してるパターンが目立つ
539 = :
プライマリキー二つが重複してないかのチェックにかかりそうな気が
540 = :
大量にINSERTする前にBEGIN 、 終了時に COMMIT 入れたらどうなる？
541 = :
>>539
空からの始めのうちと400万件のころとで1INSERTあたりのレスポンスにあまり差がないので、
そこのコストではない気がしています。
>>540
トランザクションを使う場合と使わない場合を比較してみたところ、
トータルの処理時間としては大した差がでませんでした。
542 = :
キーに原因があるかどうかを確認するために
キー無しで定義してデータ入れてからキー設定してみては
544 = :
>>532
RDBの良さはリレーショナルだけで十分だ
それ以上はいらぬ
545 :
【ＴＰＰ断固反対（嘘）】 自由ホランチョ党 【スタンフォード（嘘）】
安倍首相がスタンフォード大前で「嘘つき安倍は帰れ！」と抗議を受ける
https://www.youtube.com/watch?v=HkMjwggu3ko
安倍総理、麻生副総理も経歴詐称？ 海外留学の経歴が削除されていた！ 「学歴詐称」は公職選挙法違反
【日本の金正恩】 安倍寛信 【安倍晋三の兄】
復活した電力会社の原発広告に文化人や芸能人がまたぞろ登場して原発をPR！ 500万円の高額ギャラも 勝間和代 三橋貴明 佐藤優
三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている
ネットにおける言論統制は、非公然で陰湿に進んでいるようです
https://twitter.com/toka iamada/status/664017453324726272
山本太郎
先ず真のテロリズムと戦うべき！
汚染物質をバラ撒き、国民を無理心中へと巻き込む政治家、経済団体等をテロ指定、資産凍結するのが筋ではないか！
【だってお金欲しいもん～】
今朝、辺野古で新基地建設に反対するママの会メンバーに対して、
機動隊員が「お前たちには汚い血が流れている」などと暴言を吐いたそうです。
自分のやっていることを「だってお金欲しいもん～」「俺の写真を待ち受けにしろ」とも （顔写真）
https://twitter.com/MothersNoWar/status/690357793702940672
547 = :
>>537
217 : NAME IS NULL2015/08/10(月) 22:59:49.12 ID:???
何かアドバイスお願いします。
WordPressとMySQLをIISサーバーにインストールしたのですが、
いちおう動いているのですが、何となく動きが遅いんです。
どのページを開いても読み込みに２～５秒掛かります。
これなんかが良い例。
Wordpressはカスタムフィールドを実現するためにDB設計がクソ中のクソで、
RDBMSの良いところを全部殺しちゃってるからとにかく遅い。
普通にSELECTかけたらアプリ側のロジック込みで0.15秒くらいのことが、
Wordpressだと2秒とか5秒とかかかるのが当たり前になってる。
548 = :
ほんとそれ。
ただ無料だからで飛びつく馬鹿ばかり。
549 = :
全てのトリガーを消し去りたい！
550 :
辛いことがあったのか？
マ板で相談してみたら？
みんなの評価 :
mysql一覧へ類似してるかもしれないスレッド
- MySQL 総合 Part24 (1010) - [94%] - 2015/2/14 4:46
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part23 (992) - [94%] - 2013/8/11 17:00
- MySQL 総合 Part22 (1001) - [94%] - 2012/7/10 16:45
- MySQL 総合 Part26 (860) - [94%] - 2023/2/2 9:30
- MySQL 総合 Part21 (1001) - [94%] - 2011/12/25 22:16
- MySQL 総合 Part20 (995) - [94%] - 2011/10/17 4:48
- MySQL 総合 Part12 (1001) - [89%] - 2008/1/30 17:34 ○
- MySQL 総合 Part18 (986) - [89%] - 2011/1/17 15:46
- MySQL 総合 Part13 (996) - [89%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [89%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part17 (1001) - [89%] - 2010/6/10 20:47 ○
- MySQL 総合 Part19 (982) - [89%] - 2011/6/9 2:33
- MySQL vs PostgreSQL Part2 (941) - [36%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について