Strip the mystique off SQL injection and it's one idea: the application glues your input into a query like taping two strips of paper together. If it trusts your input and tapes it in raw, you can write input that stops being data and starts being instructions.
Type ' OR 1=1 -- into a username field and the query is no longer asking "is this a valid user?", it's asking "is one equal to one?", which it always is.
-- what the developer wrote
SELECT * FROM users WHERE name = '$input';
-- what you sent
' OR 1=1 --
-- what the database runs
SELECT * FROM users WHERE name = '' OR 1=1 --';
The fix is equally simple, and it's the same fix for every injection bug everywhere: keep data and code in separate channels. Parameterized queries hand the database the query and the values separately, so a value can never be reinterpreted as syntax. String concatenation is the bug; parameterization is the cure.
The bigger lesson generalises past SQL: every injection (SQL, command, template, all of it) is the same gap between what the developer believes the code does and what it actually does when fed something they never pictured. Find that gap and you find the bug.
(Always on DVWA, Juice Shop, and the deliberately vulnerable labs. SQLi against something you don't own and that has no program is a crime with extra steps.)