タグ

performanceとmysqlに関するlunasteraのブックマーク (4)

  • 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時間以内にする - エムスリーテックブログ
  • MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub

    こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした!障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー

    MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
  • ISUCON Cheat Sheet · GitHub

    00_timeline.md 集合 9:00にオフィス(Sticky Fingers) 料品は事前に用意しておく。べ過ぎない。胃に負担をかけないようにする。 運営の櫛井さんからのメールに従って、サポートチャットと予選ポータルサイトにログインする。 ISUCON6 予選レギュレーション メール: ISUCON6 オンライン予選 当日の流れについて 今までに寄せられた質問についてまとめたFAQ ISUCON6 予選 9月18日(日) 参加者サポート用チャット ISUCON6 予選ポータルサイト http://isucon6q.songmu.org/ 10:00〜11:00 最初の1時間 11:00〜12:00 まず基的なことをやる。 12:00〜17:00 この辺りからRedis移行に取り組む。 17:00〜18:00 最後の1時間 01_first_hour.md Why 課題の理解、

    ISUCON Cheat Sheet · GitHub
  • 複合インデックスの正しい列の順序

    データベースは、プライマリキーに対して自動的にインデックスを作成しますが、キーが複数の列からなる時は、さらに手動で調整をする 余地があります。この場合、データベースはプライマリキーの全ての列にいわゆる 連結インデックス(あるいはマルチカラム インデックス、複合インデックス)を作成します。 複合インデックスの列の順番は、インデックスの使い勝手に大きな影響を及ぼすので、注意して決定する必要があります。 例として、企業が合併した場合を考えてみましょう。他の会社の社員が 加わったので、EMPLOYEESテーブルが10倍の大きさになったと しましょう。ここで問題が発生します。EMPLOYEE_IDが、 それぞれの会社で一意になっていなかったのです。子会社IDのような追加の識別子で、プライマリキーを拡張する必要があります。このため、プライマリ キーは、以前からのEMPLOYEE_IDに加えて、一意性を

    複合インデックスの正しい列の順序
  • 1