EF Core gives you several ways to search text, and on MySQL with Oracle's provider they behave differently in ways that matter: some ignore case, some don't, and one treats % as a wildcard. This guide runs each one on the same data, and reads the SQL, so you can choose.
A list endpoint shouldn't return every row. Skip and Take give you one page at a time, which EF Core turns into MySQL's LIMIT and OFFSET. Getting it right takes three more things: a sort order rows can't escape from, the total count, and a limit on the page size. This guide builds all of it.
ExecuteDeleteAsync sends one DELETE to MySQL, without loading anything, for one row or thousands. It's shorter than loading a row and removing it. But its errors arrive differently, and that catches people out. This guide shows the call, the SQL, and how to handle a foreign key refusal.
SaveChangesAsync loads rows, changes them in memory and writes them back. When you already know the change, that's wasted effort. ExecuteUpdateAsync sends one UPDATE straight to MySQL, for one row or thousands. This guide shows it in use, reads the SQL, and demonstrates the two ways it can surprise you.
To delete a row with EF Core, load it, call Remove, and call SaveChangesAsync. A Web API also needs to answer the two things that can go wrong: the row isn't there, and other rows still depend on it. This guide does all of that, with the real SQL from MySQL.
To update a row with EF Core, load it, change the property, and call SaveChangesAsync. There's no Update call in that, and EF Core sends an UPDATE with only the columns that changed. If nothing changed, it sends nothing at all. This guide shows that in the real SQL, and compares it with the Update method.
EF Core decides what SQL to send by looking at each entity's state. There are five states, and once you know them, SaveChangesAsync stops being mysterious. This guide follows one entity through all of them, printing the state at each step and showing the SQL each save sends.
When SaveChangesAsync does something you didn't expect, or nothing at all, you need to see what EF Core thinks has changed. ChangeTracker.DebugView.LongView prints it: every tracked entity, its state, each property's value, and what changed from what. This guide reads it for a real change.
ToQueryString() gives you the SQL a LINQ query would send, as a string, without running it. It's handy for one query you want to look at, with no need to turn on logging for the whole app. This guide shows it with a constant and a variable.
AnyAsync answers one question: is there at least one row like this? It sends SELECT EXISTS and returns true or false, so nothing gets loaded or counted. This guide shows the call, the SQL, and the one thing it can't do safely.
