日付カラム、インデックスないない問題

とあるフォローイング風景

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を気にしてるムードがほとんどない印象で。

まだ考え中の案件

と思ったりするのですが、みなさんどうなんでしょうね？

これから色んな人にヒアリングして行きたいなと思っています。

(そのためにこのブログを書いたと言っても過言ではない^^)