タグ

sqlに関するfrkw2004のブックマーク (9)

  • Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ

    この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ

    Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
    frkw2004
    frkw2004 2022/12/30
    インデックスでselect処理が速くなる、って勉強した時に、その代わりinsertが遅くなる、って聞いてなかった? ORACLEもsqlサーバーも大量インサートで一時的にインデックスを無効にする手法は覚えておいた方がいい。
  • SQLわかんねーーーーーーーー!!!!!!

    学生時代に独学でVBAやってたのが零細企業でなぜか評価されてDB管理をやらされかけてるけど SQLマジでわかんねーーーーーーーーーーー!!! なんだこれーーーーーーーーーーーーー!! ああああああああああああああ!!!! わかんねーーーーーー!!!!

    SQLわかんねーーーーーーーー!!!!!!
    frkw2004
    frkw2004 2022/10/07
    千行を超えるSQLを使ったことあるけど、それはほぼ同じ副問い合わせを条件別にUNIONするようなやつだった。とりあえずLeft JoinとRight Joinを混合するのはやめろ。
  • SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita

    2020/9/30追記 記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか? 今回は、そんな方々にこそ

    SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
    frkw2004
    frkw2004 2020/09/22
    window関数はどこになるのかな? SQL書くとき、Select * FROM と書いて主テーブルとJOIN句書いていくなぁ。ところでJOIN句の結合条件書くときの順番が A JOIN B ON A.FLD=B.FLDよりA JOIN B ON B.FLD=A.FLD の方が好き。
  • 分析用SQLを書くときの思考回路について|だみ〜

    稿では、分析用のSQLを書くときに則っている思考回路について述べて行こうと思います。 この言語化はあまりきちんとされている印象が無いので、自分がそこそこ初めての言語化だと思って頑張ってやってみようと思います。 言い換えれば、私はこういう思考回路でSQLを書きますが、みなさんどうですか、という話でもあります。 あとは、前提として、現代的な分析用の分散エンジンにSQLを投げるときを考えています。それ以外の場合はむしろ非効率になることも多いかもしれません。 0.問題設定今回の題材は、待てばチケットが復活する無料単話があり、有料で無料単話も買える、そして単行購買もできる、というマンガサービスとしましょう。 このサービスの企画者から、チケットで無料単話だけ読むユーザが、もし有料で単話を買うようになったらどれくらい売上が伸びるのか教えてほしい、という依頼が来たとします。 これを仮説形式に直すと、

    分析用SQLを書くときの思考回路について|だみ〜
    frkw2004
    frkw2004 2020/08/20
    leftとrightが同居しててカッコも付けていない、数10kのSQLをメンテナンスしたのはきつかった。
  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!
    frkw2004
    frkw2004 2017/06/26
    複合インデクスはsqlに書いた列順に関わらずオプティマイザが適切に直してくれなかったっけ? 確認しないと。
  • 俺もカンマ先頭に置く派だわ INの中というか、主にSELECTの取得項目を並べた..

    俺もカンマ先頭に置く派だわ INの中というか、主にSELECTの取得項目を並べたりFROMのテーブル名を並べるトキな。 こんなん。 SELECT COLUMN_A , COLUMN_B , COLUMN_C FROM TABLE WHERE COLUMN = 'abcde'; ただ「カンマを先頭に置く書き方は滅ぶべきだよ」派の方が圧倒的多数派のはずで その理由を知りたいんだけど見たトキねえわ。

    俺もカンマ先頭に置く派だわ INの中というか、主にSELECTの取得項目を並べた..
    frkw2004
    frkw2004 2014/11/10
    1つのSQLで10KB越すのとか結構あるので読みやすさは大事。カンマから行を始めるのはメンテナンスのしやすさから。テストでは最後にダミー列を追加しとけばいい、のではあるけど。
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
    frkw2004
    frkw2004 2011/07/14
    サロゲートキーのデメリットにも言及しないと。ナチュラルキーにユニーク制約をつけないテーブルのせいでメンテナンスできないよ。あっちゃいけないデータ重複とかさ。
  • 地獄のようによくわかるSQLテーブル結合 - こせきの技術日記

    テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOINJOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。

    地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
    frkw2004
    frkw2004 2010/09/16
    二つのテーブルなら難しくない。3つ以上のテーブルになると結合順の問題も出てくる。5つ以上のテーブルがLeft,Right,Cross入り混じって結合されているSQLを見たときは「何考えてんだ、コイツ?」と思いました。
  • SQLインジェクションとは何か?その正体とクラッキング対策。

    世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン

    SQLインジェクションとは何か?その正体とクラッキング対策。
    frkw2004
    frkw2004 2010/01/14
    でもさぁ、インジェクションを成功させるSQL作成例は前提の説明が足りないよね。ユーザー入力テキストの文字数制限がないとか。ユーザーIDとパスワード入力用のテキストに必要文字数以上の入力はさせないよね。
  • 1