MySql Сервер 5.7 не сохраняет миллисекунды в столбце DATETIME (3) - PullRequest
1 голос
/ 04 февраля 2020

У меня MySQL Сервер работает на Armbian Bioni c (Ubuntu 18.04.4), работает на Orange Pi Zero. MySQL версия сервера 5.7.29.

Я создал таблицу с типом данных DATETIME(3), то есть я хотел бы хранить дату и время с точностью до миллисекунды.

Когда я выполняю INSERT INTO table1 (column1) VALUES ('2020-02-04 12:34:46.789');, а затем я выполняю SELECT column1 FROM table1;, он показывает:

2020-02-04 12: 34: 47

Итак казалось бы, это не экономит миллисекунду? Но если я выполню SELECT NOW(3);, он покажет:

2020-02-04 20: 25: 33.077

Таким образом, он обрабатывает миллисекунды. Есть идеи?

Ответы [ 2 ]

2 голосов
/ 04 февраля 2020

Похоже, ваш столбец использует значение по умолчанию DATETIME. Вы можете просмотреть текущую схему таблицы, используя следующий запрос:

DESC table_name

Убедитесь, что вы создали таблицу с DATETIME(3):

CREATE TABLE table_name (
  column_name DATETIME(3)
)

Вы можете убедиться, что выходные данные используют точность. Но вы получите миллисекунды только в том случае, если значение хранится в столбце DATETIME(3):

SELECT CAST(column_name AS DATETIME(3)) FROM table_name

демо на dbfiddle.uk

0 голосов
/ 07 февраля 2020

Я не могу этого объяснить. Несмотря на то, что я создал столбец как DATETIME (3) , и даже после выполнения DESC table1 и получения ответа DATETIME (3) из чистого отчаяния я попытался использовать другую базу данных клиент другой тогда MySql верстак. Я скачал DBeaver и отредактировал таблицу. Я увидел, что для column1 задано значение DATETIME (хотя Workbench показало его как DATETIME (3)). Так что я сделал это DATETIME (3), и теперь это работает! Так что это должна быть ошибка в Workbench, когда при создании или редактировании столбца DATETIME он игнорирует дробный второй спецификатор.

...