CONVERT_TZ関数を安易にWHERE句で使っていませんか？
データベース運用において、異なるタイムゾーンを持つ拠点間でデータを集計する際、CONVERT_TZ関数は非常に便利です。しかし、この関数をWHERE句の条件式に組み込む際、多くのエンジニアが「インデックスの無効化」という大きな落とし穴に直面します。
例えば、WHERE句で CONVERT_TZ(created_at, ‘UTC’, ‘Asia/Tokyo’) >= ‘2023-10-01 00:00:00’ と記述すると、MySQLはテーブルの全行に対して関数を実行してから比較を行います。これはフルスキャンを引き起こし、テーブルのデータ量が増えるほどクエリの応答時間は劇的に悪化します。実務では、計算後の値を条件にするのではなく、定数側を変換して比較する「逆算のロジック」を徹底すべきです。
サマータイム対応と意図せぬ挙動の回避
CONVERT_TZ関数の興味深い点は、タイムゾーンの定義テーブル（mysql.time_zone_nameなど）を参照していることです。ここでの注意点は、OSのタイムゾーン設定とデータベース内のタイムゾーン定義が乖離しているケースです。
過去に、サマータイムが切り替わるタイミングで、CONVERT_TZが期待した値を返さず、集計結果に1時間のズレが生じる障害を経験しました。この原因は、MySQLのタイムゾーンテーブルが更新されていなかったことにあります。クラウド環境（RDSなど）を利用している場合でも、デフォルトではタイムゾーンデータが空のケースがあるため、運用の初期段階で必ず mysql_tzinfo_to_sql ツールを用いて、OSのゾーン情報を流し込んでおくことがトラブル防止の鉄則です。
実務における推奨設計：アプリ側かDB側か
では、どこでタイムゾーン変換を行うべきでしょうか。私の結論は、「表示用のクエリであればDB側で処理しても良いが、大規模なバッチ処理や検索条件には決して組み込まない」というものです。
特に、アプリケーション側でUTC統一管理をしているシステムであれば、DB側で無理に変換するよりも、アプリケーションのORM層で処理を行う方が、DBの負荷を平準化しやすく、保守性も高まります。もしDB側で行う場合でも、計算列（Generated Column）を作成し、その列にインデックスを貼ることで、読み取り性能を犠牲にせずに柔軟な検索を実現することが可能です。
まとめ：技術の引き出しを増やす
CONVERT_TZは強力なツールですが、魔法の杖ではありません。関数の動作原理である「計算コスト」と「タイムゾーンデータの依存性」を理解し、クエリ実行計画（EXPLAIN）を常に確認する癖をつけてください。小規模な開発環境では顕在化しない問題こそが、大規模な本番環境でシステムを停止させる引き金になります。DBAとして、常に「この関数は本当にインデックスを活用できるか？」という問いを自分に投げかけ続けることが、安定運用への最短ルートです。
コメント