Like和'='等于sql中的运算符性能 - mysql集群

Posted

技术标签:

【中文标题】Like和\'=\'等于sql中的运算符性能 - mysql集群【英文标题】:Like and '=' equals to operator performance in sql - mysql clusterLike和'='等于sql中的运算符性能 - mysql集群 【发布时间】:2016-10-03 05:36:25 【问题描述】:

mysql-Cluster-gpl-7.4.12-1.el6.x86_64

查询 1

    select
    userinfo.username,
    userinfo.firstname,
    userinfo.lastname,
    userinfo.email,
    radcheck.attribute,
    radcheck.`value`,
    radusergroup.groupname,
    userinfo.id,
    userinfo.account_type,
    userinfo.workphone,
    userinfo.homephone,
    userinfo.mobilephone,
    userinfo.address,
    userinfo.zone,
    userinfo.account_state,
    userinfo.link_type,
    userinfo.device_owner,
    userinfo.email
    FROM
    userinfo
    INNER JOIN radcheck ON userinfo.username = radcheck.username
    INNER JOIN radusergroup ON userinfo.username = radusergroup.username
    WHERE
    radcheck.attribute='Expiration'  AND userinfo.mobilephone LIKE '9876543210%'

此查询大约需要 8 秒 才能完成 下面是查询的explain 输出

    +----+-------------+--------------+------+----------------------+-----------+---------+----------------------------+------+-------------+
    | id | select_type | table        | type | possible_keys        | key       | key_len | ref                        | rows | Extra       |
    +----+-------------+--------------+------+----------------------+-----------+---------+----------------------------+------+-------------+
    |  1 | SIMPLE      | radcheck     | ref  | username,attribute   | attribute | 34      | const                      |    9 | Using where |
    |  1 | SIMPLE      | userinfo     | ref  | username,mobilephone | username  | 131     | ctradius.radcheck.username |   13 | Using where |
    |  1 | SIMPLE      | radusergroup | ref  | username             | username  | 66      | ctradius.userinfo.username |   10 | Using where |
    +----+-------------+--------------+------+----------------------+-----------+---------+----------------------------+------+-------------+

查询 2

以下是

内完成的查询
    select
    userinfo.username,
    userinfo.firstname,
    userinfo.lastname,
    userinfo.email,
    radcheck.attribute,
    radcheck.`value`,
    radusergroup.groupname,
    userinfo.id,
    userinfo.account_type,
    userinfo.workphone,
    userinfo.homephone,
    userinfo.mobilephone,
    userinfo.address,
    userinfo.zone,
    userinfo.account_state,
    userinfo.link_type,
    userinfo.device_owner,
    userinfo.email
    FROM
    userinfo
    INNER JOIN radcheck ON userinfo.username = radcheck.username
    INNER JOIN radusergroup ON userinfo.username = radusergroup.username
    WHERE
    radcheck.attribute like 'Expiration%'  AND userinfo.mobilephone LIKE '9876543210%'

下面是查询的解释

 +----+-------------+--------------+-------+----------------------+-------------+---------+----------------------------+------+------------------------+
    | id | select_type | table        | type  | possible_keys        | key         | key_len | ref                        | rows | Extra                  |
    +----+-------------+--------------+-------+----------------------+-------------+---------+----------------------------+------+------------------------+
    |  1 | SIMPLE      | userinfo     | range | username,mobilephone | mobilephone | 203     | NULL                       |  585 | Using where; Using MRR |
    |  1 | SIMPLE      | radusergroup | ref   | username             | username    | 66      | ctradius.userinfo.username |   10 | Using where            |
    |  1 | SIMPLE      | radcheck     | ref   | username,attribute   | username    | 66      | ctradius.userinfo.username |   17 | Using where            |
    +----+-------------+--------------+-------+----------------------+-------------+---------+----------------------------+------+------------------------+

问题

为什么使用like 运算符(第二个查询)而不是=(第一个查询)时查询执行速度更快?

【问题讨论】:

你能在额外栏目中看到Using MRR吗? 在 radcheck 上尝试“覆盖”索引:INDEX(attribute, value) 【参考方案1】:

你有两个完全不同的执行计划。

对于您的第一个查询,MySQL 通过radcheck.attribute 上的索引查找所有带有radcheck.attribute='Expiration' 的条目(并假设有9 行适合)。然后它将使用username(以及username 上的索引)为每个pssible 用户名连接其他表,然后从表中读取userinfo.mobilephone 的值并查看它是否适合。

对于您的第二个查询,它将检查 userinfo.mobilephone 上的索引以查找以 9876543210 开头的任何内容(假设它将找到 585 行)。然后它将使用username(以及username 上的索引)为所有具有正确手机的用户名加入其他表,然后从表中读取radcheck.attribute 的值并查看它是否适合。

当您实际上只有少数以您的手机号码开头的行,但很多行以radcheck.attribute='Expiration' 开头时,您的第二个查询当然会快得多,因为它必须完成其余的执行(加入,特别是从表中读取)行数少得多(尽管您必须比解释中显示的行数多得多才能证明 8 秒是合理的)。

MySQL 必须猜测哪种方式更快,并根据您的查询和有关表的一些统计数据选择一种方式。它选择了完全错误的。

在您的第一个查询中,MySQL 假设在索引中查找 = 比在索引中查找 like 更好(并且只会产生 9 行,这显然是不正确的)。在您的第二个查询中,它只需要选择在第一个或第二个索引中查找 like 是否更好 - 并且猜对了。但是,如果您愿意,例如寻找userinfo.mobilephone LIKE '0%',它可能会更慢(取决于您的数据)。

您可以尝试一些事情:

使用optimize table userinfo, radcheck, radusergroup。这将重新创建您的索引和统计信息。根据您的数据,它可能不再假设您的第一个查询只有 9 行。

使用STRAIGHT_JOIN 强制 mysql 始终按照您的第二个查询的顺序加入:

...
from radcheck
straight_join userinfo ON userinfo.username = radcheck.username
straight_join radusergroup ON userinfo.username = radusergroup.username
where ...

但这可能会在您正在寻找的情况下导致查询速度变慢,例如userinfo.mobilephone LIKE '0%',或者userinfo.mobilephone根本没有条件,所以在不同的情况下测试。

继续使用like 'Expiration%',如果你没有或只有一个短的手机要寻找,你甚至可以将它切换到=,但不能保证总是使用第二种方式(和可能会随着其他 mysql 版本而改变)。

顺便说一句,如果您将username-columns 替换为(整数)id,则可能会获得一些额外的性能,使其(第一部分)成为三个表的主键,然后使用这个id 加入你的表,因为你的索引会变小很多,你例如找到Expiration 的值后,不必查找用户名。这应该会减少您的第一个查询的执行时间(基于对您的表和数据的一些假设,我猜想超过 50% - 但这只是一个猜测,也可能只有 5%)。但是,由于它不能证明为此更改整个应用程序是合理的(尽管其他查询也会从中受益),所以当您必须对代码进行一些大的更改时,您可能会考虑它。 (您可以模拟其中的一部分并尝试通过添加索引radcheck(attribute, username) 是否值得努力,这应该为您的第一个查询提供 30%-50% - 假设 username 已经不是您的主键)

【讨论】:

radcheck(attribute) 上的索引也应该让 MySQL 意识到 attribute='Expiration' 条件不是很有选择性。

以上是关于Like和'='等于sql中的运算符性能 - mysql集群的主要内容,如果未能解决你的问题,请参考以下文章

SQL相关易忽略点

Hibernate Criteria API 中的 SQL 'LIKE' 运算符

Sql基础

SQL学习——LIKE运算符

类似于 SQL“like”的 JavaScript 运算符 [重复]

SQL WHERE 子句