大数据量查询慢的问题

[昆泽]

select * from tablea where post_date>"XXXXXX"

类似这样的条件查询语句，当数据库表的量比较大以后（比如几百万），执行速度会非常慢。

有什么办法改进吗？

数据库是mysql 引擎是myisam

加索引没有用，已经试过。

[zjsQQ]

象你这样的语句，本身就有些问题。
select * from tablea where post_date>"XXXXXX"
就算对post_date建立了索引，用explain观察type最多也是range级别。如果不建立索引，type是ALL。

当MySQL估计检查的行数可能会”太多”，范围查找优化将不会被使用。尤其是上百万比较明显。
建议换种思路。

[rucypli]

post_date加索引

[liuxinran819]

对这个语句唯一能做的就是给post_date加索引。
但是你确定你的应用程序需要所有这么多条数据吗？建议从应用程序入手，减少获取的行数~

[setail]

如果所得到结果的数据量大的话加不加索引效果都一样，查询的时候都不会使用索引。

[ACMAIN_CHM]

先添加post_date索引吧。

[沉沦]

当你查询大量数据时,index是没用的.

[昆泽]

[Quote=引用 1 楼 zjsqq 的回复:]

象你这样的语句，本身就有些问题。
select * from tablea where post_date>"XXXXXX"
就算对post_date建立了索引，用explain观察type最多也是range级别。如果不建立索引，type是ALL。

当MySQL估计检查的行数可能会”太多”，范围查找优化将不会被使用。尤其是上百万比较明显。
建议换种思路。
[/Quote]

那如果对于这样大数据量的表，我想得到插入时间大于某一个时间的所有行的行数，应该怎么来做呢。

[zjsQQ]

[Quote=引用 6 楼 lzcwxc1986 的回复:]

引用 1 楼 zjsqq 的回复:

象你这样的语句，本身就有些问题。
select * from tablea where post_date>"XXXXXX"
就算对post_date建立了索引，用explain观察type最多也是range级别。如果不建立索引，type是ALL。

当MySQL估计检查的行数可能会”太多”，范围查找优化将不会被使用。尤其是上百万比较明显。
建……
[/Quote]
第一种办法是：
如：
获取2011-07-27之前的数据，那么，你可以先获取前几天的数据出来，没必要用大于或小于号，直接用等号。
这样的话，查询速度应该极大提升。也会带来一点的问题。如逻辑要求会更加高。
第二种办法是：
分区。分区有好多种。我没记错，应该可以按时间分区。你可以去了解下。

[昆泽]

[Quote=引用 7 楼 zjsqq 的回复:]

引用 6 楼 lzcwxc1986 的回复:

引用 1 楼 zjsqq 的回复:

象你这样的语句，本身就有些问题。
select * from tablea where post_date>"XXXXXX"
就算对post_date建立了索引，用explain观察type最多也是range级别。如果不建立索引，type是ALL。

当MySQL估计检查的行数可能会”太多”，范……
[/Quote]

是指查询的结果很多，还是指需要查询的表的行数太多呢？

[昆泽]

[Quote=引用 8 楼 m582445672 的回复:]

当你查询大量数据时,index是没用的.
[/Quote]

是指查询的结果很多，还是指需要查询的表的行数太多呢？

[zuoxingyu]

1：post_date上加索引
2：查询时，通过索引，可以直接定位到最后一行的INDEX位置（你用的是>）,然后通过索引，去对应的磁盘位置把数据找出来，拼装。如果数据存的都是有序的，那么磁盘扫描是顺序扫描，速度很快。如果数据是无序的，比如（1,4，6100，2，13,1，34324,0），那么磁盘扫描是随机的，就会比较慢。这时候可以试试

13.5.2.5. OPTIMIZE TABLE语法
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
如果您已经删除了表的一大部分，或者如果您已经对含有可变长度行的表（含有VARCHAR, BLOB或TEXT列的表）进行了很多更改，则应使用OPTIMIZE TABLE。被删除的记录被保持在链接清单中，后续的INSERT操作会重新使用旧的记录位置。您可以使用OPTIMIZE TABLE来重新利用未使用的空间，并整理数据文件的碎片。