Comments on: Why MySQL could be slow with large tables ? http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Cristina Fon http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-884423 Cristina Fon Thu, 02 Feb 2012 12:09:25 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-884423 Need help! I was on a windows server with mysql and get faster and moved to a linux machine with 24 G of memory. It was very slow and the process that ran on another machine that took 1 hour this is 6 hours. The tables are large and when I select a table that is locked to insert. Someone could help me, perhaps the my.cnf configuration, the team was named the server my.cnf for large tables. Thank you Need help! I was on a windows server with mysql and get faster and moved to a linux machine with 24 G of memory. It was very slow and the process that ran on another machine that took 1 hour this is 6 hours. The tables are large and when I select a table that is locked to insert. Someone could help me, perhaps the my.cnf configuration, the team was named the server my.cnf for large tables. Thank you

]]> By: francis http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-883654 francis Tue, 31 Jan 2012 16:57:11 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-883654 i also have problems with my queries i tried to optimized mysql using the explain and i got 1 row result per table except the master table in which it has 13,000 records. i joined 6 tables and the result using explain is Tables Result master 130000 Sorting, temporary... subrtable 1 overal records is 20 subtable2 100 overal records is 100 subtable3 1 - overal records is 13,0000 subtable4 1 - the overall records of this is more than 100 thousand records running the query with subtable4 took 36 - 59 secs running the query without took 6 secs i want to have at less 1 sec run per query. any help is very much appreciated thanks i also have problems with my queries i tried to optimized mysql using the explain and i got 1 row result per table except the master table in which it has 13,000 records. i joined 6 tables and the result using explain is

Tables Result
master 130000 Sorting, temporary…
subrtable 1 overal records is 20
subtable2 100 overal records is 100
subtable3 1 – overal records is 13,0000
subtable4 1 – the overall records of this is more than 100 thousand records

running the query with subtable4 took 36 – 59 secs
running the query without took 6 secs

i want to have at less 1 sec run per query. any help is very much appreciated thanks

]]> By: Michael http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-862673 Michael Fri, 23 Dec 2011 21:22:56 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-862673 So joins are good if selecting only a few items, but probably not good if selecting nearly an entire table (A) to then be joined with nearly another table (B) in a one-to-many join? I'm considering doing this with a 1 min cron. But, would this (nearly full table joins within a script that runs frequently) be a case were it'd be better to store a small amount of data from table B (the "many"; five or six items; thresholds for notifications actually) as *serialized* data within Table A? Are huge joins or serialization the greater evil? (I've been struggling with this one for about a week now.) So joins are good if selecting only a few items, but probably not good if selecting nearly an entire table (A) to then be joined with nearly another table (B) in a one-to-many join?

I’m considering doing this with a 1 min cron. But, would this (nearly full table joins within a script that runs frequently) be a case were it’d be better to store a small amount of data from table B (the “many”; five or six items; thresholds for notifications actually) as *serialized* data within Table A?

Are huge joins or serialization the greater evil?

(I’ve been struggling with this one for about a week now.)

]]> By: Toko Bunga http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-839306 Toko Bunga Fri, 11 Nov 2011 03:14:25 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-839306 Did the reason is normally table design and understanding inner works of MySQL? Did the reason is normally table design and understanding inner works of MySQL?

]]> By: Toko Bunga http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-839299 Toko Bunga Fri, 11 Nov 2011 03:00:01 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-839299 Processing in memory is so much faster and you have whole bunch of problems solved just doing so. Use multiple servers to host portions of data set. Store portion of data you’re going to work with in temporary table etc. Processing in memory is so much faster and you have whole bunch of problems solved just doing so. Use multiple servers to host portions of data set. Store portion of data you’re going to work with in temporary table etc.

]]> By: Sebastian Knopp http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-833260 Sebastian Knopp Sat, 22 Oct 2011 06:31:23 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-833260 @ankit: replications? you could use your master for write queries like, update or insert and the slave for selects. that should increase the speed dramatically. @ankit: replications? you could use your master for write queries like, update or insert and the slave for selects. that should increase the speed dramatically.

]]> By: ankit http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-832017 ankit Mon, 17 Oct 2011 12:36:24 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-832017 I have 10GB MYISAM table . My website has about 1 million hits daily . Under such a heavy load the SELECT and inserts get slowed . I have the below solutions in mind : 1. Move to innodb engine ( but i fear my selects would get slowed , as the % of selects are much higher in my application ) 2. Upgrade to 5.0+ ( currently i am on 4.0) 3. Partition my tables ( i.e. break my table data into mutliple smaller tables , but this would make thigs very difficult for me to handle) Can anybody help me in figuring out a solution to my problem . I have 10GB MYISAM table . My website has about 1 million hits daily . Under such a heavy load the SELECT and inserts get slowed . I have the below solutions in mind :
1. Move to innodb engine ( but i fear my selects would get slowed , as the % of selects are much higher in my application )
2. Upgrade to 5.0+ ( currently i am on 4.0)
3. Partition my tables ( i.e. break my table data into mutliple smaller tables , but this would make thigs very difficult for me to handle)

Can anybody help me in figuring out a solution to my problem .

]]> By: Greg http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-824804 Greg Fri, 23 Sep 2011 21:29:37 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-824804 "fit your data into memory" in a database context means "have a big enough buffer pool to have the table/db fit completely in RAM". In InnoDB, have innodb_buffer_pool_size > the size of your database (or at least your table). In MyISAM, it's a bit trickier, but make sure key_buffer_size is big enough to hold your indexes and there's enough free RAM to load the base table storage into the file-system cache. Obviously, this gets expensive with huge databases, but you still want to have a good percentage of the db in RAM for good performance. “fit your data into memory” in a database context means “have a big enough buffer pool to have the table/db fit completely in RAM”. In InnoDB, have innodb_buffer_pool_size > the size of your database (or at least your table). In MyISAM, it’s a bit trickier, but make sure key_buffer_size is big enough to hold your indexes and there’s enough free RAM to load the base table storage into the file-system cache.

Obviously, this gets expensive with huge databases, but you still want to have a good percentage of the db in RAM for good performance.

]]> By: joe http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-823837 joe Tue, 20 Sep 2011 17:26:13 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-823837 You need a lot of work on your technical writing skills. Most of your sentences don't pass as "sentences". "So you understand how much having data in memory changed things here is small example with numbers." -OMG How you obtained a masters degree is beyond me. You need a lot of work on your technical writing skills. Most of your sentences don’t pass as “sentences”.

“So you understand how much having data in memory changed things here is small example with numbers.” -OMG

How you obtained a masters degree is beyond me.

]]> By: Alam Florist http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/comment-page-3/#comment-809709 Alam Florist Sat, 06 Aug 2011 03:41:50 +0000 http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/#comment-809709 i think indexes can fix the problem. i think indexes can fix the problem.

]]>