登録日時・更新日時を記録する場合、TIMESTAMP型かDATETIME型か、それとも… - [Mi]みたいなもの
経験値がないから、どういう型を使えばいいのかでとってもとっても迷うんですよねぇ……（後々影響しまくるし）。 今回は、登録日時・更新日時の場合です。 TIMESTAMP型かDATETIME型の比較 サポート範囲が違う（その結果、消費バイト数が違う）らしい。 のみならず、「コードが更新された時に自動的に現在時刻でTIMESTAMP型のカラムを更新できる」らしい（おお？ しかしcurrent_timestampは1カラムだけ。 むー。 2037年なんてまだまだ先だからいいとも言えるけど、素直にDATETIME型を使うのがよさそう。 自動的にってのは楽でよさそうだけど、想定外の動作になりそうで怖いよ。 ▽TIMESTAMP型とDATETIME型（suusukeの日記） http://d.hatena.ne.jp/suusuke/20081119/1227094456 ▽MySQLでのTIMESTA
![登録日時・更新日時を記録する場合、TIMESTAMP型かDATETIME型か、それとも… - [Mi]みたいなもの](https://cdn-ak-scissors.b.st-hatena.com/image/square/3107836cc236c83aae34417d3981aba718848895/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127156572702%2F17680117127156591120%2F1558483477)
MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
