V2EX › whiteblack 的所有回复 › 第 2 页 / 共 2 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2

❮

❯

2015 年 4 月 17 日

回复了 delavior 创建的主题 › MySQL › 关于 mysql 读写速度疑问

@delavior 更正下，确实是会过滤数据
This is quite a misleading status. It should be called "reading and filtering data".

This means that MySQL has some data stored on the disk (or in memory) which is yet to be read and sent over. It may be the table itself, an index, a temporary table, a sorted output etc.

If you have a 1M records table (without an index) of which you need only one record, MySQL will still output the status as "sending data" while scanning the table, despite the fact it has not sent anything yet.

官方描述太有迷惑性了

2015 年 4 月 17 日

回复了 delavior 创建的主题 › MySQL › 关于 mysql 读写速度疑问

@delavior 不是过滤数据是去磁盘取数据

Sending data
The thread is processing rows for a SELECT statement and also is sending data to the client.

使用辅助索引则就不用去磁盘取数据，所有查询过程在index内部进行。

在innodb 中，主键是聚集索引，所以主键是和所有数据绑定在一起的，而非主键索引是独立于数据的，所以在count（）过程中，走非主键索引比主键索引效率更高。

2015 年 4 月 17 日

回复了 delavior 创建的主题 › MySQL › 关于 mysql 读写速度疑问

@delavior 你这个感觉是环境和磁盘的问题，sending data这个过程表示mysql 从磁盘中取回数据，然后发送给客户端，所以这个过程中可能有很多磁盘操作。
建议在一个非主键字段（字段长度选择小的，区分度高的）上建一个index，然后select count() 那个有非主键索引的字段，看下效果

2015 年 4 月 17 日

回复了 sujin190 创建的主题 › MySQL › mysql 查询 Copying to tmp table 疑问

@sujin190 用久了mysql 就知道了，这玩意全是坑。。。。已经不知道发现多少诡异的mysql问题，最后了解到是mysql的bug了。。。

2015 年 4 月 17 日

回复了 sujin190 创建的主题 › MySQL › mysql 查询 Copying to tmp table 疑问

DEPENDENT SUBQUERY 的问题，这里涉及到in的执行过程，具体看这篇博文

http://www.cnblogs.com/zhengyun_ustc/p/slowquery3.html

2015 年 4 月 16 日

回复了 delavior 创建的主题 › MySQL › 关于 mysql 读写速度疑问

这个就涉及到myisam 和 InnoDB数据结构问题了，
myisam会保存表的行数，所以不用count(*)直接
SELECT TABLE_NAME,TABLE_ROWS FROM
INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'database' and TABLE_NAME = "table"
就可以了

InnoDB则不同，他没有保存这个数据。

”InnoDB的数据文件本身要按主键排序，所以在创建InnoDB表时必须要有主键，如果没有显式指定，那么系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则系统自动为该表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。“

所以并不是主键的问题，即时你没有设置主键，mysql也会给你设置，而且从你的explain来看，type也是 index，使用了主键索引。

所以先show processlist查看这个是不是由于锁表导致的（一般来说不会，因为innodb使用多版本控制，一般select不会要求锁，除非是meta锁之类的坑）。

然后使用profiling 查看select语句每一步的耗时，分析性能瓶颈，查看可能的原因
随便搜的一个连接 http://www.cnblogs.com/adforce/archive/2012/06/02/2532287.html 里面有说明。

把结果贴上来在具体分析

1 2

❮

❯