私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part25
mysql スレッド一覧へ / mysql とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
データの挿入時に発動するトリガーを
一時的にオフにしたいんだけど
どうしたらいいかな
一時的にオフにしたいんだけど
どうしたらいいかな
トリガー内で特定の変数を見て、その値によって処理するかどうかを分岐する。
トリガーを動かしたくない場合は事前にその変数をセットする。
トリガーを動かしたくない場合は事前にその変数をセットする。
トリガーを動かして欲しくないのかどうかは、使う側でしか分からないだろう
クエリー実行してエラーが起きたとき、それが
そのクエリそのもので起きたのか、それともトリガー内で起きたのかを
区別する方法はある?
そのクエリそのもので起きたのか、それともトリガー内で起きたのかを
区別する方法はある?
クエリが失敗した→クエリでエラーが出る(トリガーは動いていない)
クエリが成功した→クエリでエラーは出ない(トリガーの成否でエラー?)
クエリが成功した→クエリでエラーは出ない(トリガーの成否でエラー?)
素朴な疑問ですけど、
1つのテーブルにレコードを追加していくより、
ある一定数以上はテーブルを分けた方がパフォーマンが良くないですか?
パーティショニングとかメモリを増やすとか色々対策はあると思いますけど
1つのテーブル内に詰め込むより、分けた方が速いと思うんです。
1テーブル1000万レコードから探すより、
100テーブル10万レコードから探す方が速いと思うんです。
こんな考え方に対してやっぱりおかしい・間違ってますかね?
1つのテーブルにレコードを追加していくより、
ある一定数以上はテーブルを分けた方がパフォーマンが良くないですか?
パーティショニングとかメモリを増やすとか色々対策はあると思いますけど
1つのテーブル内に詰め込むより、分けた方が速いと思うんです。
1テーブル1000万レコードから探すより、
100テーブル10万レコードから探す方が速いと思うんです。
こんな考え方に対してやっぱりおかしい・間違ってますかね?
MySQLで現在扱っているDBがあり、その性能に関しての疑問なら、
その試みを実際に試すことで回答は出ると思う。
MySQLに限定しないことなら、DB設計スレで聞く方が良いかもしれない。
言えることは、実運用時のデータアクセスの傾向と、
対するテーブル設計のチューニングに関係しそう。
その試みを実際に試すことで回答は出ると思う。
MySQLに限定しないことなら、DB設計スレで聞く方が良いかもしれない。
言えることは、実運用時のデータアクセスの傾向と、
対するテーブル設計のチューニングに関係しそう。
結局は設計の話になってくると思うけど、それだとどのテーブルから探すかを決定してからって事なんでしょ。
試してみて結果を教えてくださいw
試してみて結果を教えてくださいw
>>512-513
例に出したように1000万レコード、1テーブルに10カラムで試してみたのですが、
1テーブルでwhere検索すると数十秒~数分かかります。(検索条件による)
もちろん、テーブル設計やハードを改善していけば変わってくるのでしょうが、
そういう物理的なコストをかけるより、単純なテーブル分散の方が良いと思うのですが、
その事に対してはなにもないのでしょうか?
皆さんもある程度試したうえで発言されてると思いますが。
例に出したように1000万レコード、1テーブルに10カラムで試してみたのですが、
1テーブルでwhere検索すると数十秒~数分かかります。(検索条件による)
もちろん、テーブル設計やハードを改善していけば変わってくるのでしょうが、
そういう物理的なコストをかけるより、単純なテーブル分散の方が良いと思うのですが、
その事に対してはなにもないのでしょうか?
皆さんもある程度試したうえで発言されてると思いますが。
テーブルにインデックスが張ってあり、検索時にそのインデックスを効率的に利用しているかどうか、とか
あるいは、テーブル上の全レコードを見ないと結果が出せないような検索(フルスキャン)なのか、とか
あとはストレージの性能とか、色々ありそうだけど
検索条件によるって所が気にはなる
仮にテーブル分散しても、分散したテーブル全てを見ないと結果が出せないなら、それほど変わらない気がする。
試した上でやれるかと言われると、じゃデータくださいになるような気もするし。
あるいは、テーブル上の全レコードを見ないと結果が出せないような検索(フルスキャン)なのか、とか
あとはストレージの性能とか、色々ありそうだけど
検索条件によるって所が気にはなる
仮にテーブル分散しても、分散したテーブル全てを見ないと結果が出せないなら、それほど変わらない気がする。
試した上でやれるかと言われると、じゃデータくださいになるような気もするし。
>>514
explainの結果貼れば一発でわかるよ
explainの結果貼れば一発でわかるよ
1000万程度なら瞬時に出るはずで、1秒以上かかるなら何かがおかしいと
疑ってみるべき、そこ直さないとテーブル分割は効果まったくでないと思う
疑ってみるべき、そこ直さないとテーブル分割は効果まったくでないと思う
Oracleより性能良くなったり、同等だったら、
困る会社が出てくるんじゃないの?
困る会社が出てくるんじゃないの?
やっぱそうなんだ
なんでもかんでもPL/SQLで組んだシステムだから、その辺りをアプリケーションサーバー側に持っていくの、かなりしんどいんだよな
なんでもかんでもPL/SQLで組んだシステムだから、その辺りをアプリケーションサーバー側に持っていくの、かなりしんどいんだよな
分析関数使ってる分の代替手段を考えないといけないとか
互換のない部分の心配はしなくていいのかな?
互換のない部分の心配はしなくていいのかな?
>>523
MySQLでもストアドプロシージャでいいんじゃないの?
MySQLでもストアドプロシージャでいいんじゃないの?
>>523
アプリケーションサーバとDBサーバが別のコンピュータなら、ネットワーク通信による性能劣化が激しくて話しにならないぞ。
アプリケーションサーバとDBサーバが別のコンピュータなら、ネットワーク通信による性能劣化が激しくて話しにならないぞ。
>>519
ストアドが遅いなんて言っているが、外部からSQL文だけでどうにかしようとする方がはるかに遅くなる。
ストアドが遅いなんて話はMySQLのSQLが遅いだけだろ。
そもそも遅いという話自体が誤解のように感じる。
ストアド嫌いはストアドを悪くいうから気をつけな。
それにシステム全体の性能要件を考えずに遅い、速いを論じても意味がない。
ストアドが遅いなんて言っているが、外部からSQL文だけでどうにかしようとする方がはるかに遅くなる。
ストアドが遅いなんて話はMySQLのSQLが遅いだけだろ。
そもそも遅いという話自体が誤解のように感じる。
ストアド嫌いはストアドを悪くいうから気をつけな。
それにシステム全体の性能要件を考えずに遅い、速いを論じても意味がない。
保守することを考えてDBに機能を持たせることはやめた
トリガも廃止した
トリガも廃止した
>>528
性能要件が満たせるのか?
性能要件が満たせるのか?
失敗とは言わんが、そんなにパフォーマンス気にするんやったらもっとDBMSに仕事させろやと思う事はある。
Oracle使いこなしているシステムでMySQLにするのに、MySQLに詳しいメンバーがいないなら、その時点でやばいプロジェクトだぞ。
PHPでpostしてレンタルサーバーのMySQLに絵文字を入れるため
utf8mb4を使いたいのですがmy.cnfがいじれません
以下のよう既存のデータを変更しても
alter database データベース名 default character set utf8mb4;
character-set-serverとdefault-character-setが変更できないためうまくいきませんでした
何か参考になるサイトなどはないでしょうか
utf8mb4を使いたいのですがmy.cnfがいじれません
以下のよう既存のデータを変更しても
alter database データベース名 default character set utf8mb4;
character-set-serverとdefault-character-setが変更できないためうまくいきませんでした
何か参考になるサイトなどはないでしょうか
50byte程度のレコードを500万レコードほどINSERTするのに3分近くかかるのですが、
リソースモニタで監視してもCPUもディスクも数%(~15%程度)しか使用してなく、
何がボトルネックになっているのかよくわかりません。
CPUもメモリも全く余裕なので普通に考えるとストレージのIOなのですが、
リソースモニタでみる限りではディスクも働いてないので、
限界まで引き出せればもっと縮むのではと考え、質問させていただきました。
ソフト側の実装はマルチスレッドで、
各スレッド毎にコネクションを張ってINSERTしまくっています。
処理時間は、5スレッド前後で頭打ちになっているようです。
ハードウェアの主なスペックは下記のとおりです。
Xeon 16コア32スレッド
システムメモリ64GB
データ用ストレージSSDx2のRaid0
OSはWindows10proでMySQL5.7.11x64、my.iniはデフォルトから下記を編集しています。
(作業用端末を兼ねていますが、リソースの3/4はMySQLに割り当ててよいと考えています。)
sync_binlog=0
skip-innodb-doublewrite
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=8G
innodb_log_file_size=4G
innodb_io_capacity=10000
sort_buffer_size=16MB
max_heap_table_size=8G
key_buffer_size=4G
テーブル構造は、下記のような単純なものです。
CREATE TABLE `hoge_table` (
`hoge_id` varchar(127) NOT NULL,
`fuga` int(9) NOT NULL,
`aaa` tinyint(4) NOT NULL,
`bbb` tinyint(4) NOT NULL,
(略)
PRIMARY KEY (`hoge_id`,`fuga`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
以上、どこから調整していけばよいでしょうか。
よろしくお願いいたします。
リソースモニタで監視してもCPUもディスクも数%(~15%程度)しか使用してなく、
何がボトルネックになっているのかよくわかりません。
CPUもメモリも全く余裕なので普通に考えるとストレージのIOなのですが、
リソースモニタでみる限りではディスクも働いてないので、
限界まで引き出せればもっと縮むのではと考え、質問させていただきました。
ソフト側の実装はマルチスレッドで、
各スレッド毎にコネクションを張ってINSERTしまくっています。
処理時間は、5スレッド前後で頭打ちになっているようです。
ハードウェアの主なスペックは下記のとおりです。
Xeon 16コア32スレッド
システムメモリ64GB
データ用ストレージSSDx2のRaid0
OSはWindows10proでMySQL5.7.11x64、my.iniはデフォルトから下記を編集しています。
(作業用端末を兼ねていますが、リソースの3/4はMySQLに割り当ててよいと考えています。)
sync_binlog=0
skip-innodb-doublewrite
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=8G
innodb_log_file_size=4G
innodb_io_capacity=10000
sort_buffer_size=16MB
max_heap_table_size=8G
key_buffer_size=4G
テーブル構造は、下記のような単純なものです。
CREATE TABLE `hoge_table` (
`hoge_id` varchar(127) NOT NULL,
`fuga` int(9) NOT NULL,
`aaa` tinyint(4) NOT NULL,
`bbb` tinyint(4) NOT NULL,
(略)
PRIMARY KEY (`hoge_id`,`fuga`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED;
以上、どこから調整していけばよいでしょうか。
よろしくお願いいたします。
大量にINSERTする前にBEGIN 、 終了時に COMMIT 入れたらどうなる?
キーに原因があるかどうかを確認するために
キー無しで定義してデータ入れてからキー設定してみては
キー無しで定義してデータ入れてからキー設定してみては
ってWindowsか、ファイルシステムはNTFSだろうし、、、
別のOSで別のファイルシステムで試しても同じ数字になるか気になるな、、、
別のOSで別のファイルシステムで試しても同じ数字になるか気になるな、、、
【TPP断固反対(嘘)】 自由ホランチョ党 【スタンフォード(嘘)】
安倍首相がスタンフォード大前で「嘘つき安倍は帰れ!」と抗議を受ける
https://www.youtube.com/watch?v=HkMjwggu3ko
安倍総理、麻生副総理も経歴詐称? 海外留学の経歴が削除されていた! 「学歴詐称」は公職選挙法違反
【日本の金正恩】 安倍寛信 【安倍晋三の兄】
復活した電力会社の原発広告に文化人や芸能人がまたぞろ登場して原発をPR! 500万円の高額ギャラも 勝間和代 三橋貴明 佐藤優
三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている
ネットにおける言論統制は、非公然で陰湿に進んでいるようです
https://twitter.com/toka iamada/status/664017453324726272
山本太郎
先ず真のテロリズムと戦うべき!
汚染物質をバラ撒き、国民を無理心中へと巻き込む政治家、経済団体等をテロ指定、資産凍結するのが筋ではないか!
【だってお金欲しいもん~】
今朝、辺野古で新基地建設に反対するママの会メンバーに対して、
機動隊員が「お前たちには汚い血が流れている」などと暴言を吐いたそうです。
自分のやっていることを「だってお金欲しいもん~」「俺の写真を待ち受けにしろ」とも (顔写真)
https://twitter.com/MothersNoWar/status/690357793702940672
安倍首相がスタンフォード大前で「嘘つき安倍は帰れ!」と抗議を受ける
https://www.youtube.com/watch?v=HkMjwggu3ko
安倍総理、麻生副総理も経歴詐称? 海外留学の経歴が削除されていた! 「学歴詐称」は公職選挙法違反
【日本の金正恩】 安倍寛信 【安倍晋三の兄】
復活した電力会社の原発広告に文化人や芸能人がまたぞろ登場して原発をPR! 500万円の高額ギャラも 勝間和代 三橋貴明 佐藤優
三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい
これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている
ネットにおける言論統制は、非公然で陰湿に進んでいるようです
https://twitter.com/toka iamada/status/664017453324726272
山本太郎
先ず真のテロリズムと戦うべき!
汚染物質をバラ撒き、国民を無理心中へと巻き込む政治家、経済団体等をテロ指定、資産凍結するのが筋ではないか!
【だってお金欲しいもん~】
今朝、辺野古で新基地建設に反対するママの会メンバーに対して、
機動隊員が「お前たちには汚い血が流れている」などと暴言を吐いたそうです。
自分のやっていることを「だってお金欲しいもん~」「俺の写真を待ち受けにしろ」とも (顔写真)
https://twitter.com/MothersNoWar/status/690357793702940672
>>537
217 : NAME IS NULL2015/08/10(月) 22:59:49.12 ID:???
何かアドバイスお願いします。
WordPressとMySQLをIISサーバーにインストールしたのですが、
いちおう動いているのですが、何となく動きが遅いんです。
どのページを開いても読み込みに2~5秒掛かります。
これなんかが良い例。
Wordpressはカスタムフィールドを実現するためにDB設計がクソ中のクソで、
RDBMSの良いところを全部殺しちゃってるからとにかく遅い。
普通にSELECTかけたらアプリ側のロジック込みで0.15秒くらいのことが、
Wordpressだと2秒とか5秒とかかかるのが当たり前になってる。
217 : NAME IS NULL2015/08/10(月) 22:59:49.12 ID:???
何かアドバイスお願いします。
WordPressとMySQLをIISサーバーにインストールしたのですが、
いちおう動いているのですが、何となく動きが遅いんです。
どのページを開いても読み込みに2~5秒掛かります。
これなんかが良い例。
Wordpressはカスタムフィールドを実現するためにDB設計がクソ中のクソで、
RDBMSの良いところを全部殺しちゃってるからとにかく遅い。
普通にSELECTかけたらアプリ側のロジック込みで0.15秒くらいのことが、
Wordpressだと2秒とか5秒とかかかるのが当たり前になってる。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 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 ○
トップメニューへ / →のくす牧場書庫について