2

私はmysql 5.6で遊んでいます。私は特に可能性に興味があります: DATETIME または TIMESTAMP 値には、最大マイクロ秒 (6 桁) の精度で秒の小数部を含めることができます。

私が望むのは、そのようなタイムスタンプを使用してテーブルを分割することです。

例：

CREATE TABLE `VALUE_BIS` (
  `TSTAMP` timestamp(3) NOT NULL,
  `ATTRIBUTE_ID` int(11) NOT NULL,
  `VAL` int(11) unsigned NOT NULL,
  PRIMARY KEY (`ATTRIBUTE_ID`,`TSTAMP`)
)  PARTITION BY RANGE (UNIX_TIMESTAMP(TSTAMP))
     (PARTITION p_s18 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-18 00:00:00')),
     PARTITION p_s19 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-19 00:00:00')),
     PARTITION p_Max VALUES LESS THAN (UNIX_TIMESTAMP('2020-09-26 00:00:00' )));

==>エラー 1491 (HY000): PARTITION 関数が間違った型を返します

*整数ではないunixtimestamp_seconds.microsecondsを返すので、それは正常だと思います*

次のようにミリ秒を追加すると

PARTITION p_s18 VALUES LESS THAN (UNIX_TIMESTAMP('2012-09-18 00:00:00.000')

==> エラー 1697 (HY000): パーティション 'p_s18' の VALUES 値の型は INT でなければなりません

OK 前と同じ話

tstamp 列の定義を変更し、ミリ秒を使用しない場合

`TSTAMP` timestamp

==>問題なく動作しますが、ミリ秒を保存しません。それは私が望むものではありません。

何か案が？

4

3 に答える 3

3

MySQL では、このようなタイムスタンプを使用してテーブルをパーティショニングする際にまだ問題があり、 InnoDB のクラッシュを引き起こす可能性があります。過去に小数秒を使用したタイムスタンプの動作にいくつかの変更を加えました。

私の最初の推測は、フラクタル秒の保存方法と使用方法が unix_timestamp と衝突することです。したがって、パーティショニングを適切に作成できません (タイプが間違っているため) ... したがって、発生したエラーメッセージが生成されます。

回避策は、端数秒を含まないタイムスタンプのみを含む 2 番目のフィールドを追加し、代わりにこれを範囲識別子として使用することです。

いずれにせよ、バグを報告する必要があります。

于 2012-09-25T13:46:34.183 に答える
0

Bjoern が提案したように、私は mysql トラッカー (http://bugs.mysql.com/bug.php?id=66958) にバグを提出しました。これが彼らの答えです（彼らにとってはバグではありません）

Timestamp(N) は文書化されているようにサポートされていません: http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html

" 互換性のない変更: MySQL の非常に古いバージョン (4.1 より前) では、TIMESTAMP データ型は表示幅をサポートしていましたが、MySQL 4.1 から黙って無視されていました。これは MySQL 5.1 で廃止され、MySQL 5.5 で完全に削除されました。これらの変更MySQL 5.5 以降のサーバーで TIMESTAMP(N) 列を使用しようとすると、2 つの問題が発生する可能性があります。

MySQL 5.0 以前のサーバーで作成されたダンプ ファイル (たとえば、mysqldump を使用して作成されたもの) を新しいリリース シリーズのサーバーにインポートする場合、TIMESTAMP(N) を含む CREATE TABLE または ALTER TABLE ステートメントによりインポートが失敗します。構文エラー。"

于 2012-09-26T09:15:08.960 に答える