请教一个MYSQL两表关联的效率问题。(每张表2000W条数据)

liukang520236 2012-06-29 04:51:10
我有A,B两张表。
A表有字段ID,A1,A2,A3....(2000W数据,没有主键,索引是ID)
B表有字段ID,B1,B2,B3....(2000W数据,没有主键,索引是ID)
B里面的ID都来自A里面的ID,但B里面的ID可能重复,有2,3的情况。

现在我关联两张表查询语句如下:
select count(*)
from A,B
where A.ID = B.ID

居然用了8个小时,这正常吗?
如果正常的话,怎么能调高查询效率。



...全文
705 24 打赏 收藏 转发到动态 举报
写回复
用AI写文章
24 条回复
切换为时间正序
请发表友善的回复…
发表回复
ilovepc 2013-11-04
  • 打赏
  • 举报
回复
楼主数据库引擎是用innoDB吧? 它查询count(*) 超级慢!
liukang520236 2012-07-03
  • 打赏
  • 举报
回复
谢谢楼上两位。。。我去修改程序了,结贴后面一并处理哈
liukang520236 2012-07-02
  • 打赏
  • 举报
回复
[Quote=引用 18 楼 的回复:]

没什么可优化的了。对于A表,总归是全表扫描,主要的优化是通过A查B的时候。你的B上ID已经有索引了。
[/Quote]
1000W 条数据双表关联就要10分钟吗?
我的个妈呀,这也太夸张了,
看来只能进行预处理一下,分表啦。。。
麻烦
ACMAIN_CHM 2012-07-02
  • 打赏
  • 举报
回复
没什么可优化的了。对于A表,总归是全表扫描,主要的优化是通过A查B的时候。你的B上ID已经有索引了。
ACMAIN_CHM 2012-07-02
  • 打赏
  • 举报
回复
数字肯定会快。 字符最长比较起来越慢。
WWWWA 2012-07-02
  • 打赏
  • 举报
回复
从15楼的结果来看,你已经创建了A表索引,SQL语句没有优化了,考虑分区表之类

explain select * from A,B where A.ID=B.id
结果如何
wwwwb 2012-07-02
  • 打赏
  • 举报
回复
[Quote=引用 20 楼 的回复:]

补充一个重要信息:我的ID是程序自动生成的,类似于下面这样:
ccf5d652-26eb-4692-a4ae-8ceafd9ca663
fcd16e39-42c1-460a-a38a-7f18828cc5dd
af370e48-b974-4c78-b0ac-48aad84747df


这样会对 A.ID=B.id 的判断产生很大的影响吗?
比如我简单的把ID搞成字增或者纯数字会……
[/Quote]
一般来讲,数字的速度要快一些
liukang520236 2012-07-02
  • 打赏
  • 举报
回复
补充一个重要信息:我的ID是程序自动生成的,类似于下面这样:
ccf5d652-26eb-4692-a4ae-8ceafd9ca663
fcd16e39-42c1-460a-a38a-7f18828cc5dd
af370e48-b974-4c78-b0ac-48aad84747df


这样会对 A.ID=B.id 的判断产生很大的影响吗?
比如我简单的把ID搞成字增或者纯数字会不会又能提高不少效率啊,各位亲。。。
liukang520236 2012-06-30
  • 打赏
  • 举报
回复
跑了一下SQL
结果如下

+----------+
| count(*) |
+----------+
| 18364876 |
+----------+
1 row in set (10 min 41.09 sec)

这正常吗?
liukang520236 2012-06-30
  • 打赏
  • 举报
回复
[Quote=引用 14 楼 的回复:]

先创建索引,然后再看你的

explain select count(*)
from A,B
where A.ID=B.id
[/Quote]
mysql> explain explain select count(*)
from A,B
where A.ID=B.id

+----+-------------+-------+-------+----------------+----------------+---------+----------------------+----------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+----------------+----------------+---------+----------------------+----------+--------------------------+
| 1 | SIMPLE | A | index | index_uniqueID | index_uniqueID | 452 | NULL | 18364876 | Using index |
| 1 | SIMPLE | B | ref | index_uniqueID | index_uniqueID | 453 | db.a.uniqueID | 1 | Using where; Using index |
+----+-------------+-------+-------+----------------+----------------+---------+----------------------+----------+--------------------------+--+----------------+---------+----------------------+----------+--------------------------+
ACMAIN_CHM 2012-06-29
  • 打赏
  • 举报
回复
先创建索引,然后再看你的

explain select count(*)
from A,B
where A.ID=B.id
liukang520236 2012-06-29
  • 打赏
  • 举报
回复
[Quote=引用 11 楼 的回复:]

检查 一下A表的索引情况
SHOW INDEX FROM a
[/Quote]

貌似是这个问题,我刚发现A的索引居然没有ID。。。。
Rotel-刘志东 2012-06-29
  • 打赏
  • 举报
回复
对于表的设计最好有主键的,这是设计一个原则?另外也能提高效率。
WWWWA 2012-06-29
  • 打赏
  • 举报
回复
检查 一下A表的索引情况
SHOW INDEX FROM a
Rotel-刘志东 2012-06-29
  • 打赏
  • 举报
回复
关键是数据库的缓存没有那么大?造成查询时磁盘的i/o消耗过大,从而导致查询时间过长。
liukang520236 2012-06-29
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 的回复:]

一般来讲,表中要有主键,建立主键试试
[/Quote]
我也在考虑这个问题,
A表的主键好说,可以用ID,因为ID不重复,
B表中主键是个问题啊,ID有可能重复。

A表和B表的ID几乎一样,2000W的数据量估计会有1W的不一样,不过这不是大问题吧?
Rotel-刘志东 2012-06-29
  • 打赏
  • 举报
回复
2000w 在4G下运行是有问题的。
liukang520236 2012-06-29
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 的回复:]

explain select count(*)
from A,B
where A.ID=B.id
贴出执行计划
[/Quote]


| id | select_type | table | type | possible_keys | key | key_len | ref
+----+-------------+-------+------+----------------+----------------+---------+---------------------
| 1 | SIMPLE | A | ALL | NULL | NULL | NULL | NULL
| 1 | SIMPLE | B | ref | index_uniqueID | index_uniqueID | 153 | databasename.A.uniqueID
liukang520236 2012-06-29
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 的回复:]

不正常
机器的性能如何?数据量多大?这都是有关系的。
表的设计有问题。
[/Quote]

普通的开发机器
CPU:i52400 3.1G
内存4G
WWWWA 2012-06-29
  • 打赏
  • 举报
回复
一般来讲,表中要有主键,建立主键试试
加载更多回复(4)

56,677

社区成员

发帖
与我相关
我的任务
社区描述
MySQL相关内容讨论专区
社区管理员
  • MySQL
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧