MySQL Forums :: Partitioning :: No other way than delete primary key to create partitions by single datetime columns?


Advanced Search

Re: No other way than delete primary key to create partitions by single datetime columns?
Posted by: Sam Young ()
Date: August 26, 2015 12:53AM

Enlightening article in the blog.
Partition seems not so powerful as in my guess.
Sorry for my lack of experience, if a table comes 10M+, 100M+ rows and more, what to do in general to keep the SQL's performance and avoiding entangle the service logic so mush?
split the table? use other DB product? or some nosql things? search engine?

Options: ReplyQuote


Subject Views Written By Posted
No other way than delete primary key to create partitions by single datetime columns? 1251 Sam Young 08/20/2015 08:00PM
Re: No other way than delete primary key to create partitions by single datetime columns? 780 Jonathan Stephens 08/21/2015 02:53AM
Re: No other way than delete primary key to create partitions by single datetime columns? 690 Sam Young 08/23/2015 08:57PM
Re: No other way than delete primary key to create partitions by single datetime columns? 681 Rick James 08/22/2015 03:35PM
Re: No other way than delete primary key to create partitions by single datetime columns? 631 Sam Young 08/23/2015 09:23PM
Re: No other way than delete primary key to create partitions by single datetime columns? 605 Rick James 08/24/2015 12:36PM
Re: No other way than delete primary key to create partitions by single datetime columns? 671 Sam Young 08/26/2015 12:53AM
Re: No other way than delete primary key to create partitions by single datetime columns? 671 Rick James 08/26/2015 10:02AM
Re: No other way than delete primary key to create partitions by single datetime columns? 629 Sam Young 08/26/2015 07:42PM


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.