Mysql大数据量条件下的性能优化

yueliangdao0608

原帖由 sunnyfun 于 2008-5-6 13:59 发表

当遇到海量数据的时候，分区会遇到走索引比扫表还慢的情况，因为索引会大到内存都放不下。
当然准备超大内存和磁盘阵列肯定是没错的了。

对极了。

gogo407

原帖由 talen-t 于 2008-5-5 22:57 发表
随便找了一个,读每天2000w,写每天1300w.so easy

talen-t的图表显示的write操作应该是是指数据更新操作，包括update和insert或者还有delete操作之类
如果lz每天需要insert 千万条 delete千万条，来回至少是2千万！

况且db是否有7千万行，或者大于7kw，也很难讲！希望能稍微指点，行数和服务器具体的硬件配置 ，如果可以的话大概数据库大小：）！

sunnyfun讲得似乎很有道理，但是我有点不能理解的是，如果分区走索引比扫表还慢的话，那这个索引的价值在哪里？（当然具体还要视需求来定）
还有就是如果内存里放不下这个索引了，那和分区不和分区的关系在哪里（反正分区和不分区都是放不下的)

呵呵，纯交流！希望朋友指点一下：）

angel1949

原帖由 sunnyfun 于 2008-5-6 13:59 发表

当遇到海量数据的时候，分区会遇到走索引比扫表还慢的情况，因为索引会大到内存都放不下。
当然准备超大内存和磁盘阵列肯定是没错的了。

大概多少数据会出现这样的情况呢？

xie995

小弟对Mysql不熟，只好将回复字数最多的选为最佳答案。大家有兴趣的话继续讨论。
我那个应用最大的问题大概的确是删除过期数据。过几天再继续测试这个问题。我现在先干另外的工作去了。领导多了也有些小问题，呵呵。
说实话我们这边有几个Oracle、Sybase 的高手。但对Mysql都不怎么精通。想用Mysql是为了省钱。我个人对各个数据库都不怎么精通，都只是用用而已。
其实我们公司有自己做的一个内存数据库，真要追求极致的速度的话会用内存数据库。现在对速度也没有要求到那份上。有些小项目也舍不得投入。
再次谢谢大家。欢迎继续讨论。

gogo407

原帖由 xie995 于 2008-5-6 21:33 发表
小弟对Mysql不熟，只好将回复字数最多的选为最佳答案。大家有兴趣的话继续讨论。
我那个应用最大的问题大概的确是删除过期数据。过几天再继续测试这个问题。我现在先干另外的工作去了。领导多了也有些小问题， ...

以回复字数......,有点汗！
不过我还是挺关注这个问题的，所以我也给出了自己的想法，和如果是我自己做的话采用的方法！
所以还是希望有经验的兄弟们能指点一，二。
：）

sunnyfun

原帖由 gogo407 于 2008-5-6 18:06 发表


talen-t的图表显示的write操作应该是是指数据更新操作，包括update和insert或者还有delete操作之类
如果lz每天需要insert 千万条 delete千万条，来回至少是2千万！

况且db是否有7千万行，或者大于7kw， ...

我只是对你之前引用我的那句话的意思做出解释。
大数据量时索引是定时炸弹，开始没啥甚至很爽，一但不能在内存命中，那就惨了。何时发生那种情况，就要看给索引多少内存了，兴许永远不会。

至于分区和不分区的关系很简单，没索引的话可以利用分区的“分区”扫表效果，不分区，扫表就算了。

至于删过期数据，如果是按日，RANGE分区的话，试试 DROP PARTITION 然后加个新的。

yueliangdao0608

原帖由 sunnyfun 于 2008-5-6 22:52 发表


我只是对你之前引用我的那句话的意思做出解释。
大数据量时索引是定时炸弹，开始没啥甚至很爽，一但不能在内存命中，那就惨了。何时发生那种情况，就要看给索引多少内存了，兴许永远不会。

至 ...

我是觉得分区还不如自己分表呢
如果自己分表的话，给一块表上的索引当然不可能超出内存的大小。

当时如果按照MYSQL的分区来做的话，最好不要建立索引。

gogo407

原帖由 sunnyfun 于 2008-5-6 22:52 发表


我只是对你之前引用我的那句话的意思做出解释。
大数据量时索引是定时炸弹，开始没啥甚至很爽，一但不能在内存命中，那就惨了。何时发生那种情况，就要看给索引多少内存了，兴许永远不会。

至 ...

挺认同的：）呵呵
关键还是得实际操作下：）

瀚海书香

回复 1# xie995


innodb与myisam引擎的本质区别是什么？
那个更适合大数据量的查询？

瀚海书香

回复 1# xie995
innodb与myisam引擎的本质区别是什么？
那个更适合大数据量的查询？