mysql – 使用索引优化WHERE IN条件

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了mysql – 使用索引优化WHERE IN条件，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1317字，纯文字阅读大概需要2分钟。

内容图文

我有一个看起来像下面的表：

CREATE TABLE foo ( 
    type       TINYINT,    -- low cardinality (2..5)
    id         BINARY(16), -- high cardinality
    other_data OTHERTYPE(n),
    CONSTRAINT foo_PK PRIMARY KEY (type, id)
);

访问包含该表的数据库的一个应用程序按类型和标识运行点查询,并按多个(类型,标识)对过滤查询.

问题是：在这些情况下哪个指数表现更好？目前,我将类型列分组并在SELECT * FROM表上执行UNION WHERE type =？ AND id IN(？)

首先使用最高基数列的经验法则仍然可行,或者我应该定义(类型,id)索引？

注意：数据库运行在MySQL之上,但考虑其他RDBMS的答案也很有趣.

解决方法:

警告：这个答案适用于MySQL中的InnoDB.它可能不适用于其他MySQL引擎,也不适用于其他RDBMS.

一个主要的关键是

>与数据集群,和
>唯一性约束,和
>一个索引

SELECT * FROM表WHERE type =？ AND id IN(？,？,？)最好由PRIMARY KEY(type,id)处理,并按此顺序排列. (第二好的是INDEX(type,id)).

>作为索引,查找不需要扫描整个表.
>群集,查找和*(SELECT *)同时完成.
>独特与此SELECT无关.
>列顺序是必需的,因为=必须先出现.
>如果IN中只有一个项目,IN将优化为=;该指数仍然是最优的.

与一个根深蒂固的妻子的故事相反,类型与身份的基数是不相关的,至少对于这个查询而言.

附注：WHERE中项目的顺序对性能没有影响;索引中的顺序.

在这种情况下,=应首先出现在索引中,然后是更复杂的项目,在这种情况下为IN.

id闻起来像一个打包的UUID.对于可能在所有RDBMS中的可怕类型索引的巨大表,因为它是随机的,因此缓存是不切实际的.

Index Cookbook for MySQL / MariaDB.

内容总结

以上是互联网集市为您收集整理的mysql – 使用索引优化WHERE IN条件全部内容，希望文章能够帮你解决mysql – 使用索引优化WHERE IN条件所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端