Bagaimana untuk menyelesaikan masalah cap waktu 2038 Mysql

Cap masa merujuk kepada jumlah saat dari 00:00:00 pada 1 Januari 1970, Waktu Greenwich (08:00:00 pada 1 Januari 1970, waktu Beijing) hingga sekarang.
Pelbagai versi MySQL digunakan dalam persekitaran pengeluaran, termasuk tiga versi utama MySQL 5.5/5.6/5.7 dan N versi minor Disebabkan oleh keserasian MySQL yang lemah, SQL yang sama berkelakuan berbeza dalam versi yang berbeza, cap waktu jenis data akan diperkenalkan secara terperinci dari beberapa aspek di bawah.

Akses data cap masa

Dalam tiga versi utama MySQL di atas, julat nilai jenis cap masa lalai (Timestamp) ialah ’1970-01-01 00:00:01&rsquo ; hingga ’2038-01-19 03:14:07&rsquo UTC, data adalah tepat ke tahap kedua ini mengandungi kira-kira 2.2 bilion nilai, jadi jenis INT 4-bait digunakan secara dalaman dalam MySQL untuk menyimpan cap waktu. . Data:
1 Apabila menyimpan data cap waktu, mula-mula tukar masa zon waktu tempatan kepada waktu zon waktu UTC, kemudian tukar masa zon waktu UTC kepada milisaat dalam format INT (menggunakan fungsi UNIX_TIMESTAMP), dan kemudian simpannya dalam pangkalan data.
2. Apabila membaca data cap masa, mula-mula tukar nilai milisaat dalam format INT kepada masa zon waktu UTC (menggunakan fungsi FROM_UNIXTIME), kemudian tukarkannya kepada waktu zon waktu setempat, dan akhirnya kembalikan kepada klien.

Dalam MySQL 5.6.4 dan versi yang lebih baru, data jenis cap waktu boleh disimpan dengan ketepatan tertinggi dalam mikrosaat (sepersejuta saat Jenis data ditakrifkan sebagai cap masa(N), dan julat nilai N ialah 0- 6. Lalai ialah 0. Jika ia perlu tepat kepada milisaat, tetapkannya kepada Cap Masa(3 Jika ia perlu tepat kepada mikrosaat, tetapkannya kepada cap masa(6). ketepatan ialah peningkatan dalam ruang storan dalamannya, tetapi ia masih tidak menukar julat nilai minimum dan maksimum jenis cap waktu.

Takrif medan setem masa

Takrifan medan setem masa terutamanya mempengaruhi dua jenis operasi:

• Apabila memasukkan rekod, medan cap masa mengandungi STAMP MASA_KASA LALAI , seperti Jika data masa tertentu tidak dinyatakan semasa memasukkan rekod, nilai medan cap masa ditetapkan kepada masa semasa

• Apabila rekod dikemas kini, medan cap masa mengandungi ON UPDATE CURRENT_TIMESTAMP Jika masa tertentu tidak dinyatakan semasa mengemas kini rekod Untuk data masa, tetapkan nilai medan cap masa kepada masa semasa

PS1: CURRENT_TIMESTAMP bermaksud menggunakan fungsi CURRENT_TIMESTAMP() untuk mendapatkan masa semasa, serupa dengan fungsi NOW()

Mengikut dua jenis operasi di atas, lajur cap masa boleh mempunyai empat definisi gabungan, yang maksudnya ialah:

• Apabila medan ditakrifkan sebagai cap masa, ini bermakna medan itu tidak disisipkan atau dikemas kini. Ia akan ditetapkan secara automatik kepada masa semasa.

• Apabila medan ditakrifkan sebagai cap waktu DEFAULT CURRENT_TIMESTAMP, ini bermakna medan hanya diberikan masa semasa apabila dimasukkan dan tiada nilai ditentukan, dan tidak diubah suai apabila dikemas kini dan tiada nilai dinyatakan.

• Apabila medan ditakrifkan sebagai cap waktu PADA KEMASKINI CURRENT_TIMESTAMP, ini bermakna medan itu diberikan nilai "0000-00-00 00:00:00" apabila ia dimasukkan dan tidak nilai ditentukan Apabila ia dikemas kini dan Jika tiada nilai dinyatakan, ia mengemas kini kepada masa semasa.

• Apabila medan ditakrifkan sebagai cap masa DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, yang bermaksud bahawa medan tidak menyatakan nilai semasa memasukkan atau mengemas kini, ia akan diberikan masa semasa.

PS1: Akan terdapat perbezaan antara pernyataan penciptaan jadual yang dilaksanakan dalam MySQL dan pernyataan penciptaan jadual akhir Adalah disyorkan untuk menggunakan SHOW CREATE TABLE TB_XXX untuk mendapatkan pernyataan penciptaan jadual jadual yang dibuat.

Perbezaan dalam penggunaan medan cap masa dalam pelbagai versi MySQL

• Dalam MySQL 5.5 dan versi terdahulu, hanya satu medan cap masa boleh ditakrifkan sebagai STAMP_MASA MASA DEFUALT atau ON UPDATE CURRENT_TIMESTAMP , tetapi sekatan ini telah dibatalkan dalam versi MySQL 5.6 dan MySQL 5.7;

• Dalam versi MySQL 5.6, nilai lalai parameter explicit_defaults_for_timestamp ialah 1, dalam versi MySQL 5.7, nilai lalai parameter explicit_defaults_for_timestamp ialah 0 ;

• Dalam versi MySQL 5.5 dan MySQL 5.7, jenis cap masa lalai kepada NOT NULL, dan dalam versi MySQL 5.6, jenis cap masa lalai kepada NULL;

Apabila pernyataan penciptaan jadual ditetapkan kepada cap waktu c1,

• bersamaan dengan cap waktu c1 BUKAN NULL STAMP MASA LAILA PADA KEMASKINI CURRENT_TIMESTAMP;

  dalam MySQL 5.5
bersamaan dengan c1 timestamp null lalai null dalam mysql 5.6;

• >Apabila c1 timestamp lalai 0 digunakan dalam penyataan penciptaan jadual,

• bersamaan dengan c1 timestamp NOT NULL DEFAULT dalam MySQL 5.5 ‘0000-00-00 00:00: 00’ ;

bersamaan dengan cap waktu c1 NULL DEFAULT dalam MySQL 5.6 ‘0000-00-00 00:00:00’;

• Setara to c1 timestamp NOT NULL DEFAULT ‘0000-00-00 00:00:00’; dalam MySQL 5.7 Dijejaskan oleh nilai lalai parameter explicit_defaults_for_timestamp.
• PS2: Apabila nilai lalai lajur cap masa ialah ’0000-00-00 00:00:00’, menggunakan nilai lalai "tidak dalam julat nilai cap masa" tidak akan menjana amaran. .

  Pengecualian disebabkan oleh jenis cap masa

  Apabila parameter MySQL time_zone=system, menanya medan cap masa akan memanggil zon waktu sistem untuk penukaran zon waktu Walau bagaimanapun, disebabkan masalah kunci global dalam zon waktu sistem , dalam akses data volum besar berbilang serentak Ini akan menyebabkan konteks benang sering bertukar, penggunaan CPU meroket, tindak balas sistem menjadi perlahan dan animasi yang digantung berlaku.

  Jenis cap masa dan pemilihan jenis masa

  Dalam beberapa dokumen "Panduan Pangkalan Data", adalah disyorkan untuk menggunakan jenis cap masa dan bukannya medan masa tarikh Sebabnya ialah jenis cap masa menggunakan 4 bait, dan medan datetime Gunakan 8 bait, tetapi dengan peningkatan prestasi cakera dan pengurangan kos ingatan, dalam persekitaran pengeluaran sebenar, menggunakan jenis cap waktu tidak akan membawa banyak peningkatan prestasi Sebaliknya, ia mungkin terhad dan menjejaskan perniagaan disebabkan oleh definisi dan julat nilai bagi jenis cap masa.

  Dalam MySQL 5.6.4 dan versi yang lebih baru, data jenis cap masa (cap masa) boleh ditukar kepada mikrosaat ketepatan tertinggi, dan data jenis masa (masa tarikh) juga boleh ditukar kepada mikrosaat ketepatan tertinggi benar untuk jenis masa (masa tarikh) Anda boleh mendapatkan kesan yang sama seperti jenis cap masa, contohnya, tentukan medan sebagai dt1 DATETIME(3) NOT NULL DEFAULT NOW(3) ON UPDATE NOW(3); datetime) ialah ’1000-01-01 00: 00:00.000000’ hingga ‘9999-12-31 23:59:59.999999’, yang boleh menyimpan data setiap tempoh masa dengan lebih baik.

  Pengesyoran untuk penggunaan jenis cap masa

  Apabila anda hanya mengambil berat tentang masa kemas kini terakhir data, adalah disyorkan untuk mentakrifkan lajur cap masa sebagai STAMP MASA BUKAN NULL STAMP MASA LALAI PADA KEMASKINI CURRENT_TIMESTAMP;

  Jika anda mengambil berat tentang masa penciptaan dan masa kemas kini, adalah disyorkan untuk menetapkan masa kemas kini sebagai medan cap masa, tentukan masa penciptaan sebagai DAETIME atau TIMESTAMP DEFAULT ‘0000-00-00 00:00: 00’, dan paparkannya apabila memasukkan rekod untuk menentukan masa penciptaan

  Adalah disyorkan untuk mentakrifkan hanya satu lajur cap waktu dalam jadual dan mentakrifkan atribut LALAI dan ON UPDATE; >

  Walaupun medan cap masa boleh ditetapkan atau dikemas kini dalam MySQL , tetapi disyorkan untuk memasukkan dan mengemas kini lajur cap masa secara eksplisit hanya apabila perlu
  Adalah disyorkan untuk menetapkan parameter zon_masa kepada nilai di luar sistem, seperti pelayan wilayah China ditetapkan kepada ’+8:00’
  Adalah disyorkan untuk memastikan versi ujian luar talian MySQL dan versi pengeluaran dalam talian konsisten.
  Persamaan dan perbezaan antara Cap Waktu dan masa tarikh
  Mata yang sama:
  • Boleh dikemas kini dan dimulakan secara automatik, dan format paparan lalai adalah sama YYYY -MM-dd HH:mm :ss

  Perbezaan:
  • Julat masa cap waktu ialah: ‘1970-01-01 00 :00:01’ UTC hingga ‘2038-01-19 03:14:07&rsquo UTC, penukaran zon waktu automatik, storan sebenar milisaat, storan 4-bait

  • masa tarikh julat: ‘1000-01 -01 00:00:00’ hingga ‘9999-12-31 23:59:59’, tidak menyokong zon waktu, storan 8-bait

  Tetapkan kemas kini automatik cap masa dan tarikh Masa
  Apabila mengemas kini sekeping data atau memasukkan sekeping data baharu tanpa memberikan nilai kepada tarikh dan tarikh saya, kedua-dua medan tarikh dan tarikh saya akan lalai secara automatik kepada masa semasa

  CREATE TABLE `mytime` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `date` timestamp(6) NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
    `mydate` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`)
  ) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;

  masalah 2038
  Apabila masa yang disimpan cap waktu lebih besar daripada '2038-01-19 03:14:07' UTC, mysql akan melaporkan ralat, kerana ini adalah masalah mysql itu sendiri, yang bermaksud bahawa cap waktu mempunyai had atas, jika ia melebihi, ralat secara semula jadi akan dilaporkan. Beberapa tangkapan skrin adalah seperti berikut:

  

  Penyelesaian
  cap masa Walaupun terdapat had atas, ia menyimpan cap masa, jadi anda tidak perlu mempertimbangkan Isu zon waktu Jika perlu menangani keperluan yang berkaitan dengan zon waktu Apabila menyelesaikan had 2038, adalah disyorkan untuk menukar cap masa kepada jenis integer untuk menyimpan cap masa dan kemudian menukarnya dalam program (penyelesaian ini mempunyai. tidak dilaksanakan, ia hanya cadangan, gunakan dengan berhati-hati )

  Jika anda tidak perlu mempertimbangkan isu zon waktu, gantikan saja cap waktu dengan jenis masa data, kerana julat nilai masa data adalah lebih besar, lihat gambar di atas;
  

  Idea penggantian:
  1. Ubah suai nama medan asal; yang asal);

  ALTER TABLE `student` CHANGE `entry_date` `temp_entry_date` timestamp NOT NULL default '0000-00-00 00:00:00';

  Salin data lajur medan asal ke lajur medan baharu; berikut: (Perlu diambil perhatian bahawa nilai lalai cap waktu asal juga perlu ditambah)

  ALTER TABLE `student` ADD `entry_date` DATETIME NOT NULL default '0000-00-00 00:00:00';

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah cap waktu 2038 Mysql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!