WWW無人速報

速くなる？

日付カラムにインデックス貼ると検索速度上がるよ

>>11 でも日付ってカーディナリティ低くない？ インデックス効果薄そう

>>17 確かに日付の選択性は低いけど 範囲検索するならインデックス有効だと思う

>>22 例えば「最近1ヶ月分のデータ」みたいな検索とかね

>>26 そういう範囲検索の場合 日付インデックスあると爆速になるよな

>>35 ただイコール検索だとインデックス要らないかも

created_atカラムとかによく使うから とりあえずインデックス貼っとくのがセオリーだと思ってた

インデックス貼りすぎると更新が遅くなるデメリットもあるから 適材適所だね

>>50 日付カラムのデータ型はdatetimeとtimestampどっちがいいんだろ？

>>53 MySQLだとtimestampのが便利な気がする タイムゾーン変換できるし

>>56 でもtimestampって2038年問題あるんでしょ？

>>56 timestampは2038年以降の時間を保持できないから 使わない方がいいぞ

日付カラムを複合インデックスの一部にするのはアリ？

>>81 アリだと思う ユーザーIDと組み合わせて「あるユーザーの直近データ」を検索したりするし

>>84 複合インデックスの順番は選択性高い方から並べるのが鉄則だよね

>>93 そうそう だからuser_idとcreated_atの複合インデックスならuser_id先頭にするべき

>>100 INDEXヒントでインデックス強制したりする？

>>105 正直あんまり使ったことない

SQLite使ってるんだけど 日付のインデックスって大丈夫？

>>113 SQLiteも日付にインデックス使えるよ datetimeとかdate型で

部分インデックスって使える？ 例えば「今年のデータ」だけインデックス

>>122 部分インデックスはMySQLにはないんだよね

>>128 マジか PostgreSQLとかOracleにはあるのに

>>131 MySQLにも欲しい機能だよね

日付のパーティショニングはどうよ

>>141 パーティショニングいいよね 年月でパーティション切ると捗る

>>142 確かにパーティション使うとデータ絞り込みが楽だわ

>>144 ただパーティションの管理めんどいのが玉にキズ

>>146 一理ある

ソートにも効果あるの？

>>158 ソート済みの状態になってるから 明示的なソートが不要で速くなるよ

日付カラムを複数持つテーブルのインデックスどうしてる？

>>174 created_atとupdated_atによくあるパターンだよね

>>180 そういう時は両方カラムにインデックス張ってる アプリケーション要件次第だけど

>>189 updated_atはあんまり検索しない気がするからcreated_atだけでもいいかも

>>191 たしかに

MySQLのクエリログ見ると意外と日付の検索多いんだよね

>>205 そういう時にインデックス役立つんだろうね