Salts don't help prevent someone from cracking a particular password. They help prevent someone from cracking many passwords at once using a rainbow table.
Say you have the following users on your site (the password wouldn't actually be stored in the database, just the hashed version).
USER PASSWORD HASHED PASSWORD
hamfist god de898928393a893
bttltoad god de898928393a893
woob god de898928393a893
marco-fiset mypass1 1238ffff2342399
dean password2 a44ca77446ff449
If someone were to pre-compute the hashes for a ton of passwords ahead of time and store this in memory (a rainbow table) then it would be trivial for them to check if
de898928393a893 existed in the password list. They would then know that all of these users accounts could be accessed with the password,
god. In very short order, they would have access to the accounts of everyone with a simple password that exists in their rainbow table (and anywhere else on the web that person uses the same email/password combo).
Now if you add a random salt, everyone with the same password will end up with different hashes:
USER PASSWORD SALT HASHED PASSWORD
hamfist god ae#o abf4388ff343401
bttltoad god cdo@ 29292d919100001
woob god !doe 3902dda99210099
marco-fiset mypass1 12uo aaffff121bcce13
dean password2 TEe9 b44ca7743324234
Now a rainbow table doesn't really help. Instead of just needing the hash for
god, for instance, you'd need to pre-compute the hash for
god + <all_potential_salts>. Kind of limits what you can store in memory.
However, if someone is out to get
hamfist specifically, they have the salt since it's stored in the database, so this isn't going to slow down a cracking attempt at all.