タグ

ブックマーク / atsuizo.hatenadiary.jp (6)

  • SELECT文をタイムアウト強制終了させる「MAX_EXECUTION_TIME」使ってる? - なからなLife

    この記事はMySQL Casual Advent Calendar 2017 - Qiitaの9日目のエントリとなります。 実行が長引いたSELECT文を強制終了させるヤーツ MySQL5.6まで、正常に処理が進んでいて遅いSELECTをタイムアウトさせるシステム変数はありませんでした。 正常に処理が進んでいない時のパラメータだと lock_wait_timeout:メタデータロック取得待ち innodb_lock_wait_timeout:レコードロック取得待ち がありました。 正常に処理が進んでいるけど、厳密には「処理中」ではないときに効くパラメータだと net_read_timeout:クライアントからサーバに送り込んだデータの読み込み時間 net_write_timeout:サーバからクライアントへのデータの書き戻し時間 がありました。 他にも、アイドルタイムアウト系で inter

    SELECT文をタイムアウト強制終了させる「MAX_EXECUTION_TIME」使ってる? - なからなLife
  • MySQLのGLOBAL_STATUSとGLOBAL_VARIABLES - なからなLife

    今更MySQL5.7を扱うにあたって MySQL5.6とMySQL5.7のパラメータ差分をあらためて見直してたら、「show_compatibility_56」という、プロダクトのアーキ移行期間にありがちな「いかにも」な名前のパラメータがありまして。 これは何? 「SHOW [GLOBAL] STATUS」や「SHOW [GLOBAL] VARIABLES」という、とてもお世話になるコマンドがあり、その実、テーブルに格納されている値を表示していたわけで、テーブル*1があることから、SELECT文を使うことでSHOWコマンドよりもより柔軟な条件式などを使って参照ができたわけです。 そんなテーブルたち、MySQL5.6まではInformation_Schemaにあったのが、MySQL 5.7からはPerformance_schemaに移動するぞ、ってドキュメントに書いてあります。 その説明のた

    MySQLのGLOBAL_STATUSとGLOBAL_VARIABLES - なからなLife
  • SQLを繰り返し実行したら段階的に応答速度が上がった話 - なからなLife

    MySQL Casual Advent Calendar 2016 - Qiitaの6日目の記事です。 AdventCalendar自体初参加でドキドキ、してたら、成り行きで2日連続。 コレ用のきれいなエビデンス取れるような環境要していなかったので、普段より荒っぽいですが、Casualな感じで失礼します。 大きなテーブルを繰り返しSELECTしてたら、挙動が変わったんですよ。 バッファに載っているなら載っているで早いだろうし、載っていいなら最初ガッツリ遅くて、次からグイっと速くなるだろうと思っていたんですよ。 バッファに載りきらないなら、何回やっても遅いだろうと思っていたんですよ。 で、ちょいと計測的なことをやってた関係で、同じSQLを何度か叩いて平均、中央を見ようと思っていたんです。 そしたら、 45.71秒、44.90秒、24.44秒、13.32秒、13.12秒・・・ と、段階的に応答

    SQLを繰り返し実行したら段階的に応答速度が上がった話 - なからなLife
  • MySQLのトランザクション制御がキモい話 - なからなLife

    MySQL Casual Advent Calendar 2016 - Qiitaの5日目の記事です。 AdventCalendar自体初参加でドキドキ。 トランザクションの開始は、BEGINしたときじゃない! MySQLでは、BEGIN(START TRANSACTION。長いので、以下、特筆すべき場合以外は「BEGIN」で)を宣言しても、内部的にはまだトランザクションを開始してません。 SQLを投げたタイミングで、トランザクション開始になります。 このとき、更新のない、FOR UPDATEもないSELECT文でも、トランザクションが開始されます。 なにそれきもい。 「AutoCommit=ON/OFF」による違い AutoCommit=ONのとき トランザクションはSQLを発行するたびにBEGIN/COMMITで完了し、ロールバックできません。 複数SQLを束ねて1つのトランザクション

    MySQLのトランザクション制御がキモい話 - なからなLife
  • ORDER BYで、単純な昇順降順「以外」で並べる! - なからなLife

    いやー、知らないって怖いね。 なんだこのキモいSQLは、って思ってしまったけど、調べているウチに、これちゃんとSQL構文に則ってる!こちらが間違ってた!って事がわかっていきました。 あえて、知らなかった所から勢いで書いていたのを、そのままにしてみました。 キモいSQLコードを偶然見つけた SQLにおけるORDER BYって、その後にカラム(およびそのエイリアス)を並べてソート順として使用するわけですが、MySQL案件のお仕事の中で偶然こんなものを見つけて、絵に描いたような二度見リアクションしました。 SELECT * FROM tbl ORDER BY id = 23; -- (1) SELECT * FROM tbl ORDER BY FIELD( id, 23, 234, 543, 23 ); -- (2)こうした、「ORDER BYに、あたかもWHERE句で絞り込む条件指定のような使

    ORDER BYで、単純な昇順降順「以外」で並べる! - なからなLife
  • ネットワークトラフィックという、古くて新しい問題。 - なからなLife

    クラウドサービスバンザイ! ハードウェアの置き場要らないし、資産管理もほとんどいらないし。 負荷急増にもすぐ対応できるし、サーバー納品待ちとかないし。 「このロット、ハズレだなー」、とかないし。 Saasレベルののもに至っては、ほんとに「1ライセンス月いくら」しか気にしなくて良いからなー。 いいよのなかになったもんだー。 情報システムに資金を回しにくい非IT系ベンチャーにとっても、非常に嬉しい時代になりました。 そして、ふと沸き起こるトラブル 情シスがサーバーを手放して、Iaasを活用した。 情シスが開発を手放して、Paas・Saasに乗っかった。 そして残ったのは、ほんとに低層の「ネットワーク」の部分。 情シスが呼び出されるトラブルの多くが「ネットワークが繋がらない、遅い」という問題に。 そんなに複雑な構成を組んでいない、設定すべき情報もほとんどないネットワークで、トラブルが起こります。

    ネットワークトラフィックという、古くて新しい問題。 - なからなLife
  • 1