3

注意问题已解决：这似乎是由同一记录上的后来替换引起的。

插入记录时，我有一个带有时间戳列标记的表：

insert_timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

随着时间的推移，该表已经变得相当大 - 目前约 570 万条记录。

为了帮助您理解我问这个问题的原因，我需要解释一下，我有一个应用程序会尝试在插入数据后立即使用插入的数据，以与将记录插入数据库的代码异步的方式。在许多情况下，它工作得很好，而且我看到这个过程几乎是瞬时的。但是，我也看到一些insert_timestamp 值远大于插入记录的时间的情况。TIMESTAMP 数据类型的 MySQL 文档没有任何解释为什么会发生这种情况。

我怀疑这可能是由于索引重建问题，尽管我不明白为什么时间戳不能设置为插入的时刻。

你知道为什么会这样吗？任何见解或想法也将不胜感激。

谢谢，亚龙

注意：虽然 insert_timestamp 列是使用 ON UPDATE 定义的，但此表中的记录从未真正更新过。

下面是表格的完整结构：

CREATE TABLE `checkins` (
`type` enum('Change','Add','Remove') DEFAULT NULL,
`ci_when` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`whoid` mediumint(9) NOT NULL DEFAULT '0',
`repositoryid` mediumint(9) NOT NULL DEFAULT '0',
`dirid` mediumint(9) NOT NULL DEFAULT '0',
`fileid` mediumint(9) NOT NULL DEFAULT '0',
`revision` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '',
`prevrevision` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '',
`stickytag` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '',
`branchid` mediumint(9) NOT NULL DEFAULT '0',
`addedlines` int(11) NOT NULL DEFAULT '0',
`removedlines` int(11) NOT NULL DEFAULT '0',
`descid` mediumint(9) DEFAULT NULL,
`reviewid` mediumint(9) NOT NULL DEFAULT '0',
`insert_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY `repositoryid` (`repositoryid`,`dirid`,`fileid`,`revision`),
KEY `ci_when` (`ci_when`),
KEY `whoid` (`whoid`,`ci_when`),
KEY `dirid` (`dirid`),
KEY `fileid` (`fileid`),
KEY `branchid` (`branchid`),
KEY `reviewid` (`reviewid`),
KEY `file_insert` (`dirid`,`fileid`,`insert_timestamp`),
KEY `insert_ts` (`insert_timestamp`),
KEY `its2` (`insert_timestamp`,`branchid`,`dirid`,`fileid`,`repositoryid`),
KEY `branch_its` (`branchid`,`insert_timestamp`,`dirid`,`fileid`,`repositoryid`),
KEY `review_and_branch` (`reviewid`,`branchid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

更多信息：

  • 插入速度通常相当慢。过去 24 小时是 361 条记录。有时它可能会更多（甚至一天超过 100K），但并不经常。无论插入率如何，我正在研究的延迟问题都会发生。
  • 服务器有 8 个 CPU，12GB RAM
  • 操作系统：Linux/Debian 2.6.32-5-amd64
  • 磁盘：系统：130GB，数据：60GB，58% 已使用，raid 1，82% 空闲
  • MySQL 5.1.6.3
  • 服务器变量：
    • innodb_adaptive_hash_index 开启
    • innodb_additional_mem_pool_size 1048576
    • innodb_autoextend_increment 8
    • innodb_autoinc_lock_mode 1
    • innodb_buffer_pool_size 8589934592
    • innodb_checksums ON
    • innodb_commit_concurrency 0
    • innodb_concurrency_tickets 500
    • innodb_data_file_path ibdata1:10M:autoextend
    • innodb_data_home_dir
    • innodb_doublewrite 开启
    • innodb_fast_shutdown 1
    • innodb_file_io_threads 4
    • innodb_file_per_table ON
    • innodb_flush_log_at_trx_commit 1
    • innodb_flush_method
    • innodb_force_recovery 0
    • innodb_lock_wait_timeout 50
    • innodb_locks_unsafe_for_binlog 关闭
    • innodb_log_buffer_size 1048576
    • innodb_log_file_size 5242880
    • innodb_log_files_in_group 2
    • innodb_log_group_home_dir ./
    • innodb_max_dirty_pages_pct 90
    • innodb_max_purge_lag 0
    • innodb_mirrored_log_groups 1
    • innodb_open_files 300
    • innodb_rollback_on_timeout 关闭
    • innodb_stats_method nulls_equal
    • innodb_stats_on_metadata 开启
    • innodb_support_xa 开启
    • innodb_sync_spin_loops 20
    • innodb_table_locks 开启
    • innodb_thread_concurrency 8
    • innodb_thread_sleep_delay 10000
    • innodb_use_legacy_cardinality_algorithm ON
4

0 回答 0