问题
Let me explain the context first : I am building a visit tracker, with PHP and MySQL. So when a user visit a certain URL, his informations will be registered, then he will be redirected to a page. Then, when he will click on a link, I will register the information then redirect the user to his destination.
So I need to WRITE informations in the database at the moment of the visit. And I need to READ and WRITE informations at the moment of the click.
My problem is that I will have many many rows to save in the database. And since I need to read and write very quickly (so that the user will be redirected as fast as possible, that's the main concern), I am thinking about partitioning my tables.
But what will be the fastest way of doing it ? I was thinking about two solutions :
Partitioning the table with MySQL
Basically just doing a partition on the table, based on the range of the ID registered. When I will query data, MySQL will take care of it directly, and it will be transparent from the PHP side.
But since I don't know how many rows I will have to register, how can I efficiently define the range ? And what about when I reach the limit of partitions ?
Creating new tables when needed
If I have the actual number of rows cached in memory, I can know that every 100.000 rows, I need to create a new table. So a little before I reach the limit, I just have to create a new table. And from a given ID, I just have to divide by 100.000 to know the table I need to query.
This way, I will not have any problems about a maximum number of partitions.
But what will be the most efficient in my situation ? Can a partition system based on PHP (that's basically what I intend to do in solution #2) be more efficient than the one from MySQL ? Or should I rely on MySQL and if I ever reach a limit, create another partitioned table ?
来源：https://stackoverflow.com/questions/34984953/database-partition-better-done-by-php-or-mysql