Question

我们正在使用MySql 5.5.37，Java 7和Hibernate 5.1.3。 Hibernate是自动生成查询，有一个让我感到困惑。我们有这些表......

 CREATE TABLE `user` (
  `ID` varchar(32) COLLATE utf8_bin NOT NULL,
  `FIRST_NAME` varchar(50) COLLATE utf8_bin NOT NULL,
  `MIDDLE_NAME` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `LAST_NAME` varchar(50) COLLATE utf8_bin NOT NULL,
  `USER_NAME` varchar(50) COLLATE utf8_bin NOT NULL,
  `URL` varchar(200) COLLATE utf8_bin NOT NULL,
  `SALUTATION` varchar(10) COLLATE utf8_bin DEFAULT NULL,
    ...
  `ADDRESS_ID` varchar(32) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `USER_IDX_01` (`USER_NAME`,`URL`),
  KEY `FK2_USER` (`GRADE_ID`),
  KEY `FK4_USER` (`USER_DEMOGRAPHIC_INFO_ID`),
  KEY `FK3_USER` (`CREATOR_ID`),
  KEY `FK_USER` (`ADDRESS_ID`),
  CONSTRAINT `FK2_USER` FOREIGN KEY (`GRADE_ID`) REFERENCES `grade` (`ID`),
  CONSTRAINT `FK3_USER` FOREIGN KEY (`CREATOR_ID`) REFERENCES `user` (`ID`) ON UPDATE NO ACTION,
  CONSTRAINT `FK_USER` FOREIGN KEY (`ADDRESS_ID`) REFERENCES `cb_address` (`ID`) ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |

和

role | CREATE TABLE `role` (
  `ID` varchar(40) COLLATE utf8_bin NOT NULL,
  `NAME` varchar(40) COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `ROLE_IDX_01` (`NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |

我们将他们与联接表一起加入

user_role | CREATE TABLE `user_role` (
  `USER_ID` varchar(32) COLLATE utf8_bin NOT NULL,
  `ROLE_ID` varchar(40) COLLATE utf8_bin NOT NULL,
  UNIQUE KEY `USER_ROLE_IDX_02` (`USER_ID`,`ROLE_ID`),
  KEY `FK2_USER_ROLE` (`ROLE_ID`),
  CONSTRAINT `FK1_USER_ROLE` FOREIGN KEY (`USER_ID`) REFERENCES `user` (`ID`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `FK2_USER_ROLE` FOREIGN KEY (`ROLE_ID`) REFERENCES `role` (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |

但是当我们查询用户并在查询中包含角色时，MySql似乎忽略了索引。请注意解释计划中的“1688568”行。为什么MySQL不使用索引以及查询数据的更好方法是什么？

mysql> EXPLAIN     select  user0_.id as id1_112_, user0_.ADDRESS_ID as ADDRESS17_112_,
        user0_.AVATAR as AVATAR2_112_, user0_.CREATED_ON as CREATED_3_112_,
        user0_.CREATOR_ID as CREATOR18_112_, user0_.DOB as DOB4_112_,
        user0_.ENABLED as ENABLED5_112_, user0_.EXPIRATION as EXPIRATI6_112_,
        user0_.first_name as first_na7_112_, user0_.GRADE_ID as GRADE_I19_112_,
        user0_.INCORRECT_LOGINS as INCORREC8_112_, user0_.last_name as last_nam9_112_,
        user0_.middle_name as middle_10_112_, user0_.password as passwor11_112_,
        user0_.RESET_STATE as RESET_S12_112_, user0_.salutation as salutat13_112_,
        user0_.temporary_password as tempora14_112_, user0_.url as url15_112_,
        user0_.USER_DEMOGRAPHIC_INFO_ID as USER_DE20_112_, user0_.user_name as user_na16_112_
    from  user user0_
    inner join  user_role roles1_  ON user0_.id = roles1_.USER_ID
    inner join  role role2_  ON roles1_.ROLE_ID = role2_.ID
    inner join  cb_address address3_  ON user0_.ADDRESS_ID = address3_.id
    where  user0_.url = 'mycityst.myco.org'
      and  (role2_.ID in ('Student'))
      and  lower(address3_.email) = 'myemail@gmail.com'
      and  user0_.ENABLED = 1;

+----+-------------+-----------+--------+--------------------------------------+------------------+---------+---------------------------+---------+--------------------------+
| id | select_type | table     | type   | possible_keys                        | key              | key_len | ref                       | rows    | Extra                    |
+----+-------------+-----------+--------+--------------------------------------+------------------+---------+---------------------------+---------+--------------------------+
|  1 | SIMPLE      | role2_    | const  | PRIMARY                              | PRIMARY          | 122     | const                     |       1 | Using index              |
|  1 | SIMPLE      | roles1_   | ref    | USER_ROLE_IDX_02,FK2_USER_ROLE       | FK2_USER_ROLE | 122     | const                     | 1688568 | Using where; Using index |
|  1 | SIMPLE      | user0_    | eq_ref | PRIMARY,FK_USER                      | PRIMARY          | 98      | schema1.roles1_.USER_ID   |       1 | Using where              |
|  1 | SIMPLE      | address3_ | eq_ref | PRIMARY                              | PRIMARY          | 98      | schema1.user0_.ADDRESS_ID |       1 | Using where              |
+----+-------------+-----------+--------+--------------------------------------+------------------+---------+---------------------------+---------+--------------------------+

Answer 1

除了通过主键进行连接外，除了术语role2_.ID in ('Student'))之外，您没有可用于搜索条件的索引。因此，MySQL采用该术语，从表roles1_（表user_roles）开始（通过连接关系role2_.id = roles1_.role_id）查找使用索引FK2_USER_ROLE的所有学生（并估算）在该表中获得约160万行），然后通过主键加入其他表。

搜索

where user0_.url='mycityst.myco.org' 
and (role2_.ID in ('Student')) 
and lower(address3_.email)='myemail@gmail.com' 
and user0_.ENABLED=1;

您在user0_.url上缺少可用密钥（您在该表中只有(USER_NAME,URL)的索引），并且address3_.email上的潜在索引因lower()而无法使用1}} - 功能。（虽然你的addresstable描述不见了，所以目前还不清楚你是否有索引。）

作为快速修复，请为user0_(url)添加一个索引（可能包括enabled）。

您还应该重新考虑使用utf8_bin。它认为“A”与“a”不同。因此，如果您确实想要进行不区分大小写的搜索，则会阻止您使用索引，您通常希望对电子邮件，名称，地址或网址执行此操作。使用像lower(email)这样的函数也可以防止在该列上使用索引。因此，如果可能的话，请使用不区分大小写的排序规则替换您的列（例如utf8_unicode_ci，ci代表case insensitive）。

Answer 2

其他问题：

由于role的ID和NAME似乎都最多为40个字符，因此我建议删除role表并将ROLE_ID替换为ROLE_NAME无论发生在哪里。

然后在UNIQUE KEY中宣传PRIMARY KEY到user_role。

我没有看到address表，但我怀疑它的整理是utf8_bin？相反，如果它是utf8_unique_ci，那么您可以将其编入索引并更改

and  lower(address3_.email) = 'myemail@gmail.com'

到

and  address3_.email = 'myemail@gmail.com'

从而为优化器提供了一种更好的方式来启动查询。

关于

的问题

MySql似乎忽略了索引。请注意＆＃34; 1688568＆＃34;解释计划中的行。

正在使用索引;但是有关于＆＃34; 1688568＆＃34; ＆＃34;学生＆＃34;在表中。

你真正的问题是＆＃34;为什么它从role开始而不是更好的表？＆＃34;

MySQL将单项IN优化为=，将多项OR优化为IN。然而，优化程序仍然可能会选择其他索引，或者没有索引。＆＃34;不使用索引＆＃34;通常在索引值引用超过约20％的表时发生。

为什么MySql不使用我们表上的索引？

2 个答案: