アーバン寄席からのSQLチューニング
クローバーフィールドの杉山です。
7/31に開催されたアーバン寄席に行ってきました。
今回は、桂紋四郎さん、林家染左さん、桂文三さんがそれぞれ１席ずつでした。
会議室を使用した落語会だったのですが、演者との距離がとても近くて表情や仕草もよく見えました。
特に、桂文三さんの「グッドジョブ」が良かったです。
始めて聴きましたが、めちゃくちゃテンションの高い死神とダークな感じの福の神の対比が面白いネタでした。
文三さんのキャラとマッチしていて、終わってみたらひとりで演じてたんやなと再確認してしまうほどでした。
三人三様で、それぞれのキャラクターにあった噺であっと言う間でした。
上から目線ですまんせんが、個性や年齢、体格なんかが上手くマッチしていたように思います。
ソフトウェア業を営む上でも、それぞれ人によって個性があります。
個人の得手不得手、好き嫌いがあって然るべきでしょう。
まぁ、本人の希望や野望が叶った仕事に取り組めるのが最高ですが、なかなか百発百中とはいかないものです。
それでも、取り掛かった仕事から何かを得るように努力するのが本筋だと思います。
そんなこんなでしょうもない話しですが、SQL書くんやったら「ちょっと考えてよ」と思う事案がありました。
一人のプログラマが「この処理が遅いんですがどないしたらええですか?」と聞いてこられました。
WEBアプリケーションで作成した情報を検索する処理で、検索を実行するとタイムアウトしてしまうとのことでした。
私「んで、どこが遅いか確認したん?」
プ「まだです。」
私「・・・。ほな、クライアントから処理を受信して、データベースの抽出の前後、サービス側の処理の終わり。クライアント側の表示時間くらいを実測してよ」
プ「わかりました。で、どうしたらできますか?」
私「・・・それぞれログに出力したらええやん。クライアントとサーバの時刻同期できてるか確認してな」
プ「わかりました」
翌日のこと。
プ「データベースの処理が遅いみたいです。」
私「ほな、実行したSQLとデータベースの実行計画を取得したらええやん」
プ「実行計画ってどうやったら取得できるんですか?」
私「(使用しているデータベース管理システムはOracleなので)DBMS_XPLAN.DISPLAY_CURSORの使い方調べてごらん」
プ「わかりました」
しばらくして。
プ「取れました。」
私「え?、自分で確認せーへんの」
プ「見方がわかりません」
私「・・・。」
一緒にお勉強しました。(※ちなみに弊社のプログラマではありません。)
本人が作ったものではなかったので責めても仕方ないのですが、ツライ。
んで、SQL自体も確認しましたが、ダメ過ぎました。
誰やねん、こんな糞コード書いたん。(※ちなみに弊社のプログラマではありません。)
知っている構文を駆使して、「とりあえず要件を満たしました!パフォーマンスとか知らんけど!!」って感じでした。
と、言う訳でSQLの実行計画は単体テストの時点で取得してください。
昔と違って簡単です。
あちこちで記述されていますが、最低限のSQLを書く際のルールは守りましょう。
・テーブルは結合する前に絞り込め
・抽出条件で索引が有効な効くように項目を指定する。
・where句の左辺を関数で編集しない(索引が効かなくなる)
・where句のIS NULL, IS NOT NULLを使用しない。(索引が効かなくなる)
・where句でin, or, !=, <>を使用しない。
・where句で暗黙の型変換をさせない。
(まだまたあるけど飽きてきた。)
そして、使用しているデータベース管理システムがOracleであれば、使用しているバージョンの「パフォーマンス・チューニング・ガイド」を読みましょう。
スマホでゲームをする時間を少し使えば読めます。
自分のレベルを上げてください。(日頃、我が子に言うてる内容そのまま)
その他のデータベース管理システムでも同様の情報があると思います。
ただし、テーブルの設計自体が腐っていると、どうにもしようがない場合があります。
テーブルをひっくり返さず、上司に相談してください。
お後がよろしいようで。