一、消息队列解决什么问题

消息队列的核心价值有三个。第一是解耦，生产者和消费者不需要同时在线，也不需要知道彼此的存在。第二是削峰，突发流量先进入队列，消费者按自身能力处理，避免下游被瞬时流量打垮。第三是异步化，把非核心链路从主流程中剥离，缩短用户请求的响应时间。

这些收益是有代价的。异步意味着一致性窗口变长，解耦意味着故障排查链路变长，削峰意味着队列本身成为新的关键组件。

二、重复消费是常态而不是异常

主流消息队列普遍提供至少一次投递语义。也就是说，同一条消息可能被投递多次，这在网络抖动、消费者重启、分区再均衡时都可能发生。

因此消费逻辑必须具备幂等能力。常见做法是为每条消息分配唯一标识，消费前检查该标识是否已处理，或者利用数据库唯一约束防止重复写入。对于状态变更类操作，可以基于版本号或状态机判断，已经处于目标状态的请求直接丢弃。

把去重责任放在消费侧，是消息队列使用的基本共识。依赖队列侧完全不重复，在分布式环境下代价极高且通常不可保证。

三、顺序消息需要付出额外成本

全局有序在分布式消息系统中很难实现，常见方案只保证分区级有序。也就是说，只有被路由到同一分区的消息才能保证消费顺序，不同分区之间没有顺序保证。

需要顺序处理的业务，例如同一账户的余额变动，通常以业务标识作为分区键，让相关消息进入同一分区。这样做的代价是牺牲了部分并行度，单个分区的吞吐量成为瓶颈。如果某个标识的消息量特别大，还会出现分区热点。

设计时需要权衡：是否真的需要严格顺序，还是只需要最终一致；是否可以把顺序要求缩小到更细的粒度，用更少的分区换取更高的吞吐。

四、消息积压是容量问题的信号

积压指消息生产速度持续超过消费速度，队列中的待处理消息不断增长。短期积压是削峰的正常表现，持续积压则说明消费能力不足或消费逻辑异常。

积压的排查通常分三步。先确认是生产突增还是消费变慢，再看消费慢在逻辑本身还是下游依赖，最后判断是否需要扩容消费者或临时降级非核心消息。

需要警惕的是把积压当作缓冲的默认手段。队列容量有限，积压时间过长会导致消息过期丢失，或者磁盘写满影响整个集群。对积压设置告警阈值，并预先约定扩容和降级预案，是稳定使用消息队列的基本要求。

五、总结

消息队列把同步调用的问题换成了异步系统的问题。重复消费要求消费幂等，顺序要求要求牺牲并行度，积压要求持续的容量管理。引入消息队列之前，先回答三个问题：消息丢了怎么办，重复了怎么办，积压了怎么办。三个问题都有明确答案，才算真正具备了使用条件。

第二篇：索引为什么有时不生效：数据库索引的常见误解

摘要

建了索引查询仍然很慢，是数据库使用中最常见的困惑之一。索引不是创建了就一定生效，它的生效与否取决于查询写法、数据分布和优化器的成本估算。本文解释索引失效的几类典型原因，以及排查索引问题时的基本方法。

标签：数据库、MySQL、索引、慢查询、性能优化

一、索引的本质是有序的数据结构

常见数据库的索引大多基于 B+ 树。它的价值在于把全表扫描变成树查找，把复杂度从线性降到对数级。但这个价值成立的前提是，查询条件能够利用索引的有序性进行快速定位。

一旦查询写法破坏了有序性的使用条件，索引就可能失效，查询退化为全表扫描。

二、最常见的几类失效场景

对索引列使用函数或表达式。例如对创建时间列做日期格式化后再比较，数据库无法直接利用索引中的原始值定位，只能逐行计算后再判断。类似地，索引列参与运算、隐式类型转换，都会导致索引失效。字符串列传入数字、字符集不一致的关联，都属于这一类。

模糊匹配以通配符开头。索引按照列值从左到右排序，最左通配的查询无法确定从哪个位置开始查找，只能全表扫描。

违反最左前缀原则。联合索引按照定义的列顺序组织，查询条件跳过左侧列时，后续列通常无法有效利用索引。联合索引的列顺序应该根据查询频率和区分度设计，而不是随意排列。

范围条件之后的列无法继续走索引。在联合索引中，一旦某一列使用了范围查询，其右侧的列一般只能用于过滤，不能用于索引定位。

三、优化器有时主动放弃索引

即使查询写法没有问题，优化器也可能估算后认为全表扫描更便宜。典型场景是查询条件命中的数据占比过高。当优化器判断需要回表的比例太大，随机 IO 的成本超过顺序扫描时，会主动选择全表扫描。

这类情况说明索引的区分度不足，或者查询本身就不适合用索引解决。盲目强制使用索引，反而可能让查询更慢。

四、排查索引问题的基本方法

第一步是使用执行计划确认索引是否被使用，关注访问类型、使用的索引、扫描行数。第二步是对比预估扫描行数与实际执行耗时，判断问题是出在索引选择还是数据访问本身。第三步是检查表统计信息是否过期，过期的统计信息会误导优化器做出错误决策。

此外，索引并非越多越好。每个索引都会增加写入时的维护成本和存储开销。索引设计应该基于真实的查询模式，定期清理未被使用的索引，与添加新索引同样重要。

五、总结

索引失效的根源可以归结为两类：查询写法破坏了索引的有序性，或者优化器判断索引不划算。理解 B+ 树的组织方式和最左前缀原则，配合执行计划进行验证，是解决大多数索引问题的通用路径。索引是写给查询的，不是写给表的，脱离查询场景谈索引设计没有意义。