とあるフォローイング風景
seaさん「検索SQL速くしたくて悩んでるんですけど」
jflute「おお」
seaさん「これをどうにか」
jflute「この日付カラムにINDEX貼ればおしまいのような」
seaさん「INDEXを貼らずに速くできないかなと」
jflute「なんで？」
(小声でたどたどしく...)
seaさん「夜間メンテとか大げさなことになっちゃって...」
jflute「むー」
【追記: 2025/01/09】
補足: テーブルのレコード数が膨大でINDEX貼るとテーブルロックが掛かっちゃってサービスストップになってしまうため、もしくて、おいそれと貼ることができないという状況 (夜間メンテすらできないというケースも)
とあるフォローイング風景２
landさん「検索SQL速くしたくて悩んでるんですけど」
jflute「おお」
landさん「これをどうにか」
jflute「この日時カラムにINDEX貼ればおしまいのような」
landさん「INDEXを貼らずに速くできないかなと」
jflute「なんで？」
(小声でたどたどしく...)
landさん「DB変更は先輩にお願いしないといけなくて...」
jflute「むー」
jflute（まあ言いづらいんだろうね...）
いやいやいや？ or しょうがない？
人生でまあまあな回数あるんですよね苦笑
まあ、seaさん、landさんの仕事推進スキルがまだまだって面もあるし...
そういうのが拾い上げられないチームのムード面もあるわけですが...
あえて視野を狭く考えると、気持ちはわからなくもないってのもあって。
【追記】
実際、どうしたかというと...
「そういう気にせず、システムとしてあるべき姿は？ってのを優先して行動できるようになりましょう」ってな話は必ずした上で、後はその方や開発プロジェクトとの関係性次第でケースバイケースですかね。
(もちろん本当にINDEX貼るのが最適かどうか？の再検討も含めること前提で)
後からINDEXはおいそれと貼れない
事業会社ならではなんでしょうか？
最初のまだサービスが小さい時、日付/日時カラムにインデックスがなくても全然問題なくSQLは戻ってきます。
でも、サービスが大きくなってデータ量が増えた頃にインデックスを貼りたくなっても、インデックスを貼る処理自体に時間が掛かってテーブルロックの時間が長くなってサービスが止まってしまうので貼れないって状況も。(DBMSに依るかもですが)
確かにこれはジレンマではあります。
日付/日時の検索が後に来る
事業会社ならではなんでしょうか？
最初のまだサービスが小さい時、日付/日時カラムを作っても、検索をする人がまだいなかったりします。
でも、作っておかないと後から欲しくなっても取得できないので、あらかじめカラム作って保存しておこうってなります。(作らないと情報ロスになってしまうので)
それはそれで、わりと当たるのです。閲覧に限らず絞り込み条件で使う場面も大いにやって来ます。(というか日付/日時カラムの目的ってほとんど絞り込み条件？)
なので作っておいて良かった良かった...は良いんですけど、INDEX貼ってなくてさっきのフォローイング風景のようになるのですね。
もはやとりあえず？
たぶん、カラムを作った人は、必要になったときに貼る方が良いというつもりだったのでしょう。(何も考えずに作ったってケースもあるかもですが)
一方で、フォローイング風景のようなことも起きます。
もはや日付/日時はとりあえずINDEX貼っておけば？
って思ってしまったりします。
(共通カラムのメタ的な日時は置いておいて、業務的な日付/日時カラムに)
検索が遅い方がつらい？
もちろんシステムの特性にも寄るかもしれません。
o DBのサイズをすごく気にしないといけないので、INDEXも無駄に貼りたくない
o 検索よりも更新のスピードの方が重要なので、INDEXも無駄に貼りたくない
という明確な事情があればまた別ですが...
jfluteが関わってる現場で言うと、事業会社で検索の方が圧倒的に重要なシステムが多い印象で。(更新が遅くて問題になるのはほとんど聞かない)
特にMySQLなんかは、FKカラムに自動的にINDEX貼られるくらいで、そもそも無駄なINDEXを気にしてるムードがほとんどない印象で。
