2038年問題という問題があります。これはUNIX系システムで使われている32ビットの時刻表現(1970年1月1日からの秒数)が2038年1月19日3時14分7秒に限界を超えることで誤った結果になる問題です。これにより一部のシステムやアプリケーションで異常動作やクラッシュが発生する可能性があります。n年後のデータを扱うするシステムなどで既に問題が起きている場合もあります。MySQLのtimestamp型は日時を扱う型で、これも2038年問題の対象です。この記事ではあるデータベース内にあるtimestamp型のカラムを見つける方法を紹介します。
MySQLではinformation_schemaに各テーブルの情報が入っています。information_schema内のデータを適切に引き出すことでtimestamp型のカラムを探せます。実際のSQLが次です。
# どのスキーマのどのテーブルのどのカラムが timestamp 型なのかわかるようにカラムを選択
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, DATA_TYPE
# カラムについての情報が入っている COLUMNS テーブルを参照する
FROM INFORMATION_SCHEMA.COLUMNS
# timestamp 型のカラムを抽出する
WHERE DATA_TYPE = 'timestamp'
  # MySQL組み込みのテーブルは無視する(その内MySQLのバージョンも更新しないとMySQL本体が2038年問題に引っ掛かりそうです)
  AND TABLE_SCHEMA NOT IN ('mysql', 'performance_schema', 'information_schema', 'sys');
# 結果例
TABLE_SCHEMA,TABLE_NAME,COLUMN_NAME,DATA_TYPE
test_db,personal_access_tokens,created_at,timestamp
test_db,personal_access_tokens,expires_at,timestamp
test_db,personal_access_tokens,last_used_at,timestamp
test_db,personal_access_tokens,updated_at,timestamp
tmp,personal_access_tokens,created_at,timestamp
tmp,personal_access_tokens,expires_at,timestamp
tmp,personal_access_tokens,last_used_at,timestamp
tmp,personal_access_tokens,updated_at,timestamp
tmp,queue_monitor,finished_at,timestamp
tmp,queue_monitor,started_at,timestamp
これで見つけたtimestamp型をdatetime型に変えるなどして対処すれば、それで2038年問題を解決できます。
 
					         
               
                       
						
						 
                