Prepared statements are where database work starts becoming more real and more professional.

Until now, you were building full SQL strings directly, including the values inside the query text. That works for basic learning, but it becomes dangerous the moment values come from outside your code, like form fields, URL params, or anything user-controlled. That is where SQL injection enters the picture.

Prepared statements solve that by separating the SQL structure from the actual data. First you prepare the query template with placeholders. Then, in a second step, you bind real values into those placeholders and execute the statement. So the database sees the SQL shape first, and the data separately after that.

That separation gives you the main practical win here: safer inserts. It also makes repeated execution cleaner, because you can prepare once and then execute the same statement multiple times with different values.

In MySQLi object-oriented style, that flow is usually: create the SQL with question-mark placeholders, call $conn->prepare(...), bind the variables with bind_param(...), set the variable values, then call execute().

One small but important new detail is the type string in bind_param(). Something like "ss" means both bound values are strings. If you had an integer and a string, it might look like "is". That type string has to match both the number and kind of values you are binding.

So the useful mental model is: normal insert mixes SQL and data together in one string. Prepared statements split that into two stages – query template first, values later.