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`索引在数据量增多后失效？的详细内容，更多请关注php中文网其它相关文章！