私はテーブル定義を持っています:
CREATE TABLE `k_timestamps` (
`id` bigint(20) NOT NULL,
`k_timestamp` datetime NULL DEFAULT NULL,
`data1` smallint(6) NOT NULL,
KEY `k_timestamp_key` (`k_timestamp`,`id`) USING BTREE,
CONSTRAINT `k_time_fk` FOREIGN KEY (`id`) REFERENCES `data` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
基本的に、私はたくさんのキーid
とdata1
値のペアを持っており、数時間ごとに、以前に見られなかった新しいキーと値のペアをリストに追加するか、以前の ID の値が変更されました。すべての値が時間ごとid
に何であったかを追跡したいと思います。したがって、id
列には重複した が含まれる可能性id
があり、主キーではありません。
補足として、現在の時刻や現在保持している値に関係なくk_time_fk
、特定の共通情報を持つ別のはるかに小さなテーブルを示します。id
(id, k_timestamp)
テーブルの(複合)主キーと考える必要があります。
例えば、
id k_timestamp data1
1597071247 2012-11-15 12:25:47 4
1597355222 2012-11-15 12:25:47 4
1597201376 2012-11-15 12:25:47 4
1597071243 2012-11-15 13:25:47 4
1597071247 2012-11-15 13:25:47 3
1597071249 2012-11-15 13:25:47 3
とにかく、私はこのクエリを実行しました:
SELECT concat(table_schema,'.',table_name),
concat(round(table_rows/1000000,2),'M') rows,
concat(round(data_length/(1024*1024*1024),2),'G') DATA,
concat(round(index_length/(1024*1024*1024),2),'G') idx,
concat(round((data_length+index_length)/(1024*1024*1024),2),'G') total_size,
round(index_length/data_length,2) idxfrac
FROM information_schema.TABLES ORDER BY data_length+index_length DESC LIMIT 20;
テーブルのスペース情報をプルするには:
rows Data idx total_size idxfrac
11.25M 0.50G 0.87G 1.36G 1.76
これを理解しているかどうかはよくわかりませんが、どうしてインデックスがそんなに多くのスペースを占めているのでしょうか? ここで明らかに間違ったことはありますか、それともこれは正常ですか? 可能であれば、このテーブルのフットプリントを削減しようとしています。それが本当に何をk_timestamp_key
買ってくれるのかさえよくわかりませんが、安全に削除できますか?