- 案例输入**
生产和测试的Mysql版本:5.7
- 查询:**
SELECT
t1.id
t1.accountId,
t2.col1
FROM
table1 t1
INNER JOIN table2 t2 ON
(t2.Id = t1.id)
WHERE
1 AND MOD(t1.id, 20) = 0 AND t1.col1 = 0 AND t1.col2 <= '2023-01-24' AND t1.col3 = 3;
Test Production
Records in table1: 139664513 220184774
Records in table2: 139664513 220178452
- 表格结构:**
CREATE TABLE `table1` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`col3` int(11) unsigned NOT NULL,
`col2` date DEFAULT NULL,
`col1` tinyint(1) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `col3` (`col3`),
KEY `col2` (`col2`),
KEY `col1` (`col1`),
KEY `idx_col3_col1_col2` (`col3`,`col1`,`col2`),
) ENGINE=InnoDB;
解释输出:
Test explain OP
Prod explain OP
由于没有在测试服务器上获取所需的索引,因此与生产服务器相比,需要花费大量时间来执行。
想知道为什么它没有在具有相同表结构的测试服务器上获取所需的索引。
"我努力过"
- Force索引工作正常,并且解释输出与生产相同,但为什么没有Force索引解释不使用所需的键,这是值得关注的问题。
1.重建索引
2条答案
按热度按时间flmtquvp1#
ANALYZE TABLE table1;
* 可以 * 修复差异。KEY
col3
(col3
),与组合键冗余;你还是放弃吧。提供
EXPLAIN FORMAT-JSON SELECT ...
--它可能会给予更多线索。如果这还不够,请尝试“优化器跟踪”-http://mysql.rjweb.org/doc.php/index_cookbook_mysql#optimizer_tracekiz8lqtg2#
问题已解决。
我删除了索引,并使用较短的索引名称重新创建了它,现在它在解释计划中恢复了。
以前我也尝试重新创建索引,但使用相同的长名称,这是行不通的。
我检查了标识符的最大长度[https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html]
在我的例子中,索引名称的长度是60个字符,而在上面的链接中,最大长度是64个字符。尽管如此,它还是解决了我的问题。
对不起,但我不能上传名称的实际表详细信息,因为数据安全。
感谢您的快速响应!