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

V2EX = way to explore

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

For Existing Member Sign In

1 2

❮

❯

2015 年 10 月 7 日

回复了 Andor_Chen 创建的主题 › PHP › 送几本《Modern PHP（中文版）》

支持楼主，求中

2015 年 9 月 25 日

回复了 m90q0 创建的主题 › 分享创造 › 于是乎做了一个新番动画的导航与评分网站(´-ω-｀)

http://bangumi.tv/ 感觉有点像 bangumi 的简化版，建议楼主看看能不能发掘出点新方向

2015 年 6 月 25 日

回复了 mengli 创建的主题 › 大学 › 胡建志愿填报求推荐~~

来我华中可基大学吧，当年报的是华科中大华南理工，多到外面看看，挺好的

2015 年 6 月 24 日

回复了 sbmzhcn 创建的主题 › Python › 求开发一个这样的 python 程序，得多少钱？

为啥不用tornado，tornado自带HTTPserver啊。。。

2015 年 6 月 3 日

回复了 snopy 创建的主题 › Python › 关于 import 的一个语法问题，求解

from . import server_app, API_VERSION 这个对。
之所以出现这个问题是因为相对导入这个东西只作用于包，你 “..” 找到的是app的上级目录，如果这个目录不是一个包，当然就不行了，如果一定要用 “..” 则需要在app这个文件夹所属的目录加个 __init__.py，使他成为一个包即可。
所以重点就是相对导入这个东西，只能在包环境里面使用，出了包就不行了

2015 年 6 月 1 日

回复了 taoche 创建的主题 › 游戏 › 《武林群侠传》重制版《侠客风云传》今日预售

支持

2015 年 4 月 29 日

回复了 anai1943 创建的主题 › MySQL › mysql left join 多个 count 问题

那什么。。。这个执行的过程是先进行join连接，如果有多个join 则先进行前面一个，然后拿join的结果去执行后面的join，当所有join执行完毕后，然后拿着最后的结果集去select where ，所以你在select 里面count的都是“所有join执行完毕之后的结果集”，所以count的结果当然一样了

2015 年 4 月 23 日

回复了 wind3110991 创建的主题 › Linux › 昨天刚收到腾讯实习 Offer 了， TEG 技术工程网络后台开发方向的，请教大神推荐一些实习前充电的知识

@welling 广州没有teg吧，只有一部分mig在南通，还有wxg

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

❮

❯