
MySQL索引失效案例分析
本文分析一个实际案例,探讨MySQL索引失效的现象及原因。
数据库表结构如下:
<code class="sql">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='代理商打货表';</code>
测试数据:
<code class="sql">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);</code>
问题SQL:
<code class="sql">EXPLAIN SELECT stock FROM `ns_delivery_shop` WHERE shop_id = 1;</code>
观察发现:当 shop_id = 1 的记录数量小于等于2时,索引 idx_shop_id 可正常使用;但当数量大于2时,索引失效,MySQL选择全表扫描。
索引失效原因分析:
这并非索引本身的问题,而是MySQL查询优化器做出的选择。当符合条件的数据量占总数据量的比例超过一定阈值时,MySQL估计全表扫描的成本更低,因此放弃使用索引。 这与数据量和数据分布有关,并非绝对的记录数量阈值。
以上就是MySQL索引失效:为何`shop_id`索引在数据量增多后失效?的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号