数据库里怎么快点找到满足好几个条件的数据，技巧分享给你

综合自多位资深数据库开发者和DBA的实践经验分享，主要参考了知乎专栏“数据库性能优化那些事”、CSDN博客“老鸟谈SQL”以及开源社区Stack Overflow上的相关高赞讨论）

想要在数据库里快速找到同时满足好几个条件的数据，说白了，就是让数据库少干点活、少跑点路，数据库就像一个巨大的图书馆，你的查询条件就是你要找的书的特点，2020年出版的、计算机类的、作者姓王的、价格低于50元的”，如果方法不对，管理员（数据库）可能得跑遍整个图书馆翻看每一本书，那当然慢了，我们的目标就是给他一张精准的“藏宝图”,让他能直奔目的地。

给查询条件排个队，让最厉害的先上。 想象一下，你要在人群中找一个人：他是“北京人、男性、戴眼镜、穿红色上衣”，最有效的办法不是一个个去问“你穿红色上衣吗？”，而是先大声问“谁是北京人？”，让一大部分人举手，然后再在举手的人里问“谁是男性？”，这样范围就迅速缩小了，数据库也一样，你要把最能筛掉大量数据的条件放在前面，这个“厉害”的条件，通常是能排除掉最多数据行的那个，你的数据表有1000万条用户记录，城市=上海”的可能有100万条，而“注册时间在最近7天”的可能只有1万条，先筛选“注册时间在最近7天”，就能立刻把范围从1000万缩小到1万，后续再在城市、性别等其他条件上过滤，工作量就小太多了，在写SQL语句的WHERE子句时，虽然数据库的查询优化器会尝试帮你优化顺序，但明确地把选择性高的条件放在前面，或者通过其他方式提示优化器,往往能起到积极作用。

建立联合索引，就像给多条路修一条直达高速。 单列索引好理解，比如给“城市”字段建个索引，找“上海”的用户就很快，但当你经常要同时按“城市”和“注册时间”查询时，单列索引可能就不够用了，数据库可能会先用“城市”索引找到所有上海用户，然后再在这100万人里一个个对比“注册时间”，这第二步如果数据量大依然很慢，这时候，联合索引就派上用场了，联合索引就像是按照“城市”和“注册时间”两个字段联合起来排序的目录，这个目录的结构是先按城市字母排序，同一个城市内部再按注册时间倒序排列，这样，当你要找“上海”且“注册时间在最近7天”的数据时，数据库通过这个联合索引可以直接定位到“上海”这个区域，然后因为内部是按时间排好序的，它可以迅速找到最近7天的数据范围，效率极高，这里有个关键点：联合索引的字段顺序至关重要，一定要把上面技巧一里那个“最厉害”、最常使用的筛选字段放在索引的第一位，这就像电话号码簿先按姓排再按名排一样，如果你只知道名不知道姓,这个电话簿就很难用。

尽量避免在条件里做计算或者用函数。 这是一个非常常见且致命的慢查询陷阱，你要查注册时间刚好是3天前的用户，新手可能会写“WHERE DATE(register_time) = '2023-10-27'”，这个查询看起来没问题，但因为你对字段register_time使用了DATE()函数，数据库就无法使用建立在register_time上的索引了，它不得不对表中的每一条记录都计算一下DATE(register_time)的值，然后再和‘2023-10-27’比较，这就是一次全表扫描，非常慢，正确的写法应该是利用范围查询：“WHERE register_time >= '2023-10-27 00:00:00' AND register_time < '2023-10-28 00:00:00'”，这样，数据库就可以高效地利用register_time字段的索引来快速定位数据，同样，对字段进行数学运算（如WHERE price * 2 > 100）、字符串截取等操作,都会导致索引失效。

只取你需要的数据，别让数据库搬回来一整座山。 你明明只需要知道书名和作者，却让图书馆管理员把整本书都搬过来给你看，这显然浪费力气，数据库查询也是同理，坚决避免使用“SELECT *”，一定要明确列出你需要的字段名，SELECT user_id, user_name, email”，这样做的好处有两个：一是减少了数据库需要从硬盘读取和通过网络传输的数据量，速度自然更快；二是在某些情况下，如果所有需要的字段都包含在某个索引里（这被称为“覆盖索引”），数据库甚至不需要再去查找原始的数据表，直接在索引里就能拿到所有数据,速度会得到极大的提升。

定期给数据库做“体检”，看看它到底是怎么干活的。 现在的数据库大多提供了分析查询执行计划的功能（比如MySQL的EXPLAIN命令，PostgreSQL的EXPLAIN ANALYZE），这个功能能告诉你数据库准备如何执行你的查询语句：它打算用哪个索引？它预估要扫描多少行数据？它是否需要做复杂的连接或排序？学会看这个执行计划至关重要，当你发现一个查询很慢时，就用EXPLAIN看一下，你可能会发现它没有使用你精心创建的索引，或者它预估的行数远远不对导致选择了错误的执行路径，这时你就可以有针对性地去调整索引或者优化SQL语句了，这就像是给数据库的思考过程拍了个X光片,问题一目了然。

核心思想就是“知己知彼”：了解你的数据分布（哪个条件筛选性强），了解数据库的工作原理（索引如何生效），然后通过建立合适的索引、编写高效的SQL语句（条件顺序、避免计算、只取所需）来引导数据库用最短的路径找到你要的数据，别忘了利用执行计划这个工具来验证和调优，这些技巧结合起来运用，对付多条件查询的速度问题,效果会非常明显。