我有这张表，其中包含大约 80,000,000 行。
CREATE TABLE `mytable` (
`date` date NOT NULL,
`parameters` mediumint(8) unsigned NOT NULL,
`num` tinyint(3) unsigned NOT NULL,
`val1` int(11) NOT NULL,
`val2` int(10) NOT NULL,
`active` tinyint(3) unsigned NOT NULL,
`ref` int(10) unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`ref`) USING BTREE,
KEY `parameters` (`parameters`)
) ENGINE=MyISAM AUTO_INCREMENT=79092001 DEFAULT CHARSET=latin1
它围绕 2 个主要列：“参数”和“日期”。每个“参数”大约有 67,000 个可能的“参数”值，大约有 1200 行，每行都有不同的日期。所以对于每个日期，有 67,000 行。1200 * 67,000 = 80,400,000。
表大小显示为 1.5GB，索引大小为 1.4GB。
现在，我想查询表以检索一个“参数”的所有行（实际上我想对每个参数都这样做，但这是一个好的开始）
SELECT val1 FROM mytable WHERE parameters=1;
第一次运行在 8 秒内给我结果，随后运行不同但接近的参数值（2、3、4...）是瞬时的
运行“遥远”值（参数 = 1000）再次给我 8 秒的结果。
我在没有索引的情况下运行了相同的查询进行了测试，并在 20 秒内得到了结果，所以我猜索引正在启动，如 EXPLAIN 所示，但性能并没有大幅提升：
+----+-------------+----------+------+---------------+------------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+------+---------------+------------+---------+-------+------+-------+
| 1 | SIMPLE | mytable | ref | parameters | parameters | 3 | const | 1097 | |
+----+-------------+----------+------+---------------+------------+---------+-------+------+-------+
但我仍然对这种简单请求的时间感到困惑（没有加入，直接在索引上）。
该服务器是 2 岁的 2 cpu 四核 2.6GHz 运行 Ubuntu，具有 4G 内存。我已将 key_buffer 参数提高到 1G，并重新启动了 mysql，但没有发现任何变化。
我应该认为这是正常的吗？还是我做错了什么？我对正确的配置有感觉，请求应该几乎是立即的。