where 条件并不是越多越好

本文讨论了一个SQL查询中where条件过多导致执行计划不佳的问题。当A表和B表通过heard_id关联,同时使用class_no和batch_no作为额外条件时,查询并未利用heard_id索引,反而选择了class_no和batch_no的联合索引,从而影响查询速度。通过简化where条件,只保留heard_id关联条件,查询性能得到显著提升。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天在写一个sql时,遇到这么个问题,where条件多写了几个,结果结果执行计划显得很槽糕:

表A 有字段 heard_id,class_no,bath_no,class_name

表B有字段 heard_id,class_no,bath_no,class_value

首先A表与B表是通过heard_id相关联,首先得承认这2个表设计有点问题,不满足范式的要求,有冗余的信息,如class_no,bath_no,结果我在写写sql时写成这个样子:

select a.class_no,a.batch_no,a.class_name,b,class_value

from a,b

where a.heard_id = b.heard_id

MySQL索引不是越多越好,其效果取决于索引的选择和使用情况。以下几点可以帮助理解: 1. **性能提升**: 索引确实可以加快查询速度,特别是对于经常作为WHERE子句条件的列,如果没有索引,全表扫描的效率会很低。因此,为这类列创建索引是有益的。 2. **资源消耗**: 每个索引都需要占用存储空间,且每次插入、更新或删除数据时,索引也需要维护,这会增加写操作的时间和I/O开销。过多的索引可能会导致性能下降,特别是对频繁写入的表。 3. **设计原则**: 应该根据查询模式选择关键列创建索引,避免在不常用于搜索的列上创建,以及避免创建全表扫描的覆盖索引(即索引包含了查询所需的所有信息,不需要回表)。 4. **唯一性和复合索引**: 唯一索引能确保唯一性,而复合索引可以在多个列上组合索引,提高复杂查询的效率。但过多的复合索引可能会增加维护的复杂性。 5. **InnoDB存储引擎**:InnoDB存储引擎有自适应哈希索引,它可以根据表的数据动态调整索引策略,但这不意味着可以随意创建大量索引。 因此,优化的策略是根据实际应用需求,分析查询模式,合理地创建和维护索引,而不是单纯追求索引数量。如果你对如何优化你的特定数据库有疑问,可以提供更详细的表结构和查询日志,以便给出更精准的建议。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值