MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
Treasure Dataに入社しました - かみぽわーる
近況などをブログに書いたことはなかったんですが、4月からTreasure Dataで働くことになりました。 3月に新しい仕事を探してたタイミングでちょうど声をかけてもらって、他に誘ってくれてるところもあっていろいろ考えたんですけど、今まで自分がやってたWeb屋さんとは結構ちがう専門的なプロダクトが面白そうだったこと、話してみてエンジニアリング上の解決したい課題についてすごく具体的にいろいろ話してくれたので、畑違いな気もするけどやれることは結構ありそうだなとイメージできたので入社することにしました。 あとは声をかけてくれるのが2週間遅かったら他のところに決めちゃってたので、お互いのタイミングが合ってたことで自分が想像していなかった選択肢が生まれたことにも面白さを感じて、まあこれも自分の中のひとつのチャレンジだと思って返事をしたという感じです。 HadoopもFluentdもよく分からんしSl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
