企业大型网站建设要多少钱,做外文网站,找做网站找那个平台做,国外网站专题红黄题图来自APOD
上次写了一篇MySQL优化实战的文章“MySQL千万级数据从190秒优化到1秒全过程”。
这篇文章主要还是在实战MySQL优化#xff0c;所以从造数据到查询SQL优化SQL都没有业务或者其它依赖#xff0c;优化的技巧也不涉及软件架构就是纯SQL优化。
由于笔者经验有限和…
题图来自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存储海量数据的代价是人员成本高硬件授权虽贵但现在开发人员工资也不低。 之前测试过阿里云的mysql8c16g ssd 配置1.2亿条数据 查询 23 毫秒感觉阿里云有点厉害 同样的脚本在阿里云MYSQL中验证最少还是需要3s配置是8核心16G内存单机MYSQL千万数据看来确实是很多业务无法允许的瓶颈了 首先MySQL千万数据在MySQL8.0以上的版本默认配置下轻松驾驭。除非你是7年以上的老服务器或者是虚拟机或者你本地点测试。分区优化后2000万性能损失也不大。隔壁部门单表5000万了还在叠加。另外文章整体不错点赞还有分表慎用切勿只为数据分流而分表。 还有物理配置也算一个 MySQL没碰到二十多年前在Oracle上遇到新系统全系统初始化库存的时候同事写的脚本要执行六个小时调整了下大概不到二十分钟。
他山之石
文章确实还有很多完善的地方比如硬件配置是性能测试的基准没有体现出来。
MySQL千万数据究竟大吗结论是大但不是天花板。
不是关系型数据库的天花板也不是软件优化的天花板。
但是怎么说MySQL作为被Oracle收购的一个开源软件更像是一个弃子一样所以各大云服务厂商都优化和迭代了MySQL性能好很多~
软件的分层设计很重要缓存、软件、代理、持久化每个环节的综合设计可以让软件很能打平摊各个环节的取舍也就降低了风险~
关于作者
来自一线全栈程序员nine的探索与实践持续迭代中。
欢迎评论、点赞、收藏、关注。
