3

注問題は解決されました。これは、同じレコードでの後の REPLACE が原因のようです。

レコードが挿入されたときのタイムスタンプ列のマークが付いたテーブルがあります。

insert_timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

テーブルは時間の経過とともに非常に大きくなり、現在は最大 570 万レコードです。

なぜ私がこれを尋ねているのかを理解するのを助けるために、レコードを DB に挿入するコードから非同期的に、挿入されたデータをすぐに利用しようとするアプリケーションがあることを説明する必要があります。多くの場合、うまく機能し、このプロセスはほぼ瞬時に行われることがわかります。ただし、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 レコードでした。場合によってはそれ以上になることもありますが (1 日で 100K を超えることもあります)、頻繁ではありません。私が調査しているレイテンシの問題は、挿入率に関係なく発生します。
  • サーバーには 8 つの CPU、12GB の RAM があります。
  • OS: Linux/Debian 2.6.32-5-amd64
  • ディスク: システム: 130GB、データ: 60 GB、使用率 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 オン
    • 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 オン
    • 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 オン
4

0 に答える 0