MySQL处理记录数的极限是多少

[dongsheng]

最近处理一个大学的课程管理系统数据库，他们的一个日志表达到2000万行记录的水平，已经有了严重的性能问题，mysql有很多死掉的查询，请问MySQL何时会在记录数上出现瓶颈，有什么合适的解决办法吗？（这里不可能使用NoSQL）

[flytwokites]

我想是索引没有用好，打开mysql的慢查询功能看看哪些sql有性能问题。

[sophon]

可以考虑做下拆表

[dongsheng]

@flytwokites 索引没问题，第一件事就是检查了索引

[virushuo]

我听说过的最大表里面有几个亿，每天增量还在百万级别

[dongsheng]

@virushuo 这种量级的数据库用的是哪种引擎？INNO DB能抗得住吗？

公司有个非常繁忙的网站是把数据库放到内存里了，这才抗得住频繁的查询。

[muxi]

2000w而已，不至于出现什么瓶颈，我所用过的表多的会有10亿+的记录，像你这种日志表，只要有足够的内存（我一般给MySQL 8G以上的内存）、查询能使用主键或者索引应该不会出现什么问题，或许你换成Innodb引擎会更快一点，而且大学的课程管理系统，应该不会有很大的并发量，超级大的表，一般慢在磁盘和CPU上，或许你可以换个好点的服务器，如果你熟悉MySQL的话， 最新的5.5版本应该能显著提升你系统的性能

[liwei]

@dongsheng 我觉得这个不是MySQL处理数据的极限限制，而是受你查询复杂程度的限制。单表带索引的查询，在上亿的数据量上还是很快的

[dongsheng]

@muxi 现在最大的问题是日志表的查询非常非常频繁，因为这个系统非常依赖日志表显示来显示课程的中最近的活动，大量的查询都卡死在这里，导致很多页面都打不开。数据量可能跟你说的10亿没法比，但这个大学对该系统依赖非常高，所有的授课和考试都通过这个系统进行，并发很大。

可能真的让他们升级硬件或者升级MySQL（现在是5.0），我个人和他们都不倾向升级软件，数据量极大，可能得折腾一星期，还可能耽误授课计划。还有个烦人的问题是升级mysql还要升级linux，mysql5.5用的是新glibc，升级系统要走的流程就更多了，烦。

多谢你的建议。

[dongsheng]

@liwei 全是简单查询，所以我才怀疑是不是到极限了

[Livid]

@dongsheng 如果不涉及什么特别敏感的信息的话，你可以把那张表的结构定义（包括所有的索引的定义）发到 gist 然后分享给大家看看。

[e6nian]

大学的选课系统都是悲剧。
某些得体的老湿基本上都是被"秒杀"

[dongsheng]

@Livid 谢谢

Gist: https://gist.github.com/907013

Indexes: http://cl.ly/0C2X3s3U2Z213J0e3b0Z

这个表完全没有join查询，都是直来直去的

[TheOnly92]

主要是做何种查询？

[dongsheng]

@TheOnly92
比如
SELECT COUNT(*) FROM log;
SELECT * FROM log WHERE course=1 AND module=2 AND action="view";

[Livid]

@dongsheng 先说一个我觉得奇怪的地方：

bigint(10)

你们的应用中会出现超过 32 位范围的 64 位整数么？如果不会的话，把所有的 bigint 改成 int 可以节约内存。

另外，bigint 的长度应该是 20 而不是 10。

[TheOnly92]

这个时候做些 alter table 会卡掉整个系统吧

那两个查询的执行时间是多少？

[Livid]

@TheOnly92 @dongsheng 嗯，如果在目前这样的数据规模下做 alter 确实会锁表至少一个小时以上，所以一定慎重。

[flytwokites]

象
SELECT * FROM log WHERE course=1 AND module=2 AND action="view";
这类语句应该做个组合索引。

[dongsheng]

@flytwokites 这个做了，你看我发的截图。

[dongsheng]

@TheOnly92 这个我用mysql客户端执行是瞬间完成的，问题是当并发大的时候，很多这种查询会死掉，用show processlist会看到很多SELECT COUNT(*) FROM log; 锁死在那里了。