MySQL Forums :: Partitioning :: large InnoDB table partitioning without explicit PK


Advanced Search

Re: large InnoDB table partitioning without explicit PK
Posted by: Miko M ()
Date: November 16, 2014 08:31PM

Many thanks for your hints again.

It seems that query_cache_size does not work the way it is supposed to. However I did not even try to check/analyse it since 8MB seems to be nothing with the all RAM available.

Regarding Select_scan / Com_select - (relatively high) number of full table scans, there was a select statement such as select count(*) from table1.... executed on a regular basis (from application) but I've finally managed to disabled it. Having checked the slow query log I think the problem with table scans has disappeared.

At the moment every ten minutes the most recent ten minute record set is spooled in to a file, compressed and transferred onto another system.
So these selects are almost the only (slow) queries reported into the slow query log.
Basically all the queries/aggregations are executed on another machine (Oracle DB).
My idea it to change it and perform aggregations on MySQL directly (either on a heap table / temp or on a slave or both).

Finally, there was one strange behaviour I observed during my testing. I think it is worth to be mentioned about.
With 10k+ inserts per sec, the volume of data that was spooled into a file was definitely much higher.
Once I decreased amount of available RAM, and extended the spool volume from 10 min to 1 hour (just for testing purposes), I quickly noticed that all available RAM was eaten up and MySQL started crashing.
I have not observed such behaviour with 10 min spools but it still made me think.

Regarding "thread_handling = one-thread-per-connection" - definitely I will check it during performance testing. Thanks for letting me know.

Options: ReplyQuote


Subject Views Written By Posted
large InnoDB table partitioning without explicit PK 2456 Miko M 11/12/2014 07:41PM
Re: large InnoDB table partitioning without explicit PK 1390 Rick James 11/13/2014 06:40PM
Re: large InnoDB table partitioning without explicit PK 1220 Miko M 11/14/2014 03:02AM
Re: large InnoDB table partitioning without explicit PK 973 Rick James 11/15/2014 12:05AM
Re: large InnoDB table partitioning without explicit PK 992 Miko M 11/16/2014 07:39PM
Re: large InnoDB table partitioning without explicit PK 877 Rick James 11/17/2014 04:21PM
Re: large InnoDB table partitioning without explicit PK 976 Rick James 11/17/2014 07:48PM
Re: large InnoDB table partitioning without explicit PK 945 Miko M 11/18/2014 02:00AM
Re: large InnoDB table partitioning without explicit PK 989 Rick James 11/18/2014 11:35PM
Re: large InnoDB table partitioning without explicit PK 1034 Miko M 11/22/2014 06:44AM
Re: large InnoDB table partitioning without explicit PK 927 Miko M 11/18/2014 01:13AM
(non-unique) index more efficient than partition pruning 1152 Miko M 11/19/2014 12:27AM
Re: (non-unique) index more efficient than partition pruning 1029 Rick James 11/19/2014 06:01PM
Re: (non-unique) index more efficient than partition pruning 1056 Miko M 11/22/2014 08:39AM
Re: large InnoDB table partitioning without explicit PK 1043 Miko M 11/14/2014 03:04AM
Re: large InnoDB table partitioning without explicit PK 1094 Miko M 11/14/2014 03:05AM
Re: large InnoDB table partitioning without explicit PK 1177 Rick James 11/15/2014 12:32AM
Re: large InnoDB table partitioning without explicit PK 1112 Miko M 11/16/2014 08:31PM
Re: large InnoDB table partitioning without explicit PK 953 Rick James 11/19/2014 12:12AM
Re: large InnoDB table partitioning without explicit PK 919 Miko M 11/22/2014 09:07AM
Re: large InnoDB table partitioning without explicit PK 911 Rick James 11/23/2014 09:00PM
Re: large InnoDB table partitioning without explicit PK 999 Miko M 12/01/2014 11:16AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.