gpt4 book ai didi

MySQL索引几乎不能加速简单查询

转载 作者:可可西里 更新时间:2023-11-01 07:45:01 24 4
gpt4 key购买 nike

我有这张表,其中包含大约 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 RAM。我已将 key_buffer 参数提高到 1G,并重新启动了 mysql,但发现没有任何变化。

我应该认为这是正常的吗?还是我做错了什么?我感觉如果配置正确,请求应该几乎是即时的。

最佳答案

尝试使用覆盖索引,即创建一个包含您需要的两列的索引。它不需要第二个磁盘 I/O 来从主表中获取值,因为数据就在索引中。

关于MySQL索引几乎不能加速简单查询,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19702774/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com