Tag: MySQL

１年と言っても必ずしも365日とはならないです。４年に１回のうるう年は366日となります。さて、この１年というあいまいな定義をデータベースのSQLあるいはプログラムで計算するとどういう結果になるかという話です。

過去の記事でも紹介されていますが、親子（or 1対多）関係にあるModelにおいて、「１つ以上子を持つ親」などの条件で絞り込む際にhas()は便利です。 しかし、has()を使わずともjoinSub()でサブクエリを指定して同じ条件で絞り込む事もできそうです。 どちらを使うのがベターなのか？気になったので調べてみました。

これまた、データベースの話ですが、長期でアクティブに管理しているプロジェクトでは必ず登場してくる作業です。

前回に複数のSQL文の結果をうまく１つのSQL文にまとめる話をしました。今回もその続きです。

以前に「調査クエリー」と称して、ウェブ画面でSQL文を入力して実行できるツールを作成しました。それ以来いろいろなSQL文を作成することになったのですが、これはできないだろうというのが最近可能と判って、大喜びです。

whereIn()はLaravelではEloquentやQuery Builderで良く使われます。特にwith()メソッドでは自動的に。今までこのクエリが返すレコードの順番はたいして気にしていなかったのですが、これはどうしたものか、という状況にぶち当たりました。

先日に作成した生SQL文の実行クエリの機能を使用しています。重宝していますが、SQL文が複雑になってくると括弧が多くなってきたりして、わかりづらくなってきます。PHPのコードやHTMLソースと同じようなもので、SQL文の整形の機能が必要です。探したらまさにそのパッケージありました。

Laravelのようなフレームワークが登場する以前は、誰しもSQL文を作成してmysqli_query()のような関数に引数として渡して実行していたものです。QueryBuilderやEloquentのORMなぞ聞いたこともない時代でした。その過去に戻るわけではないですが、それと同じこと、つまりSQL文を管理画面に直接入力して実行できないかと考えた次第です。

以前投稿したbulk insertで大量のデータをDBに登録するの記事では10万レコードの挿入をbulk insertで行い、通常のinsertと比べてどれだけ速くなるのか検証しました。結果は一目瞭然で、大量のレコードをDBに登録する際には強力な武器になる事が分かりました。 しかし、前回のコードを実際の運用で使うには１つ問題があります。それはbulk insertの途中でエラーが発生した場合、DBに中途半端にレコードが残ってしまうという問題です。今回はこの問題を解決するために、前回のコードをtransactionに入れ、エラーが発生した際にロールバックされるように改修します。そして、transaction処理にする事でパフォーマンスにどのような影響があるか検証してみます。

毎日走らせているcronのジョブの１つが、なかなか時間が掛かるのでどうにか改善できないかと悩んでいました。DBへデータを挿入する箇所で時間が掛かっており、コードを確認するとforループで１レコードずつinsert処理を行っていました。bulk insertするように改修したところ、劇的に処理時間が短くなりました。今回はそんな妙薬、bulk insertについてです。