题图来自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的探索与实践，持续迭代中。
欢迎评论、点赞、收藏、关注。
