MySQL索引失效案例分析
本文分析一个实际案例，探讨MySQL索引失效的现象及原因。
数据库表结构如下：
CREATE TABLE `ns_delivery_shop` ( `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `goods_id` INT(10) NOT NULL COMMENT '商品id', `sku_id` INT(10) NOT NULL COMMENT '商品sku', `shop_id` INT(10) NOT NULL COMMENT '代理商id', `stock` INT(10) NOT NULL COMMENT '库存', `sales` INT(10) NOT NULL COMMENT '销量', `create_time` INT(10) NOT NULL COMMENT '时间', PRIMARY KEY (`id`), KEY `idx_shop_id` (`shop_id`) USING BTREE) ENGINE=INNODB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COMMENT='代理商打货表';
测试数据：
INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (1, 86, 99, 1, 10, 5, 1613960196);INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (2, 86, 100, 1, 15, 10, 1613960196);INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (3, 86, 101, 1, 25, 10, 1613960196);INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (4, 101, 119, 9, 30, 5, 1613960196);INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (5, 101, 119, 11, 30, 5, 1613960196);INSERT INTO `ns_delivery_shop`(`id`, `goods_id`, `sku_id`, `shop_id`, `stock`, `sales`, `create_time`) VALUES (6, 101, 119, 12, 30, 5, 1613960196);
问题SQL：
EXPLAIN SELECT stock FROM `ns_delivery_shop` WHERE shop_id = 1;
观察发现：当 shop_id = 1 的记录数量小于等于2时，索引 idx_shop_id 可正常使用；但当数量大于2时，索引失效，MySQL选择全表扫描。
索引失效原因分析:
这并非索引本身的问题，而是MySQL查询优化器做出的选择。当符合条件的数据量占总数据量的比例超过一定阈值时，MySQL估计全表扫描的成本更低，因此放弃使用索引。 这与数据量和数据分布有关，并非绝对的记录数量阈值。
以上就是MySQL索引失效：为何`shop_id`索引在数据量增多后失效？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1252996.html
微信扫一扫 
支付宝扫一扫 
