Here's something you might find confusing. We'll illustrate it with an example. Let's imagine you want to track each time a User completes or finishes a BlogPost. So you might throw that into a pivot table. Let's make a migration called post_reads. Now if I take a look at that migration file, what do we need? Well, I need to track the user_id and the post_id, right? So let's say I want an unsigned big integer for the user_id, and then another one for the post_id in question. Now I'm going to leave it like this, and I want to show you something.

the post ID in question. Now I'm going to leave it like this, and I want to show you something. If I run the migration, and I switch over to SQL Pro, we now have our postReads table. And focus your attention right here, under the indexes section, we have one for the primary key. All right, this all looks good. But then you remembered, oh, I forgot to set up the foreign constraints. So you switch back to your migration, and you update it right here. The foreign key, user_id, references the id column on the users table. And we'll leave it like that.

The foreign key, user_id, references the ID column on the users table. And we'll leave it like that. We'll do one more here for the post. The post_id references the ID column on the posts table. Okay. So now we will roll back that last migration, and then rerun it. All right. So notice, we still haven't set up an index on either of these foreign keys. However, if I switch back to SQL Pro, and I give this a refresh, now we have two new ones.

So this functionality you see here can vary based on the platform. So whether you're using SQL Server versus Postgres versus MySQL versus MariaDB, fill in the blank, they may differ here. So in the case of MySQL, and I think the same is true for Postgres, when you register a foreign key in a constraint, it will automatically create the index if you did not include one. And of course, it does this to improve performance. When you are filtering a table based on one of these foreign keys, MySQL doesn't want to perform a full table scan. So it automatically adds the index, even if you didn't include one. So let's talk about that.

So it automatically adds the index, even if you didn't include one. So let's talk about that. If I switch back to Sublime, yes, when you register these foreign keys, you could add an index here. And this is one way to do it. And yes, if we rolled back the migration and we reran it, if I switch back to SQL Pro and I give this a refresh, the key name has changed. That doesn't matter, though. It's just a convention that Laravel provides. But nonetheless, the end result is identical.

It's just a convention that Laravel provides. But nonetheless, the end result is identical. So you can do this to be explicit, and that might even be a good thing. But it's not required if you only intend to ever use MySQL.