9 hours 41 minutes
I welcome back to modulate This is less than 8.5 partitions. Partitions is another useful tool that can help you optimize your sequel. Database partitions. Divide a single sequel table into multiple, smaller tables. This optimizes performance by providing less data to examine during queries.
This is hidden from the sequel programming layer or its abstracted.
So when you program or right sequel against a partition table, you do not have to go through the trouble of targeting the correct partition.
You will want to create or select a proper partition. Key wind creating a partition
Failure to implement inappropriate partition may actually her performance. For example, consider a scenario in which you've created a partition for every record on the table that would not be very efficient and would actually yield worst performance if you hadn't partitioned it in the first place. There are different partition types,
and we'll look at all the types
in the development environment when we get there. The types include range list, hash and key,
and the use case for all partitioning is when large tables with millions of records or more
and the illustration in the bottom right corner, you can see a good representation of what a partition is doing. It's taken the primary table, and it's breaking it up into three parts. Then, when I query has to go to a specific record, it can go specifically to that partition. Now the difference here is they.
In a real world partition, you wouldn't have three items.
You would have probably millions or more items. But this is just the service, that visual example. Now, with that, let's head over to the development environment and take a look at how we might implement a partition.
So here we are in the development environment, have a note at the top for additional information, and it reads as follows. It's a good idea to create the partition when creating the table. When using the altar table method is I have in these examples, the database actually copies all the data into a new area and then discards the older
so a large table is effectively doubled for a short period of time. So if you have a table that you're going to partition and it has three gigabytes of data for a period of time, it's going to take up six gigabytes of data, and that's something you want to be aware of. If you happen to be tight on space. Also,
the copying can take a while with a very large table.
Now, before we go ahead and implement these partitions, let's go ahead and make sure that we have a record that will allow us to see the difference.
So go to the PM Tran table in Akeem, Attica, and make sure that you have at least one record where the company I d. Is three and not to. And to change that Andy Beaver, it's very simple. You click into it, you change it to a four or two or three or whatever number you would like to use.
You just click, save,
then you're done.
So now, if you go back to these partition commands, the first example is by key.
So again, this is just getting the syntax right. We're going to alter table PM Tran from the axiomatic and database we're gonna partition by key are key is going to be the company I d. And we're going to do partitions number account of to.
So I'll go ahead and run this.
Okay, so that took 991 milliseconds, which is a lot slower than a query would take.
That's because of all that data copying that's going on. That data rearranging that took two milliseconds much faster.
So if we go to the PM Tran Table and D Beaver, we'll take a look at the properties. We can see that there's two partitions. Make sure you're on the partitions tab
p zero p one.
And if we go back to our script and we explain the selection where we're using that key, so let's use where company ID equals three,
we can see that that's using partition zero or P zero.
And if we do too,
we can see this switch the partition one. So we know that we have effectively partitioned the table in the way that we expect. We are able to go to different partitions based on what we're filtering. Four.
Now let's try with the list example,
so I could list Mawr in this definition. For example, I could do 34 I don't have a company floor, but I could just make it available. We go ahead and run this
and thats done
and again if you go to PM Tran and we refresh it. We'll see the method has changed to list and that we have a description that identifies what's in that list
and let's go back and run our explain command.
So the explain where company I DS two would go to partition zero.
And then if we changed it to three, of course it's gonna go to P one or partition one,
and that's what we expect.
Let's test the range example,
and something else to realize here is that when I add a partition to a table, it's actually replacing the last partition. So I don't have all these partitions on the table. When I run this command, this partition will be replaced with the range example.
Let me go ahead and run this
and thats done.
I go to the PM Tran table and I refresh it again. I'll see that I have a method of range, and I'll have a description that matches that range.
And then if I run the explain command again,
I can see that I'm going to pee one for three.
I switched it to,
and I'll go to P zero. Just what I expect
and and the last example we're going to do a altar table by hash with two partitions, which is pretty similar to the key method.
Now, when the system names the partitions, it starts at P zero p. One. But we could have given them a different name when we define the name ourselves, but I just like to follow the same,
uh, patterns that I see. So when it's automatically listed is P zero p one. I used that same name and scheme myself in many cases, unless I have a special reason to rename something.
So let's go ahead and run that altar table are altar table by hash example.
And that's complete,
and this is gonna have the expected results for sure. Partition zero.
three on. We can see that this is going to partition one,
and then we go to the PM Tran table. We can see that it's changed to a hash method,
and that is it. With partitioning, there's actually not terribly complicated. Thebe partitioning is just breaking a bigger table into smaller tables to make querying mawr effective.
Now let's go ahead and head over to the lesson review before we close out this lesson,
so that brings us to the 8.5 summary. In this lesson, we discussed partitions and partitions divide a single sequel table into multiple, smaller tables. There's different types of partitions. They are pretty easy to implement. It is best to implement when creating the table,
as the database needs to copy all the data into a new area
when implementing a partition.
The use case strengthens as record count climbs, I have heard some indicate they wouldn't implement a partition until they reached millions of records.
But if you believe partitioning might strengthen your optimization by all means implemented,
you do want to use this method instead of making your own smaller tables. I have seen some instances in applications where the developer implemented a bunch of smaller tables to how such a large set of data.
So if you find yourself in that situation, be sure to imply it using partitions instead, it will be easier to manage,
so that completes this lesson, and I hope to see you in the next thank you