MySQL解释异常

发布于 2024-08-04 06:37:39 字数 2903 浏览 6 评论 0原文

考虑以下查询:

select FEE_NUMBER
from CARRIER_FEE CF
left outer join CONTYPE_FEE_LIST cfl on CF.CAR_FEE_ID=cfl.CAR_FEE_ID and cfl.CONT_TYPE_ID=3
where CF.SEQ_NO = (
    select max(CF2.SEQ_NO) from CARRIER_FEE CF2 
    where CF2.FEE_NUMBER=CF.FEE_NUMBER 
    and CF2.COMPANY_ID=CF.COMPANY_ID 
    group by CF2.FEE_NUMBER) 
group by CF.CAR_FEE_ID 

在我的笔记本电脑上,这不会返回任何结果。在我的服务器上使用完全相同的(转储)数据库它确实返回结果。

如果我在我的笔记本电脑上运行 EXPLAIN,我会得到这个

| id | select_type        | table | type  | possible_keys                               | key                   | key_len | ref                    | rows | Extra                                        |
+----+--------------------+-------+-------+---------------------------------------------+-----------------------+---------+------------------------+------+----------------------------------------------+
|  1 | PRIMARY            | CF    | index | NULL                                        | PRIMARY               | 8       | NULL                   |  132 | Using where                                  | 
|  1 | PRIMARY            | cfl   | ref   | FK_CONTYPE_FEE_LIST_1,FK_CONTYPE_FEE_LIST_2 | FK_CONTYPE_FEE_LIST_1 | 8       | odysseyB.CF.CAR_FEE_ID |    6 |                                              | 
|  2 | DEPENDENT SUBQUERY | CF2   | ref   | FK_SURCHARGE_1                              | FK_SURCHARGE_1        | 8       | func                   |   66 | Using where; Using temporary; Using filesort | 

,而在我的所有其他服务器上,它会给出这个(注意 ref 列中的差异)

| id | select_type        | table | type  | possible_keys                               | key                   | key_len | ref                    | rows | Extra                                        |
+----+--------------------+-------+-------+---------------------------------------------+-----------------------+---------+------------------------+------+----------------------------------------------+
|  1 | PRIMARY            | CF    | index | NULL                                        | PRIMARY               | 8       | NULL                   |  132 | Using where                                  | 
|  1 | PRIMARY            | cfl   | ref   | FK_CONTYPE_FEE_LIST_1,FK_CONTYPE_FEE_LIST_2 | FK_CONTYPE_FEE_LIST_1 | 8       | odysseyB.CF.CAR_FEE_ID |    6 |                                              | 
|  2 | DEPENDENT SUBQUERY | CF2   | ref   | FK_SURCHARGE_1                              | FK_SURCHARGE_1        | 8       | odysseyB.CF.COMPANY_ID |   66 | Using where; Using temporary; Using filesort | 

如果我删除连接、子查询或最后一个分组依据,那么我会得到预期的结果结果。

我假设这是一个配置问题,但这不是我以前见过的问题。有谁知道这可能是什么原因造成的?

我的笔记本电脑运行的是 OSX 10.6 和 MySQL 5.0.41。另一台运行 OSX 10.5.7 和 MySQL 5.0.37 的笔记本电脑工作正常,运行 MySQL 5.0.27 的 Linux 服务器也是如此。

谁能解释一下使用 ref=func 的一个解释计划与使用 ref=odysseyB.CF.COMPANY_ID 的另一个解释计划之间的区别?

谢谢。

Consider the following query:

select FEE_NUMBER
from CARRIER_FEE CF
left outer join CONTYPE_FEE_LIST cfl on CF.CAR_FEE_ID=cfl.CAR_FEE_ID and cfl.CONT_TYPE_ID=3
where CF.SEQ_NO = (
    select max(CF2.SEQ_NO) from CARRIER_FEE CF2 
    where CF2.FEE_NUMBER=CF.FEE_NUMBER 
    and CF2.COMPANY_ID=CF.COMPANY_ID 
    group by CF2.FEE_NUMBER) 
group by CF.CAR_FEE_ID 

On my laptop this returns no results. Using exactly the same (dumped) database on my servers it does return results.

If I run an EXPLAIN on my laptop I get this

| id | select_type        | table | type  | possible_keys                               | key                   | key_len | ref                    | rows | Extra                                        |
+----+--------------------+-------+-------+---------------------------------------------+-----------------------+---------+------------------------+------+----------------------------------------------+
|  1 | PRIMARY            | CF    | index | NULL                                        | PRIMARY               | 8       | NULL                   |  132 | Using where                                  | 
|  1 | PRIMARY            | cfl   | ref   | FK_CONTYPE_FEE_LIST_1,FK_CONTYPE_FEE_LIST_2 | FK_CONTYPE_FEE_LIST_1 | 8       | odysseyB.CF.CAR_FEE_ID |    6 |                                              | 
|  2 | DEPENDENT SUBQUERY | CF2   | ref   | FK_SURCHARGE_1                              | FK_SURCHARGE_1        | 8       | func                   |   66 | Using where; Using temporary; Using filesort | 

Whereas on all of my other servers it gives this (note the difference in the ref column)

| id | select_type        | table | type  | possible_keys                               | key                   | key_len | ref                    | rows | Extra                                        |
+----+--------------------+-------+-------+---------------------------------------------+-----------------------+---------+------------------------+------+----------------------------------------------+
|  1 | PRIMARY            | CF    | index | NULL                                        | PRIMARY               | 8       | NULL                   |  132 | Using where                                  | 
|  1 | PRIMARY            | cfl   | ref   | FK_CONTYPE_FEE_LIST_1,FK_CONTYPE_FEE_LIST_2 | FK_CONTYPE_FEE_LIST_1 | 8       | odysseyB.CF.CAR_FEE_ID |    6 |                                              | 
|  2 | DEPENDENT SUBQUERY | CF2   | ref   | FK_SURCHARGE_1                              | FK_SURCHARGE_1        | 8       | odysseyB.CF.COMPANY_ID |   66 | Using where; Using temporary; Using filesort | 

If I remove either the join, the subquery or the last group-by then I get the expected results.

I'm assuming that this is a configuration issue, however it's not one that I've seen before. Does anybody know what might cause this?

My laptop is running OSX 10.6 with MySQL 5.0.41. Another laptop running OSX 10.5.7 and MySQL 5.0.37 works fine, as do the Linux servers running MySQL 5.0.27.

Can anyone explain the difference between one explain plan using ref=func and the other using ref=odysseyB.CF.COMPANY_ID?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

风苍溪 2024-08-11 06:37:39

在两台机器上:

mysql> SHOW CREATE TABLE CARRIER_FEE CF;

确保两个表 ENGINE 类型相同。

另外,由于您在出现错误的机器上使用 OS X 10.6?也许该操作系统上的数据类型具有与 10.5.x 不同的质量。

似乎人们与雪豹存在兼容性问题。尝试在 10.6 笔记本电脑上安装 MySQL 5.4。

http://forums.mysql.com/read.php? 10,278942,278942#msg-278942

On both machines:

mysql> SHOW CREATE TABLE CARRIER_FEE CF;

Make sure that both table ENGINE types are the same.

Also, since you are using OS X 10.6 on the machine having the error? Perhaps the data types on that OS have different qualities than 10.5.x.

Seems like people are having compatibility problems with snow leopard. Try installing MySQL 5.4 on your 10.6 laptop.

http://forums.mysql.com/read.php?10,278942,278942#msg-278942

卸妝后依然美 2024-08-11 06:37:39

我不知道为什么它会给出不同的结果。您没有完全相同的数据转储,因为 EXPLAIN 报告中报告的行数不同。我建议做一些更简单的查询来测试您的假设。

还要仔细检查您是否确实在两台服务器上执行完全相同的 SQL 查询。例如,如果您无意中将左外连接更改为内连接,则可能会使整个查询不返回任何结果。

顺便说一句,与您的问题无关,但我使用外连接解决了这些“每组最大行”类型的查询:

select FEE_NUMBER
from CARRIER_FEE CF
left outer join CARRIER_FEE CF2
  on CF.FEE_NUMBER = CF2.FEE_NUMBER and CF.COMPANY_ID = CF.COMPANY_ID 
     and CF.SEQ_NO < cf2.SEQ_NO
left outer join CONTYPE_FEE_LIST cfl 
  on CF.CAR_FEE_ID=cfl.CAR_FEE_ID and cfl.CONT_TYPE_ID=3
where CF2.SEQ_NO IS NULL 
group by CF.CAR_FEE_ID;

这种类型的解决方案通常比您当前使用的相关子查询解决方案快得多。我不认为这会改变查询的结果,我只是将其作为一个选项提供。

I don't know why it's giving different results. You don't have exactly the same data dump, since the row counts reported in your EXPLAIN reports are different. I'd recommend doing some simpler queries to test your assumptions.

Also double-check that you're really executing the exact same SQL query on both servers. For instance, if you inadvertently changed your left outer join to an inner join, that could make the whole query return no results.

BTW, tangential to your question but I solve these "greatest row per group" types of queries with an outer join:

select FEE_NUMBER
from CARRIER_FEE CF
left outer join CARRIER_FEE CF2
  on CF.FEE_NUMBER = CF2.FEE_NUMBER and CF.COMPANY_ID = CF.COMPANY_ID 
     and CF.SEQ_NO < cf2.SEQ_NO
left outer join CONTYPE_FEE_LIST cfl 
  on CF.CAR_FEE_ID=cfl.CAR_FEE_ID and cfl.CONT_TYPE_ID=3
where CF2.SEQ_NO IS NULL 
group by CF.CAR_FEE_ID;

This type of solution is often much faster than the correlated subquery solution you're currently using. I wouldn't think that could change the result of the query, I'm just offering it as an option.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文