Comments on: MySQL – to use or not to use http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: peter http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131862 peter Thu, 31 May 2007 14:32:23 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131862 Greg, We all know projects when MySQL works great. MySQL can be made to work in many cases when complex reporting queries is needed as MySQL often fails to optimize subselects properly only able to use nested loops join method this where a lot of problems happen. Same about lack of parallel query execution. Yet another showstopper I've seen is Innodb scaling issues. Second and Third classes are generally different by the state of the project and development team rather than workload. What is more complicated for you to invest time changing application and working around MySQL limitations or change the database engine all together ? People which were raised on MySQL typically choose to stick to MySQL and find workarounds, in case application is portable and not MySQL specific and development team is not highly invested in MySQL you would find using other DBMS being better option. For example O'reilly is typically using MySQL but has PostgreSQL in massively parallel setup for reporting application because application can run both MySQL and PostgreSQL and it is too much trouble to optimize queries automatically generated by third party application. Greg,

We all know projects when MySQL works great. MySQL can be made to work in many cases when complex reporting queries is needed as MySQL often fails to optimize subselects properly only able to use nested loops join method this where a lot of problems happen. Same about lack of parallel query execution. Yet another showstopper I’ve seen is Innodb scaling issues.

Second and Third classes are generally different by the state of the project and development team rather than workload. What is more complicated for you to invest time changing application and working around MySQL limitations or change the database engine all together ? People which were raised on MySQL typically choose to stick to MySQL and find workarounds, in case application is portable and not MySQL specific and development team is not highly invested in MySQL you would find using other DBMS being better option.

For example O’reilly is typically using MySQL but has PostgreSQL in massively parallel setup for reporting application because application can run both MySQL and PostgreSQL and it is too much trouble to optimize queries automatically generated by third party application.

]]> By: peter http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131861 peter Thu, 31 May 2007 14:25:06 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131861 Pavel, Do you have a test case where MySQL 5.0 is 60% slower. If yes please report it as a bug and let me know. Making regressions public is one of best ways to get attention to them and have them fixed. Pavel,

Do you have a test case where MySQL 5.0 is 60% slower. If yes please report it as a bug and let me know. Making regressions public is one of best ways to get attention to them and have them fixed.

]]> By: Greg http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131827 Greg Thu, 31 May 2007 08:35:02 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131827 As ever Peter, I love reading your blog. In this article, you state 3 categories: "There are many applications when MySQL works great, when there are some of applications when MySQL can be made to work and there are finally cases when MySQL limitations are not worth the trouble" - I'm curious what kinds of project you'd put in each. Actually, I'm curious what kinds of project you'd put into each of the last two. As ever Peter, I love reading your blog. In this article, you state 3 categories: “There are many applications when MySQL works great, when there are some of applications when MySQL can be made to work and there are finally cases when MySQL limitations are not worth the trouble” – I’m curious what kinds of project you’d put in each. Actually, I’m curious what kinds of project you’d put into each of the last two.

]]> By: Pavel http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131731 Pavel Wed, 30 May 2007 14:50:11 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131731 I agree. We are using MySQL 4.0 with over 5000 q/s traffic (simple inserts/updates). Now it runs smoothly on three years old dual Xeon/3GHz @ 30-40% CPU time. When we tried to upgrade to MySQL 5.x we lost about 60% of performace. No way to upgrade. Because it is unsupported we have to compile from source now. Or have to find another solution (another simple database engine). I agree. We are using MySQL 4.0 with over 5000 q/s traffic (simple inserts/updates). Now it runs smoothly on three years old dual Xeon/3GHz @ 30-40% CPU time. When we tried to upgrade to MySQL 5.x we lost about 60% of performace. No way to upgrade.

Because it is unsupported we have to compile from source now. Or have to find another solution (another simple database engine).

]]> By: Nils http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131664 Nils Wed, 30 May 2007 06:54:05 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131664 MySQL 5.0 sure was a milestone and really brought up many new and great featured, mostly those the guys claiming MySQL is a "toy database" used as argument. This with Subqueries being an exception, but most people I know who needed subqueries just didn't know how to do proper joins ;) Mostly, the new features in MySQL 5.0 seem to be unnoticed by the public and I've not yet seen widespread use. I think many projects need compatibility to MySQL 4.1 or even 4.0, especially open source applications. Also I think many of those who say that MySQL lacked triggers, stored procedures, views and so on didn't really want to use it - it is not a real showstopper - they just wanted to say why they like their favourite rdbms more. I didn't see many cases where the featureset of the DBMS were the showstopper, rather the creativity and skills of the developers. And then you can still hire a consultant ;) Speaking of simplicity, the fine thing is from what I see now, you can live fine without partitioning, views, triggers, stored procedures for most applications - but if you need them, they are there. I recently started to upgrade my old 4.1 servers to 5.0. One thing I learned the hard way is that you should dump and restore the tables, rather than letting the upgrade script upgrade them, it seemed to be far slower and raised innodb tablespace size severely. The reasons for the upgrade where: - MySQL 4.1 has been out of life for a long time now, and no recent debian packages where provided, with 4.1.14 being the newest - I want to use profiling to check for possible optimizations - I want to use triggers for some stuff that is currently being done by cronjobs (creating some search index tables on slaves) I also started linking in the google performancetools tcmalloc library, will be interesting to see the speed impact. MySQL 5.0 sure was a milestone and really brought up many new and great featured, mostly those the guys claiming MySQL is a “toy database” used as argument. This with Subqueries being an exception, but most people I know who needed subqueries just didn’t know how to do proper joins ;) Mostly, the new features in MySQL 5.0 seem to be unnoticed by the public and I’ve not yet seen widespread use. I think many projects need compatibility to MySQL 4.1 or even 4.0, especially open source applications.

Also I think many of those who say that MySQL lacked triggers, stored procedures, views and so on didn’t really want to use it – it is not a real showstopper – they just wanted to say why they like their favourite rdbms more. I didn’t see many cases where the featureset of the DBMS were the showstopper, rather the creativity and skills of the developers. And then you can still hire a consultant ;)

Speaking of simplicity, the fine thing is from what I see now, you can live fine without partitioning, views, triggers, stored procedures for most applications – but if you need them, they are there.

I recently started to upgrade my old 4.1 servers to 5.0. One thing I learned the hard way is that you should dump and restore the tables, rather than letting the upgrade script upgrade them, it seemed to be far slower and raised innodb tablespace size severely.

The reasons for the upgrade where:
- MySQL 4.1 has been out of life for a long time now, and no recent debian packages where provided, with 4.1.14 being the newest
- I want to use profiling to check for possible optimizations
- I want to use triggers for some stuff that is currently being done by cronjobs (creating some search index tables on slaves)

I also started linking in the google performancetools tcmalloc library, will be interesting to see the speed impact.

]]> By: Klettergriffe onlineshop http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131430 Klettergriffe onlineshop Mon, 28 May 2007 21:05:22 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131430 MySQL is NOT easy to install. when you dont know it, you cant install it. I am one of these Dummies. See you, peter :-) MySQL is NOT easy to install.

when you dont know it, you cant install it.

I am one of these Dummies.

See you,

peter :-)

]]> By: peter http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131415 peter Mon, 28 May 2007 17:35:11 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131415 Rafe, This is right. MySQL is easy to install and get going and installation is as easy with 5.0 as it was with 3.23. What I mainly mean is feature set - MySQL 5.0 has a lot of complex stuff such as triggers, views, stored procedures. True you do not have to use them. However if you're newcomer and charged with supporting MySQL 5.0 applications you may end up learning a lot of stuff even if you used MySQL a lot before. Rafe,

This is right. MySQL is easy to install and get going and installation is as easy with 5.0 as it was with 3.23.

What I mainly mean is feature set – MySQL 5.0 has a lot of complex stuff such as triggers, views, stored procedures.
True you do not have to use them. However if you’re newcomer and charged with supporting MySQL 5.0 applications you may end up learning a lot of stuff even if you used MySQL a lot before.

]]> By: Rafe http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/comment-page-1/#comment-131405 Rafe Mon, 28 May 2007 16:37:57 +0000 http://www.mysqlperformanceblog.com/2007/05/28/mysql-to-use-or-not-to-use/#comment-131405 I don't know about the complexity bit. MySQL can do a lot more than it used to, but I just built and installed MySQL 5.0 on a FreeBSD box and migrated my old 4.1 database over to it with no more trouble than I used to have with version 3.2.x. I don’t know about the complexity bit. MySQL can do a lot more than it used to, but I just built and installed MySQL 5.0 on a FreeBSD box and migrated my old 4.1 database over to it with no more trouble than I used to have with version 3.2.x.

]]>