MySQL InnoDB 的性能问题讨论

光说不练没用的，有条件的朋友可以自己去试验，我在这里置疑的不是 MyISAM，连交易都不支持，就不讨论了，也不是查询，是 InnoDB 下的 Insert/Update/Remove 性能，Cache 只能解决小数据量的问题，大数据量是不够的，RAID 0+1 能解决问题吗，看有没有机会做个试验吧，我比较怀疑，没经历过导入几百万条 InnoDB 数据到最后看着文件尺寸 100KB 100KB 的增长，是没法体会痛苦的。

btw，MySQL 我前前后后断断续续用了 7 年。。。

说的是

这么说对于百万级的频繁写入的情况，innodb在I/O上会有一些不爽了吗？只接触过百万级频繁读少量写的，没有做过准确调研到底比MyISAM慢多少。

http://www.mysqlperformanceblog.com/files/presentations/UC2005-Advanced-Innodb-Optimization.pdf

Peter Zaitsev, MySQL Inc.
– Senior Performance Engineer －－ 权威的牛人～
– MySQL Performance Group Manager
– MySQL Performance consulting and partner relationships


Very slow index creation (ALTER TABLE, LOAD DATA)
– Indexes are currently built row by row

BLOBs stored outside of the main row, in many pages
– Slower BLOB retrieval and much slower updates

Loading data or bulk inserts are much slower than MyISAM

UNIQUE keys are more expensive than non unique －－ 正好用到了
– Insert buffering does not work

Manual partitioning still make sense －－ 咣当～       
– ie users01, users02... users99
– Table locks is not the problem but ALTER TABLE is

网上有用户反映存在同样的插入性能问题，百万行记录插入之后，插入速度下降到了 1/30，从开始的 1600行/秒衰退到 50行/秒，同样的测试环境下，MyISAM 没有这样的问题。InnoDB 的 Roadmap 对此问题的时间表是“Long Term”。FeedLounge.com 也因为这个原因迁移到 PostgreSQL。

http://www.mail-archive.com/mysql@lists.mysql.com/msg99746.html

http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/

InnoDB 的风险因素：数据量是否会超过百万行的规模，是否需要 alter column/alter index/backup recovery。

有一个基于PostgreSQL 8.1.3专门为BI做了优化的数据库：bizgres

据chinaunix上一个兄弟的试用，性能比PostgreSQL 8.1有比较大幅度的提升。

SAP的效率可不敢恭维。去年一朋友公司准备上SAP，他用一台配置很好的PC来进行测试。只是基本系统，还没多少数据就慢的不行。后来总的测算下来，上SAP的成本非常大——不是指硬件，而是软件的改造成本太高，最后作罢。

MySql好像把MaxDB搁置了，不会在上面投入太多精力。Innodb估计也会淡出，只是目前还没有更好的替代引擎。

楼主设计的测试强调写操作性能，这对Innodb还是挺不利的。对于强调事务的应用，更重要的是重负下的交易完整性，以及数据可靠性。
我这里没有这么大的mysql数据库，也测试不了，不过，我们现在跑的oracle有近20G的数据了，导出再导入的速度也很慢。
要作这样的测试，得先对磁盘做个I/O测试，看看同等级的数据量下系统的极限I/O性能是多少，然后以这个基准跟数据库的测试的结果作对比。不然硬件的差异会影响测试结果。

题外话，据称裸设备下，性能是最好的，但是出了问题的时候，修复的难度也是最大的，所以也没去试过。

Craigslist 的数据库架构
这个，还有类似的Mysql的文章，至少说明在一定范围内，mysql还是够用的。

如果认为自己的数据库会控制在100G以下的话，MAXDB做SAP数据库是问题不大的，但最重要的是进行性能调优。

但这个帖子：
http://xsb.itpub.net/post/419/106223
中提到：MAXDB被SAP送给MySQL后，会被MySQL消化并消灭，可能未来只有一个MySQL



配置一台高性能的SAP系统需要专业的SAP BC做技术支持。
这样的技术人员需要对硬件(CPU、内存、磁盘阵列)、操作系统调优、内存管理、任务管理、数据性能调整有非常高的造诣。
空的SAP系统也有20G-30G的DB，如果是做DEMO用的IDES，新系统的DB就有100-150G。

另外，你“配置非常好的PC”是什么概念？SAP服务器的入门配置也要有2颗1.5G以上的CPU，2G以上内存
磁盘性能、数据库性能、SAP系统参数调整过了吗？

有位同志做了以下试验：
反驳"MySQL InnoDB (不行)的性能问题"，千万级别记录来测试说明
http://hi.baidu.com/jabber/blog/item/4df7e150a0df935c1138c202.html