题图来自APOD

上次写了一篇MySQL优化实战的文章“MySQL千万级数据从190秒优化到1秒全过程”。

这篇文章主要还是在实战MySQL优化，所以从造数据到查询SQL优化SQL都没有业务或者其它依赖，优化的技巧也不涉及软件架构就是纯SQL优化。

由于笔者经验有限和篇幅限制没有展开讲很多细节，其中有很多争议的地方也在原帖进行了回复。

通过大家的讨论学习到很多东西。有句话在技术学习这块说的挺好，“一个人走的慢，一群人走的快”。通过讨论可以发现MySQL千万数据的全貌大概是怎样的。

以下enjoy~

千万数据的信息

原帖中实际产生的数据量有1500W行数据，以下基于此说明。

名称	说明
行数	1500W
磁盘大小	字段少，接近2GB
单表查询时间	查询快
关联查询时间	查询很慢

《阿里巴巴Java开发手册》有这么一条规约：

【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

千万级数据在互联网公司是推荐分表的。笔者从事的传统行业千万级的大表还是很常见的~

笔者由此得出“千万级数据对于MySQL来说就是不太合理的一个存在”，至于是否合理也是仁者见仁智者见智了~

怎么优化的

• 怼索引
• 怼覆盖索引
• 小表驱动大表
• 强制索引
• 减少数据量

优化技巧中，其中有的有效、有的没效果。

尤其是很多优化技巧涉及到千万级才会出现，也就是隐藏技巧，比如强制索引。最实用的还是覆盖索引。

有些技巧只是提及没有实际操作。以后会按照这种方式展展开写，欢迎关注。

大家怎么说

反向逻辑的

方向操作主要就是反PUA了，虽然写的文章水平一般，但是这波方向操作我是佩服的~
虽然技术确实能实现需求，但常在职场主打的一个就是身心愉悦~

• 软件层面优化不了，那就交给硬件，硬件层面优化不了，那就交给人力

• 你记住代码和人有一个能跑就行

• 老板说，优化不了代码我们就优化需求，优化不了需求我们就优化客户

• 千辛万苦优化到1秒，领导来了一句：“谁让你这么改的？给我改回去！”

• 哈哈哈，甲方还没提需求，你就给我优化了，谁给钱啊

• 迟早都是Oracle收割的韭菜

• 我有5亿钱包数据，怎么优化都打不到秒出！

反对的

这个意见没毛病，千万数据在MySQL也很常见。
但是笔者在阿里云做过验证，配置是8核心16G内存，同样的脚本在阿里云MYSQL中验证最少还是需要3s+
单机MYSQL千万数据看来确实是很多业务无法允许的瓶颈了～

• 哈哈，需求从“统计每个用户的订单总额”，变成“统计某几个用户的订单总额”，你小子是懂优化的

• 优化不了就改需求是吧？优化思路是不对的，最后输出结果都不一样了

• 抛开需求谈设计就是耍流氓…

• 最后一部分，真 到了一秒

• 单表千万数据量没什么不合理的，一次group by出所有的用户不分页才不合理。

• 那是你们家的mysql支持不了单表1000w。我们家的可以，而且速度还很好。

支持的

主打的就是实战优化技巧，希望多多输出_{学习输出实战才能闭环增长呢}

• 本身这种全量查询大量数据的需求就不合理，当然是要优化业务了

• 虽然但是哈哈哈哈 但是你这个文章给出的SQL和存储过程都可以直接使用并且调试步骤都有，拿来试试玩玩涨涨操作知识也挺好的呀~ 支持~

技术类的

这部分讨论主要停留在技术层面，软件硬件优化还是有很多的，可以看出平台里面还是很多潜水大牛的~

• 我记得mysql的join缓冲区，有个设置，调大点，join效率会有明显提升

• 是的 但是一般都有自适应

• 数据库级别优化本来就是有极限的，最终都得靠应用级别优化

• 个人习惯先用小表驱动大表, 添加索引和减少数据量进行优化。因为覆盖索引添加了查询的列很多时候只优化了当下的查询，但如果有很多相类似的sql要查询就很容易创建越来越多列，查询时间又没有减少

• 千万级的数据量得用分库分表，还要用缓存，光索引是没有用的，在想啥呢

• mysql适合互联网科技服务的业务场景，就是用户只看自己的数据，联表业务场景不多的情况。要是来一个传统企业级数据场景就难搞了，比如银行流水数据，企业内部财务订单数据，几个千万级的大表级联就很慢很慢了，这时候还是推荐上oracle和sqlserver商业数据库了，再不济也得来个pg。免费mysql存储海量数据的代价是人员成本高，硬件授权虽贵，但现在开发人员工资也不低。

• 之前测试过阿里云的mysql，8c16g ssd 配置，1.2亿条数据 查询 23 毫秒，感觉阿里云有点厉害

• 同样的脚本在阿里云MYSQL中验证最少还是需要3s+～配置是8核心16G内存，单机MYSQL千万数据看来确实是很多业务无法允许的瓶颈了～

• 首先，MySQL千万数据，在MySQL8.0以上的版本默认配置下轻松驾驭。除非你是7年以上的老服务器，或者是虚拟机，或者你本地点测试。分区优化后，2000万性能损失也不大。隔壁部门单表5000万了，还在叠加。另外，文章整体不错，点赞！还有，分表慎用，切勿只为数据分流而分表。

• 还有物理配置也算一个

• MySQL没碰到，二十多年前，在Oracle上遇到，新系统，全系统初始化库存的时候，同事写的脚本，要执行六个小时，调整了下，大概不到二十分钟。

他山之石

文章确实还有很多完善的地方，比如硬件配置是性能测试的基准没有体现出来。

MySQL千万数据究竟大吗？结论是大但不是天花板。

不是关系型数据库的天花板也不是软件优化的天花板。

但是怎么说，MySQL作为被Oracle收购的一个开源软件，更像是一个弃子一样，所以各大云服务厂商都优化和迭代了MySQL，性能好很多~

软件的分层设计很重要，缓存、软件、代理、持久化每个环节的综合设计可以让软件很能打，平摊各个环节的取舍也就降低了风险~

关于作者

来自一线全栈程序员nine的探索与实践，持续迭代中。

欢迎评论、点赞、收藏、关注。